| Message ID | 20220201015648.2086-1-jamrial@gmail.com |
|---|---|
| State | Accepted |
| Commit | 3b9bd63ad92967e06d5e2f67e0cfd9093bf7700d |
| Headers | show |
| Series | [FFmpeg-devel,1/4] avformat/demux: don't propagate unsupported skip samples packet side data values | expand |
| Context | Check | Description |
|---|---|---|
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
| andriy/make_ppc | success | Make finished |
| andriy/make_fate_ppc | success | Make fate finished |
On 1/31/2022 10:56 PM, James Almer wrote: > Should fix ticket #9622 > > Signed-off-by: James Almer <jamrial@gmail.com> > --- > I'm not sure if this is ok or not. The AV_PKT_DATA_SKIP_SAMPLES doxy states > the skip samples value is a little endian uint32 value, so even if the mov > demuxer wrote a truncated int64_t value in sti->skip_samples (which, being an > int, can be negative), it would still be "valid" when written into the packet > as side data. > > Chromium's fix is https://chromium-review.googlesource.com/c/chromium/src/+/3424556 > where you can see they have been reading the skip samples value from > AV_PKT_DATA_SKIP_SAMPLES as an int. > > libavformat/demux.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/demux.c b/libavformat/demux.c > index f895f0ba85..09d539af68 100644 > --- a/libavformat/demux.c > +++ b/libavformat/demux.c > @@ -1354,6 +1354,7 @@ static int read_frame_internal(AVFormatContext *s, AVPacket *pkt) > } > if (sti->start_skip_samples && (pkt->pts == 0 || pkt->pts == RELATIVE_TS_BASE)) > sti->skip_samples = sti->start_skip_samples; > + sti->skip_samples = FFMAX(0, sti->skip_samples); > if (sti->skip_samples || discard_padding) { > uint8_t *p = av_packet_new_side_data(pkt, AV_PKT_DATA_SKIP_SAMPLES, 10); > if (p) { Will apply patchset.
diff --git a/libavformat/demux.c b/libavformat/demux.c index f895f0ba85..09d539af68 100644 --- a/libavformat/demux.c +++ b/libavformat/demux.c @@ -1354,6 +1354,7 @@ static int read_frame_internal(AVFormatContext *s, AVPacket *pkt) } if (sti->start_skip_samples && (pkt->pts == 0 || pkt->pts == RELATIVE_TS_BASE)) sti->skip_samples = sti->start_skip_samples; + sti->skip_samples = FFMAX(0, sti->skip_samples); if (sti->skip_samples || discard_padding) { uint8_t *p = av_packet_new_side_data(pkt, AV_PKT_DATA_SKIP_SAMPLES, 10); if (p) {
Should fix ticket #9622 Signed-off-by: James Almer <jamrial@gmail.com> --- I'm not sure if this is ok or not. The AV_PKT_DATA_SKIP_SAMPLES doxy states the skip samples value is a little endian uint32 value, so even if the mov demuxer wrote a truncated int64_t value in sti->skip_samples (which, being an int, can be negative), it would still be "valid" when written into the packet as side data. Chromium's fix is https://chromium-review.googlesource.com/c/chromium/src/+/3424556 where you can see they have been reading the skip samples value from AV_PKT_DATA_SKIP_SAMPLES as an int. libavformat/demux.c | 1 + 1 file changed, 1 insertion(+)