[FFmpeg-devel] [PATCH 2/3] ffmpeg.c: refine picking default video stream

[James Almer]

On 10/25/2020 10:26 AM, Anton Khirnov wrote:
> Quoting Andreas Rheinhardt (2020-10-25 14:17:06)
>> Anton Khirnov:
>>> Quoting Michael Niedermayer (2020-10-21 13:17:46)
>>>>
>>>> are we talking about the same thing ?
>>>> ./ffmpeg  -i ~/tickets/4496/08_lect_01.rm  file.avi
>>>>
>>>> produces a output over 1 hour long before the patch, theres no seek to before EOF
>>>>
>>>> ./ffmpeg  -i ~/tickets/4496/08_lect_01.rm  file-new.avi
>>>>
>>>> after the patch the output is empty
>>>>
>>>> IMHO, its important to remove access to internal fields from applications.
>>>> its important to cleanup code but its also important to do the cleanup
>>>> cleanly. And just droping everything thats in the way instead of spending
>>>> the hour(s) to do it properly. That is IMHO tainted cleanup, as if you
>>>> wash a dirty surface with dirty water ;)
>>>
>>> Do you have any actual suggestions as to what a "clean" solution should
>>> look like? "Not break any samples" is not a vary practical one, since I
>>> don't have all your samples and besides is too restrictive, since any
>>> change can potentially break some workflow [1].
>>>
>>> How about exporting a per-AVStream flag that indicates whether there
>>> were every any packets seen for that stream? That would allow to keep
>>> current functionality in ffmpeg.c and still avoid exporting too much
>>> detail about the inner workings of avformat_find_stream_info().
>>>
>> Where would you add this flag to AVStream? Given that ffmpeg uses
>> internal fields there is no good solution to this.
> 
> Yes, we are now officially dumpster fire, The major bump cannot come any
> sooner.

Lets cut a 4.4 release before this work goes in (assuming we want a last
one using the current soname/s), then simply don't worry if you break
offsets in any struct, as it will not make it to a release and the bump
will come soon afterwards.

> Except these patches are a part my work towards the bump, so things get
> a bit circular.
> 
> One option is to make it an event flag. That might even be usable for a
> wider number of use cases, though I cannot think of any right now.
>