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. - Derek _______________________________________________ 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".
