On Fri, May 08, 2020 at 05:21:06PM -0700, Dale Curtis wrote: > On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote: > > > On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer > > <mich...@niedermayer.cc> > > > wrote: > > > > > > > On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote: > > > > > On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer > > > > <mich...@niedermayer.cc> > > > > [...] > > > > > > > > > > You snipped out the example I provided, > > > > yes because it was messed up from linebreaks which made both variants > > unreadable > > > > Sorry, here's it in pastebin: https://pastebin.com/raw/p1VyuktF
for the purpose of the start_time adjustment I cannot think of a case where this code would trigger with a real undamaged file. The resulting timestamp should be representable as 64bit int. It being not representable kind of points to something being wrong on the input to this expression If it is an issue just in this packets timestamp which is used then just ignoring that and using the next one would be a possibility Similarly when anything else is wrong which could be corrected subsequently. If its a fuzzed and broken beyond repair file anything would be fine as value or also erroring out. I presume we have this being hit with a fuzzed file and not a real file, so the whole discussion about what would be best for real file error robustness is a bit hypothetical. OTOH for fuzzed files it doesnt really matter much what is done. So i have not much of an oppinion on what to do here. thx [...] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
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".
