В сообщении от 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 ...