[FFmpeg-devel] [PATCH][RFC - DO NOT MERGE] Revert "mov: Discard invalid CTTS."

Michael Niedermayer michael at niedermayer.cc
Wed Mar 10 19:24:19 EET 2021


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210310/5843672f/attachment.sig>


More information about the ffmpeg-devel mailing list