On Thu, Mar 11, 2021 at 12:58 PM Derek Buitenhuis < derek.buitenh...@gmail.com> wrote:
> On 11/03/2021 08:36, Michael Niedermayer wrote: > > These are not enough to unambigously reverse engeneer the bug in the > muxer > > is it true for every output of the muxer, does it always happen at the > > same position ? > > is the runaway delta always 8 ? > > does it always coincide with the 2nd entry of stts ? > > is it a coincidence that the first and 2nd stts entries differ by 8 too ? > > I think you and I have very different opinions on how this shuld be fixed. > The files > are broken. > > Nothing is consisent between hese files, and it is not a good use of > anyones time > to try and reverse engineer an unknown muxer we don't have access to based > on ses > of files, so that we can remove or change a a hack from years ago. What > you are > asking for is ridiculous. > > Even if some files showd a pattern, coding that into a demuxer is *wrong* > and fragile > at best. It just leads to more confusion and more hacks down the road when > some files > are broken in slightly different ways. It's adding fragile hacks on top of > fragile hacks, > to work around a bug that an unknown muxer had once. > > Frankly, I regret asking for input if this is the result. > > > > I was trying to describe how I would go fixing this if i was working on > it. > > And thus how someone else could fix it as well. > > This is not useful - I can do that till the cows come home, > > > What you seem to want is the result to a snippet of your "homework". Yes > that would be > > easier but if i knew what exactly to do then i would already have had to > test > > it and so would already have an implementation of it and would need to > have > > all samples and much more time. > > This is personally insulting for a few reasons: > > 1. You are implying the digging I've already done is not good enough or > that I'm > lazy for not followng your extremely vague 'well you could do this' > email > based on nto even checking anything. I did the digging that is possible > with > what is available to me, and to what I think is a good thechnical > solution, > and I've recieved no feedback on those except 'maybe do some more > digging and > add some hacks'. This is demotivating and insulting, and this crap is > part of > the reason I've distanced myself from this community. > 2. 'all samples' do not exist. It is infuriating to imply I should reverse > engineer > some unknown muxer, with a limited set of samples, and add a hack for > them, in > order to justify a previous entirely arbitrary hack added for a single > file. > > To state out this outright: The commit this revers is *wrong* and > *terrible* and > should never have been pushed in the first place. I was trying to be > ammicable here > engage in discussion on how best to remove or change it, but all I got was > the > 'Bring Me A Rock, Bring Me A Different Rock' scenario. Your barrier to add > the hack > was 0, my barrier to remove it is high. > > > yes but that code is unrelated, with or without it the ctts are trash > for this file > > this needs code prior to that test that fixes the ctts and then this > would not > > trigger anymore as the ctts would be corrected > > It does not *fix* anything. Even on the old file. It removes the ctts, but > it does not *fix* > it. Making up timestamps where PTS==DTS for all timestas is not *fixing* > anything. > > What you actually mean to say is 'it made ffmpeg.c decode linearly', which > is something enirely > differnet. It can't even seek. It only works linearly because of the > parser. The DTS are entirely > broken in your 'fix'. > > the API user should receive valid timestamps and not need to handle that. > > it cannot be expected that every API user carries around workarounds for > random > > muxer bugs. That would be really alot of duplicated code > > This is a HARD disagree from me. A demuxe should not be 'fixing' > timstamps. This is > an applciation level problem. > > But even ignoring that, a demuxer should provide *consistent* timestamps > for simila files, > not different based on some arbitrary number hack added in for a single > file. > > > I cant give an exact solution as it requires testing that solution > against as many > > samples as possible (requires both the samples and the time to do the > work) > > Maybe something like subtracting i*8 from entry 2+ works maybe the stts > entry 1-2 > > time should be used instead of 8, maybe we need to take the first - last > ctts to > > get the slope to correct it. > > then we could compare the normally read CTTS vs. the "corrected" CTTS > and check which > > is "flatter" as in maybe sum of abs diff from stts. with a strong bias > toward the > > normal. > > This needs to be implemented to know if it even works, its not unlikely > that this > > would require adjustments to work well, i cannot in 15min just from a > text dump > > tell how to best detect and correct this abberation. Maybe theres also > some > > metadata in the file that could be used to limit to which files to > attempt to > > apply this ... (i didnt see any but again i didnt look very hard) > > The first goal must of course be not to break any correct files which > such > > compensation. > > This is insane. Totally insane. I have no other words for this. > > Given that others on the list (Anton, James, etc.) are probably avoiding > responding to this > crazy thread, I am asking for someone to come in an moderate this > formally, be it by choice > in responding or by he recently approved technical committee. > > We cannot continue with this ridiculousness. > > I have CC'd j-b. > IMHO, please just revert hackish commits if they do not follow specifications. No need for TC or similar. > > - 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". _______________________________________________ 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".
