[FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[Michael Niedermayer]

Fixes: memleak
Fixes: 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/isom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/isom.c b/libavformat/isom.c
index 9fbccd4437f..c5930bd4d87 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, AVStream *st, AVIOContext
                                                 st->codecpar->extradata_size, 1, fc);
             if (ret < 0)
                 return ret;
+            av_channel_layout_uninit(&st->codecpar->ch_layout);
             st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
             st->codecpar->ch_layout.nb_channels = cfg.channels;
             if (cfg.object_type == 29 && cfg.sampling_index < 3) // old mp3on4
-- 
2.17.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/6] avformat/mov: Check that tile_item_list is initialized in read_image_iovl()

[Michael Niedermayer]

Fixes: null pointer dereference
Fixes: 67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/mov.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7bdeeb99f98..fa4c237c0d8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9364,6 +9364,10 @@ static int read_image_iovl(AVFormatContext *s, const HEIFGrid *grid,
     }
 
     for (int i = 0; i < tile_grid->nb_tiles; i++) {
+        if (!grid->tile_item_list[i]) {
+            ret = AVERROR_INVALIDDATA;
+            goto fail;
+        }
         tile_grid->offsets[i].idx        = grid->tile_item_list[i]->st->index;
         tile_grid->offsets[i].horizontal = (flags & 1) ? avio_rb32(s->pb) : avio_rb16(s->pb);
         tile_grid->offsets[i].vertical   = (flags & 1) ? avio_rb32(s->pb) : avio_rb16(s->pb);
-- 
2.17.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/6] avformat/mov: Check that tile_item_list is initialized in read_image_iovl()

[James Almer]

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> Fixes: null pointer dereference
> Fixes: 67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>   libavformat/mov.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7bdeeb99f98..fa4c237c0d8 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -9364,6 +9364,10 @@ static int read_image_iovl(AVFormatContext *s, const HEIFGrid *grid,
>       }
>   
>       for (int i = 0; i < tile_grid->nb_tiles; i++) {
> +        if (!grid->tile_item_list[i]) {
> +            ret = AVERROR_INVALIDDATA;
> +            goto fail;
> +        }

This should not happen. We shouldn't get this far if the array was not 
filled.

Can you please test the following?

> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7bdeeb99f9..fb0113b149 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -9397,8 +9397,9 @@ static int mov_parse_tiles(AVFormatContext *s)
> 
>          for (int j = 0; j < grid->nb_tiles; j++) {
>              int tile_id = grid->tile_id_list[j];
> +            int k;
> 
> -            for (int k = 0; k < mov->nb_heif_item; k++) {
> +            for (k = 0; k < mov->nb_heif_item; k++) {
>                  HEIFItem *item = &mov->heif_item[k];
>                  AVStream *st = item->st;
> 
> @@ -9424,6 +9425,13 @@ static int mov_parse_tiles(AVFormatContext *s)
>                  break;
>              }
> 
> +            if (k == grid->nb_tiles) {
> +                av_log(s, AV_LOG_WARNING, "HEIF item id %d referenced by grid id %d doesn't "
> +                                          "exist\n",
> +                       tile_id, grid->item->item_id);
> +                ff_remove_stream_group(s, stg);
> +                loop = 0;
> +            }
>              if (!loop)
>                  break;
>          }
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/6] avformat/mov: Check that tile_item_list is initialized in read_image_iovl()

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2661 bytes --]

