Message ID | CAPUDrweLGxJHFvZP6BDGt2MqMOHk+aW=P-w6OmEydnKdh4oFWQ@mail.gmail.com |
---|---|
State | Superseded |
Headers | show |
On Fri, Nov 17, 2017 at 01:46:39PM -0800, Dale Curtis wrote: > Derp, actually, 2 << 63 doesn't fit in int64_t either, this check should be > < 63. Fixed. > > > > On Fri, Nov 17, 2017 at 1:38 PM, Dale Curtis <dalecurtis@chromium.org> > wrote: > > > 2 << (wrap_bits=64 - 1) does not fit in int64_t; apply the check > > used in other places that handle wrap bits to ensure the values > > are <= 63. > > > > Signed-off-by: Dale Curtis <dalecurtis@chromium.org> > > > > > utils.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > 2f61647f4321bebca803154960f74643d4670ee8 wrap_bits_v2.patch > From 4ae4992326487ba0e42fa7fcf2a53fe3d4564780 Mon Sep 17 00:00:00 2001 > From: Dale Curtis <dalecurtis@chromium.org> > Date: Fri, 17 Nov 2017 13:35:56 -0800 > Subject: [PATCH] [avformat] Prevent undefined shift with wrap_bits >= 63. > > 2 << (wrap_bits=63 - 1) does not fit in int64_t; apply the check > used in other places that handle wrap bits to ensure the values > are < 63. > > Signed-off-by: Dale Curtis <dalecurtis@chromium.org> > --- > libavformat/utils.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavformat/utils.c b/libavformat/utils.c > index ff5e14df6c..65d111459f 100644 > --- a/libavformat/utils.c > +++ b/libavformat/utils.c > @@ -1738,8 +1738,8 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt) > // current one had no dts, we will set this to AV_NOPTS_VALUE. > int64_t last_dts = next_pkt->dts; > while (pktl && next_pkt->pts == AV_NOPTS_VALUE) { > - if (pktl->pkt.stream_index == next_pkt->stream_index && > - (av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0)) { > + if (pktl->pkt.stream_index == next_pkt->stream_index && wrap_bits < 63 && > + av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0) { this would skip the code for wrap_bits >= 63, this does not look correct [...]
On Sat, Nov 18, 2017 at 2:44 AM, Michael Niedermayer <michael@niedermayer.cc > wrote: > > this would skip the code for wrap_bits >= 63, this does not look > correct > Why do you think that's incorrect? The max int64_t value is 1 << 63 and 2 << 63 == 1 << 64 ? - dale
On Mon, Nov 20, 2017 at 12:05:05PM -0800, Dale Curtis wrote: > On Sat, Nov 18, 2017 at 2:44 AM, Michael Niedermayer <michael@niedermayer.cc > > wrote: > > > > this would skip the code for wrap_bits >= 63, this does not look > > correct > > > > Why do you think that's incorrect? The max int64_t value is 1 << 63 and 2 > << 63 == 1 << 64 ? I think its incorrect because the change would completely skip the loop but a wrap of "1<<64" would still need pts to be filled in. [...]
On Mon, Nov 20, 2017 at 12:40 PM, Michael Niedermayer < michael@niedermayer.cc> wrote: > On Mon, Nov 20, 2017 at 12:05:05PM -0800, Dale Curtis wrote: > > On Sat, Nov 18, 2017 at 2:44 AM, Michael Niedermayer > <michael@niedermayer.cc > > > wrote: > > > > > > this would skip the code for wrap_bits >= 63, this does not look > > > correct > > > > > > > Why do you think that's incorrect? The max int64_t value is 1 << 63 and 2 > > << 63 == 1 << 64 ? > > I think its incorrect because the change would completely skip the loop > but a wrap of "1<<64" would still need pts to be filled in. > There's no way this code can work with a wrap_bits > 63. 2<<64 > uint64_t. The best we can do over my change is to make wrap_bits == 63 work by changing the line from 2LL << (wrap_bits - 1) to 2ULL << (wrap_bits - 1). av_compare_mod takes a uint64_t in this position so that should be okay. How does that sound? - dale
On Mon, Nov 20, 2017 at 01:15:24PM -0800, Dale Curtis wrote: > On Mon, Nov 20, 2017 at 12:40 PM, Michael Niedermayer < > michael@niedermayer.cc> wrote: > > > On Mon, Nov 20, 2017 at 12:05:05PM -0800, Dale Curtis wrote: > > > On Sat, Nov 18, 2017 at 2:44 AM, Michael Niedermayer > > <michael@niedermayer.cc > > > > wrote: > > > > > > > > this would skip the code for wrap_bits >= 63, this does not look > > > > correct > > > > > > > > > > Why do you think that's incorrect? The max int64_t value is 1 << 63 and 2 > > > << 63 == 1 << 64 ? > > > > I think its incorrect because the change would completely skip the loop > > but a wrap of "1<<64" would still need pts to be filled in. > > > > There's no way this code can work with a wrap_bits > 63. 2<<64 > uint64_t. i dont dispute that, what i meant was more high level that is, "what that code should be doing", i think is different from skiping the code > The best we can do over my change is to make wrap_bits == 63 work by > changing the line from 2LL << (wrap_bits - 1) to 2ULL << (wrap_bits - > 1). av_compare_mod takes a uint64_t in this position so that should be > okay. How does that sound? I think that could end with the correct result thanks [...]
From 4ae4992326487ba0e42fa7fcf2a53fe3d4564780 Mon Sep 17 00:00:00 2001 From: Dale Curtis <dalecurtis@chromium.org> Date: Fri, 17 Nov 2017 13:35:56 -0800 Subject: [PATCH] [avformat] Prevent undefined shift with wrap_bits >= 63. 2 << (wrap_bits=63 - 1) does not fit in int64_t; apply the check used in other places that handle wrap bits to ensure the values are < 63. Signed-off-by: Dale Curtis <dalecurtis@chromium.org> --- libavformat/utils.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index ff5e14df6c..65d111459f 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -1738,8 +1738,8 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt) // current one had no dts, we will set this to AV_NOPTS_VALUE. int64_t last_dts = next_pkt->dts; while (pktl && next_pkt->pts == AV_NOPTS_VALUE) { - if (pktl->pkt.stream_index == next_pkt->stream_index && - (av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0)) { + if (pktl->pkt.stream_index == next_pkt->stream_index && wrap_bits < 63 && + av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0) { if (av_compare_mod(pktl->pkt.pts, pktl->pkt.dts, 2LL << (wrap_bits - 1))) { // not B-frame next_pkt->pts = pktl->pkt.dts; -- 2.15.0.448.gf294e3d99a-goog