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. > _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
