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

[Anton Khirnov]

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.
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.

-- 
Anton Khirnov