On Mon, Apr 01, 2024 at 06:54:35PM -0300, James Almer wrote:
> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> > Fixes: null pointer dereference
> > Fixes: 67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >   libavformat/mov.c | 4 ++++
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 7bdeeb99f98..fa4c237c0d8 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -9364,6 +9364,10 @@ static int read_image_iovl(AVFormatContext *s, const HEIFGrid *grid,
> >       }
> >       for (int i = 0; i < tile_grid->nb_tiles; i++) {
> > +        if (!grid->tile_item_list[i]) {
> > +            ret = AVERROR_INVALIDDATA;
> > +            goto fail;
> > +        }
> 
> This should not happen. We shouldn't get this far if the array was not
> filled.
> 
> Can you please test the following?
> 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 7bdeeb99f9..fb0113b149 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -9397,8 +9397,9 @@ static int mov_parse_tiles(AVFormatContext *s)
> > 
> >          for (int j = 0; j < grid->nb_tiles; j++) {
> >              int tile_id = grid->tile_id_list[j];
> > +            int k;
> > 
> > -            for (int k = 0; k < mov->nb_heif_item; k++) {
> > +            for (k = 0; k < mov->nb_heif_item; k++) {
> >                  HEIFItem *item = &mov->heif_item[k];
> >                  AVStream *st = item->st;
> > 
> > @@ -9424,6 +9425,13 @@ static int mov_parse_tiles(AVFormatContext *s)
> >                  break;
> >              }
> > 
> > +            if (k == grid->nb_tiles) {
> > +                av_log(s, AV_LOG_WARNING, "HEIF item id %d referenced by grid id %d doesn't "
> > +                                          "exist\n",
> > +                       tile_id, grid->item->item_id);
> > +                ff_remove_stream_group(s, stg);
> > +                loop = 0;
> > +            }
> >              if (!loop)
> >                  break;
> >          }

i confirm the code fixes the issue, please apply (if it passes fate) and backport (if needed)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/6] avformat/mov: Check that tile_item_list is initialized in read_image_iovl()

[James Almer]

On 4/1/2024 8:49 PM, Michael Niedermayer wrote:
> On Mon, Apr 01, 2024 at 06:54:35PM -0300, James Almer wrote:
>> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
>>> Fixes: null pointer dereference
>>> Fixes: 67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744
>>>
>>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>> ---
>>>    libavformat/mov.c | 4 ++++
>>>    1 file changed, 4 insertions(+)
>>>
>>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>>> index 7bdeeb99f98..fa4c237c0d8 100644
>>> --- a/libavformat/mov.c
>>> +++ b/libavformat/mov.c
>>> @@ -9364,6 +9364,10 @@ static int read_image_iovl(AVFormatContext *s, const HEIFGrid *grid,
>>>        }
>>>        for (int i = 0; i < tile_grid->nb_tiles; i++) {
>>> +        if (!grid->tile_item_list[i]) {
>>> +            ret = AVERROR_INVALIDDATA;
>>> +            goto fail;
>>> +        }
>>
>> This should not happen. We shouldn't get this far if the array was not
>> filled.
>>
>> Can you please test the following?
>>
>>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>>> index 7bdeeb99f9..fb0113b149 100644
>>> --- a/libavformat/mov.c
>>> +++ b/libavformat/mov.c
>>> @@ -9397,8 +9397,9 @@ static int mov_parse_tiles(AVFormatContext *s)
>>>
>>>           for (int j = 0; j < grid->nb_tiles; j++) {
>>>               int tile_id = grid->tile_id_list[j];
>>> +            int k;
>>>
>>> -            for (int k = 0; k < mov->nb_heif_item; k++) {
>>> +            for (k = 0; k < mov->nb_heif_item; k++) {
>>>                   HEIFItem *item = &mov->heif_item[k];
>>>                   AVStream *st = item->st;
>>>
>>> @@ -9424,6 +9425,13 @@ static int mov_parse_tiles(AVFormatContext *s)
>>>                   break;
>>>               }
>>>
>>> +            if (k == grid->nb_tiles) {
>>> +                av_log(s, AV_LOG_WARNING, "HEIF item id %d referenced by grid id %d doesn't "
>>> +                                          "exist\n",
>>> +                       tile_id, grid->item->item_id);
>>> +                ff_remove_stream_group(s, stg);
>>> +                loop = 0;
>>> +            }
>>>               if (!loop)
>>>                   break;
>>>           }
> 
> i confirm the code fixes the issue, please apply (if it passes fate) and backport (if needed)

Applied and backported.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/6] tools/target_dec_fuzzer: Adjust threshold for RV30

[Michael Niedermayer]

Fixes: Timeout
Fixes: 67530/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV30_fuzzer-6635676118351872

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 tools/target_dec_fuzzer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index a6e6b2f27f7..e7633c6ad8f 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -279,6 +279,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
     case AV_CODEC_ID_RSCC:        maxpixels  /= 256;   break;
     case AV_CODEC_ID_RASC:        maxpixels  /= 16;    break;
     case AV_CODEC_ID_RTV1:        maxpixels  /= 16;    break;
+    case AV_CODEC_ID_RV30:        maxpixels  /= 16;    break;
     case AV_CODEC_ID_SANM:        maxpixels  /= 16;    break;
     case AV_CODEC_ID_SCPR:        maxpixels  /= 32;    break;
     case AV_CODEC_ID_SCREENPRESSO:maxpixels  /= 64;    break;
-- 
2.17.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/6] tools/target_dec_fuzzer: Adjust threshold for RV30

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 779 bytes --]

