В сообщении от Friday 06 November 2020 01:40:34 вы написали:

Quoting Andrew Randrianasulu (2020-11-05 17:53:51)

...

В сообщении от Thursday 05 November 2020 14:57:22 вы написали:

...

Hi, Quoting Andrew Randrianasulu (2020-10-30 21:23:22)

...

Hello, Anton.

Sorry for writing to you directly and not to ffmpeg-devel, I'm not subscribed to it (just reader via web interface). You can copy my email there if you want.

In https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/cea7c19cda0ea1630ae1de8c102a... you moved nb_index_entries to private header, yet as it turned out this code was used by CinelerraGG:

https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra...

line 723 for example ..

Do you have any alternative route for getting this info? I hacked sources of CinlerraGG a bit by directly including libavformat's internal header, but it was not very good idea becaiuse something conflicted when I added it to header file, and required alteration of yet another file even if I added it only to ffmpeg.C

My hack attached ...

frankly, that code looks like a horrible pile of hacks. I cannot, from a quick glance, tell what is it using those private fields for and why it doesn't just call avformat_seek_file() like any other well-behaved program would.

Good question. I think code 'evolved' this way, because this is non-linear video editor (so, playback/decoding position can jump randomly forward and backward). Also, some format seeks better than others. May be other editors work-around this problem differently. Or their users just adviced to avoid hard-to-edit formats.

I think ffms2 <https://github.com/FFMS/ffms2> also operates under similar constraints, but it does not access private fields. Maybe you could draw some inspiration from there.

Thanks, I compiled it once for Aegisub, and forgot about it :/

...

Can I forward your question about this code to our mail list?

Sure. I can also be reached on IRC in freenode/#ffmpeg-devel, if anyone wants to discuss this further.

Forwarding ...