On Wed, Mar 10, 2021 at 03:29:46PM +0000, Derek Buitenhuis wrote: > On 08/03/2021 17:29, Michael Niedermayer wrote: > > I would try to detect the specific abberant muxer based on the input. > > Then have custom code in the demuxer which is based on reverse engnenering > > the > > issue to do a best effort to recover as much as is possible. And also print > > a big > > warning about the broken input / muxer so the user doesnt stay unaware. > > I mean, I already listed the options in my email. Best you can do is try and > check > for insane PTS/DTS diff (I proposed 16 frames), and the 'fix' of dropping the > CTTS > info just makes it broken in a different way.
> > > You can see this also in 2 ways > > 1. It sucks its not our job to workaround someone elses bugs > > 2. It cool, it gives FFmpegs demuxer a unique advantage over competing > > demuxers > > As an API user, I do not see returning made up PTS/DTS rather than what is in > file > as an advantage. At least if I have what is in the file, I can make my own > decisions > in my program, on how to handle it. > > As it stands right now, as detailed in my previous mail, I have no way to > even detect > these files since avformat handles them differently depending on if the file > hits > the arbitary number of 1<<28. > > What I'm looking for here is something actionable: I know what the > possibilities are > for changes/fixes. Which the community prefers are not clear. As it stands, > it is > just broken. what does the muxer exactly do ? Let me give an example (totally made up but to explain my point) if each ctts value for example has its file position added to it that can be reverted and the original ctts fully recovered. (also a user app cannot do this, only the demuxer could as the user app has no knowledge of the atoms file position) Does it store uninintialized memory then it would not be revertable but it did not sound like thats whats happening. about never modifying data, for that a system similar to workaround_bugs we have on the decoder side could be added. But its not really the users job to do this. The demuxer should already return as much recoverable data as possible. thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