On Mon, Apr 01, 2024 at 10:56:04PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 67530/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV30_fuzzer-6635676118351872
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  tools/target_dec_fuzzer.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

[Michael Niedermayer]

Fixes: memleak
Fixes: 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/demux_utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
index 86f551245be..96e6e20d1ec 100644
--- a/libavformat/demux_utils.c
+++ b/libavformat/demux_utils.c
@@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream *st0, AVIOContext *pb,
     if (!st && !(st = avformat_new_stream(s, NULL)))
         return AVERROR(ENOMEM);
     pkt = &st->attached_pic;
+    av_packet_unref(pkt);
     if (buf) {
         av_assert1(*buf);
-        av_packet_unref(pkt);
         pkt->buf  = *buf;
         pkt->data = (*buf)->data;
         pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;
-- 
2.17.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

[Andreas Rheinhardt]

Michael Niedermayer:
> Fixes: memleak
> Fixes: 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavformat/demux_utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
> index 86f551245be..96e6e20d1ec 100644
> --- a/libavformat/demux_utils.c
> +++ b/libavformat/demux_utils.c
> @@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream *st0, AVIOContext *pb,
>      if (!st && !(st = avformat_new_stream(s, NULL)))
>          return AVERROR(ENOMEM);
>      pkt = &st->attached_pic;
> +    av_packet_unref(pkt);
>      if (buf) {
>          av_assert1(*buf);
> -        av_packet_unref(pkt);
>          pkt->buf  = *buf;
>          pkt->data = (*buf)->data;
>          pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;

This seems to be from the ff_add_attached_pic() call in
mov_read_chapters() with the referenced stream having been created in
mov_read_covr(). The latter does not set a proper id -- it just takes
what avformat_new_stream() sets as id on every new stream (namely zero).
So it makes no real sense to compare it to the ids contained in
chapter_tracks (can really every track be reinterpreted as chapter
track?). But I am no mov/mp4 expert.
Anyway, does the following fix it?

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7bdeeb99f9..51d97296f1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8820,7 +8820,7 @@ static void mov_read_chapters(AVFormatContext *s)

         if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
             st->disposition |= AV_DISPOSITION_ATTACHED_PIC |
AV_DISPOSITION_TIMED_THUMBNAILS;
-            if (sti->nb_index_entries) {
+            if (!st->attached_pic.data && sti->nb_index_entries) {
                 // Retrieve the first frame, if possible
                 AVIndexEntry *sample = &sti->index_entries[0];
                 if (avio_seek(sc->pb, sample->pos, SEEK_SET) !=
sample->pos) {
s

- Andreas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2734 bytes --]

On Mon, Apr 01, 2024 at 11:35:56PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: memleak
> > Fixes: 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >  libavformat/demux_utils.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
> > index 86f551245be..96e6e20d1ec 100644
> > --- a/libavformat/demux_utils.c
> > +++ b/libavformat/demux_utils.c
> > @@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream *st0, AVIOContext *pb,
> >      if (!st && !(st = avformat_new_stream(s, NULL)))
> >          return AVERROR(ENOMEM);
> >      pkt = &st->attached_pic;
> > +    av_packet_unref(pkt);
> >      if (buf) {
> >          av_assert1(*buf);
> > -        av_packet_unref(pkt);
> >          pkt->buf  = *buf;
> >          pkt->data = (*buf)->data;
> >          pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;
> 
> This seems to be from the ff_add_attached_pic() call in
> mov_read_chapters() with the referenced stream having been created in
> mov_read_covr(). The latter does not set a proper id -- it just takes
> what avformat_new_stream() sets as id on every new stream (namely zero).
> So it makes no real sense to compare it to the ids contained in
> chapter_tracks (can really every track be reinterpreted as chapter
> track?). But I am no mov/mp4 expert.
> Anyway, does the following fix it?
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7bdeeb99f9..51d97296f1 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -8820,7 +8820,7 @@ static void mov_read_chapters(AVFormatContext *s)
> 
>          if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
>              st->disposition |= AV_DISPOSITION_ATTACHED_PIC |
> AV_DISPOSITION_TIMED_THUMBNAILS;
> -            if (sti->nb_index_entries) {
> +            if (!st->attached_pic.data && sti->nb_index_entries) {
>                  // Retrieve the first frame, if possible
>                  AVIndexEntry *sample = &sti->index_entries[0];
>                  if (avio_seek(sc->pb, sample->pos, SEEK_SET) !=
> sample->pos) {
> s

Yes, this fixes it too, please apply and backport as needed

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/6] avcodec/hevc_ps: --typo

[Michael Niedermayer]

Fixes: null pointer dereference
Fixes: 67737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4858162608930816

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavcodec/hevc_ps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 38b3721a6d5..25f087ed754 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -460,7 +460,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
     int ret = AVERROR_INVALIDDATA;
     HEVCVPS *vps;
 
-    if (ps->pps_list[vps_id]) {
+    if (ps->vps_list[vps_id]) {
         const HEVCVPS *vps1 = ps->vps_list[vps_id];
         if (vps1->data_size == nal_size &&
             !memcmp(vps1->data, gb->buffer, vps1->data_size))
-- 
2.17.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/hevc_ps: --typo

[James Almer]

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> Fixes: null pointer dereference
> Fixes: 67737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4858162608930816
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>   libavcodec/hevc_ps.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 38b3721a6d5..25f087ed754 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -460,7 +460,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
>       int ret = AVERROR_INVALIDDATA;
>       HEVCVPS *vps;
>   
> -    if (ps->pps_list[vps_id]) {
> +    if (ps->vps_list[vps_id]) {
>           const HEVCVPS *vps1 = ps->vps_list[vps_id];
>           if (vps1->data_size == nal_size &&
>               !memcmp(vps1->data, gb->buffer, vps1->data_size))

LGTM.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/hevc_ps: --typo

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --]

On Tue, Apr 02, 2024 at 09:12:09AM -0300, James Almer wrote:
> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> > Fixes: null pointer dereference
> > Fixes: 67737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4858162608930816
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >   libavcodec/hevc_ps.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 38b3721a6d5..25f087ed754 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -460,7 +460,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
> >       int ret = AVERROR_INVALIDDATA;
> >       HEVCVPS *vps;
> > -    if (ps->pps_list[vps_id]) {
> > +    if (ps->vps_list[vps_id]) {
> >           const HEVCVPS *vps1 = ps->vps_list[vps_id];
> >           if (vps1->data_size == nal_size &&
> >               !memcmp(vps1->data, gb->buffer, vps1->data_size))
> 
> LGTM.

will apply

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 6/6] avcodec/apedec: Use NABS to avoid undefined negation

[Michael Niedermayer]

Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 67738/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5444313212321792

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavcodec/apedec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 86b79182a73..d75a85f4664 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1287,7 +1287,7 @@ static void predictor_decode_stereo_3950(APEContext *ctx, int count)
                 int32_t left  = a1 - (unsigned)(a0 / 2);
                 int32_t right = left + (unsigned)a0;
 
-                if (FFMAX(FFABS(left), FFABS(right)) > (1<<23)) {
+                if (FFMIN(FFNABS(left), FFNABS(right)) < -(1<<23)) {
                     ctx->interim_mode = !interim_mode;
                     av_log(ctx->avctx, AV_LOG_VERBOSE, "Interim mode: %d\n", ctx->interim_mode);
                     break;
-- 
2.17.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 6/6] avcodec/apedec: Use NABS to avoid undefined negation

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 771 bytes --]

On Mon, Apr 01, 2024 at 10:56:07PM +0200, Michael Niedermayer wrote:
> Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
> Fixes: 67738/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5444313212321792
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavcodec/apedec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[James Almer]

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes: 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>   libavformat/isom.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 9fbccd4437f..c5930bd4d87 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, AVStream *st, AVIOContext
>                                                   st->codecpar->extradata_size, 1, fc);
>               if (ret < 0)
>                   return ret;
> +            av_channel_layout_uninit(&st->codecpar->ch_layout);

Why is there a custom layout here to begin with? The caf demuxer doesn't 
export one.

>               st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
>               st->codecpar->ch_layout.nb_channels = cfg.channels;
>               if (cfg.object_type == 29 && cfg.sampling_index < 3) // old mp3on4
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[James Almer]

On 4/1/2024 6:25 PM, James Almer wrote:
> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
>> Fixes: memleak
>> Fixes: 
>> 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
>>
>> Found-by: continuous fuzzing process 
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>> ---
>>   libavformat/isom.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 9fbccd4437f..c5930bd4d87 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>> @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext 
>> *fc, AVStream *st, AVIOContext
>>                                                   
>> st->codecpar->extradata_size, 1, fc);
>>               if (ret < 0)
>>                   return ret;
>> +            av_channel_layout_uninit(&st->codecpar->ch_layout);
> 
> Why is there a custom layout here to begin with? The caf demuxer doesn't 
> export one.

Nevermind, it calls ff_mov_read_chan() which may generate one.

Patch LGTM.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[James Almer]

On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes: 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>   libavformat/isom.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 9fbccd4437f..c5930bd4d87 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, AVStream *st, AVIOContext
>                                                   st->codecpar->extradata_size, 1, fc);
>               if (ret < 0)
>                   return ret;
> +            av_channel_layout_uninit(&st->codecpar->ch_layout);
>               st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;

Not strictly related to this fix, but should we really drop the layout 
here by forcing unspec? We're also not even bothering to check if 
cfg.channels matches st->codecpar->ch_layout.nb_channels.

>               st->codecpar->ch_layout.nb_channels = cfg.channels;
>               if (cfg.object_type == 29 && cfg.sampling_index < 3) // old mp3on4
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1642 bytes --]

On Mon, Apr 01, 2024 at 06:33:22PM -0300, James Almer wrote:
> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
> > Fixes: memleak
> > Fixes: 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >   libavformat/isom.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavformat/isom.c b/libavformat/isom.c
> > index 9fbccd4437f..c5930bd4d87 100644
> > --- a/libavformat/isom.c
> > +++ b/libavformat/isom.c
> > @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, AVStream *st, AVIOContext
> >                                                   st->codecpar->extradata_size, 1, fc);
> >               if (ret < 0)
> >                   return ret;
> > +            av_channel_layout_uninit(&st->codecpar->ch_layout);
> >               st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
> 
> Not strictly related to this fix, but should we really drop the layout here
> by forcing unspec? We're also not even bothering to check if cfg.channels
> matches st->codecpar->ch_layout.nb_channels.

I was wondering the same.
I was hoping someone would know the specs well enouh to just say straight
"this and that isnt legal together error out if thats true"

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[James Almer]

On 4/1/2024 8:40 PM, Michael Niedermayer wrote:
> On Mon, Apr 01, 2024 at 06:33:22PM -0300, James Almer wrote:
>> On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
>>> Fixes: memleak
>>> Fixes: 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
>>>
>>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>> ---
>>>    libavformat/isom.c | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>>> index 9fbccd4437f..c5930bd4d87 100644
>>> --- a/libavformat/isom.c
>>> +++ b/libavformat/isom.c
>>> @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, AVStream *st, AVIOContext
>>>                                                    st->codecpar->extradata_size, 1, fc);
>>>                if (ret < 0)
>>>                    return ret;
>>> +            av_channel_layout_uninit(&st->codecpar->ch_layout);
>>>                st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
>>
>> Not strictly related to this fix, but should we really drop the layout here
>> by forcing unspec? We're also not even bothering to check if cfg.channels
>> matches st->codecpar->ch_layout.nb_channels.
> 
> I was wondering the same.
> I was hoping someone would know the specs well enouh to just say straight
> "this and that isnt legal together error out if thats true"

Maybe Marton knows, since he's been working on this code.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[Marton Balint]

On Mon, 1 Apr 2024, James Almer wrote:

> On 4/1/2024 8:40 PM, Michael Niedermayer wrote:
>>  On Mon, Apr 01, 2024 at 06:33:22PM -0300, James Almer wrote:
>>>  On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
>>>> Fixes:  memleak
>>>> Fixes:  67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
>>>>
>>>>  Found-by: continuous fuzzing process
>>>>  https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>>>  Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>>>  ---
>>>>     libavformat/isom.c | 1 +
>>>>     1 file changed, 1 insertion(+)
>>>>
>>>>  diff --git a/libavformat/isom.c b/libavformat/isom.c
>>>>  index 9fbccd4437f..c5930bd4d87 100644
>>>>  --- a/libavformat/isom.c
>>>>  +++ b/libavformat/isom.c
>>>>  @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext
>>>>  *fc, AVStream *st, AVIOContext
>>>>                                                     st->codecpar->extradata_size,
>>>>                 1, fc);
>>>>                 if (ret < 0)
>>>>                     return ret;
>>>>  +            av_channel_layout_uninit(&st->codecpar->ch_layout);
>>>>                 st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
>>>
>>>  Not strictly related to this fix, but should we really drop the layout
>>>  here
>>>  by forcing unspec? We're also not even bothering to check if cfg.channels
>>>  matches st->codecpar->ch_layout.nb_channels.
>>
>>  I was wondering the same.
>>  I was hoping someone would know the specs well enouh to just say straight
>>  "this and that isnt legal together error out if thats true"
>
> Maybe Marton knows, since he's been working on this code.

I don't really know for sure. But it would make sense to me to only drop 
the layout if the channel count is different from what we already know.

Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()

[James Almer]

On 4/2/2024 7:22 PM, Marton Balint wrote:
> 
> 
> On Mon, 1 Apr 2024, James Almer wrote:
> 
>> On 4/1/2024 8:40 PM, Michael Niedermayer wrote:
>>>  On Mon, Apr 01, 2024 at 06:33:22PM -0300, James Almer wrote:
>>>>  On 4/1/2024 5:56 PM, Michael Niedermayer wrote:
>>>>> Fixes:  memleak
>>>>> Fixes:  
>>>>> 67442/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5068813261406208
>>>>>
>>>>>  Found-by: continuous fuzzing process
>>>>>  https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>>>>  Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>>>>  ---
>>>>>     libavformat/isom.c | 1 +
>>>>>     1 file changed, 1 insertion(+)
>>>>>
>>>>>  diff --git a/libavformat/isom.c b/libavformat/isom.c
>>>>>  index 9fbccd4437f..c5930bd4d87 100644
>>>>>  --- a/libavformat/isom.c
>>>>>  +++ b/libavformat/isom.c
>>>>>  @@ -359,6 +359,7 @@ int ff_mp4_read_dec_config_descr(AVFormatContext
>>>>>  *fc, AVStream *st, AVIOContext
>>>>>                                                     
>>>>> st->codecpar->extradata_size,
>>>>>                 1, fc);
>>>>>                 if (ret < 0)
>>>>>                     return ret;
>>>>>  +            av_channel_layout_uninit(&st->codecpar->ch_layout);
>>>>>                 st->codecpar->ch_layout.order = 
>>>>> AV_CHANNEL_ORDER_UNSPEC;
>>>>
>>>>  Not strictly related to this fix, but should we really drop the layout
>>>>  here
>>>>  by forcing unspec? We're also not even bothering to check if 
>>>> cfg.channels
>>>>  matches st->codecpar->ch_layout.nb_channels.
>>>
>>>  I was wondering the same.
>>>  I was hoping someone would know the specs well enouh to just say 
>>> straight
>>>  "this and that isnt legal together error out if thats true"
>>
>> Maybe Marton knows, since he's been working on this code.
> 
> I don't really know for sure. But it would make sense to me to only drop 
> the layout if the channel count is different from what we already know.

Ok, just did that, and also applied Michael's memleak fix. Thanks.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".