[FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.
Michael Niedermayer
michael at niedermayer.cc
Thu May 14 01:55:32 EEST 2020
On Fri, May 08, 2020 at 05:21:06PM -0700, Dale Curtis wrote:
> On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer <michael at 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
> > <michael at 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
> > > > <michael at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200514/79c907c5/attachment.sig>
More information about the ffmpeg-devel
mailing list