Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture

2022-04-13 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Wednesday, April 13, 2022 11:43 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architecture
> 
> Soft Works (12022-04-12):
> > I have always asked you kindly
> 
> You have been repeatedly rude towards the people who know libavfilter
> well.

That treatment was exclusively reserved to yours. 
You had called for it.
You got it.
You deserved it.

> On top of that, you have shown that you do not understand how
> libavfilter currently works.
> On top of that, you have refused to learn how libavfilter currently
> works.

Exactly that's one of the reasons.
You keep throwing around exactly those kinds of statements without
substantial content.

That's purely demagogic behavior.
As a long as you continue like that, you don't deserve any 
better responses.

softworkz
___
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".


Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

2022-04-13 Thread Vignesh Venkatasubramanian
On Wed, Apr 13, 2022 at 2:04 PM Andreas Rheinhardt
 wrote:
>
> Vignesh Venkatasubramanian:
> > On Mon, Mar 21, 2022 at 1:46 PM Andreas Rheinhardt
> >  wrote:
> >>
> >> Vignesh Venkatasubramanian:
> >>> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
> >>>
> >>> AVIF Specifiation: https://aomediacodec.github.io/av1-avif
> >>>
> >>> Sample usage for still image:
> >>> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
> >>>
> >>> Sample usage for animated AVIF image:
> >>> ffmpeg -i video.mp4 animated.avif
> >>>
> >>> We can re-use any of the AV1 encoding options that will make
> >>> sense for image encoding (like bitrate, tiles, encoding speed,
> >>> etc).
> >>>
> >>> The files generated by this muxer has been verified to be valid
> >>> AVIF files by the following:
> >>> 1) Displays on Chrome (both still and animated images).
> >>> 2) Displays on Firefox (only still images, firefox does not support
> >>>animated AVIF yet).
> >>> 3) Verfied to be valid by Compliance Warden:
> >>>https://github.com/gpac/ComplianceWarden
> >>>
> >>> Fixes the encoder/muxer part of Trac Ticket #7621
> >>>
> >>> Signed-off-by: Vignesh Venkatasubramanian 
> >>> ---
> >>>  configure|   1 +
> >>>  libavformat/allformats.c |   1 +
> >>>  libavformat/movenc.c | 341 ---
> >>>  libavformat/movenc.h |   5 +
> >>>  4 files changed, 322 insertions(+), 26 deletions(-)
> >>>
> >>> diff --git a/configure b/configure
> >>> index 8c69ab0c86..6d7020e96b 100755
> >>> --- a/configure
> >>> +++ b/configure
> >>> @@ -3390,6 +3390,7 @@ asf_stream_muxer_select="asf_muxer"
> >>>  av1_demuxer_select="av1_frame_merge_bsf av1_parser"
> >>>  avi_demuxer_select="riffdec exif"
> >>>  avi_muxer_select="riffenc"
> >>> +avif_muxer_select="mov_muxer"
> >>>  caf_demuxer_select="iso_media"
> >>>  caf_muxer_select="iso_media"
> >>>  dash_muxer_select="mp4_muxer"
> >>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> >>> index d066a7745b..400c17afbd 100644
> >>> --- a/libavformat/allformats.c
> >>> +++ b/libavformat/allformats.c
> >>> @@ -81,6 +81,7 @@ extern const AVOutputFormat ff_au_muxer;
> >>>  extern const AVInputFormat  ff_av1_demuxer;
> >>>  extern const AVInputFormat  ff_avi_demuxer;
> >>>  extern const AVOutputFormat ff_avi_muxer;
> >>> +extern const AVOutputFormat ff_avif_muxer;
> >>>  extern const AVInputFormat  ff_avisynth_demuxer;
> >>>  extern const AVOutputFormat ff_avm2_muxer;
> >>>  extern const AVInputFormat  ff_avr_demuxer;
> >>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >>> index 1a746a67fd..ff41579300 100644
> >>> --- a/libavformat/movenc.c
> >>> +++ b/libavformat/movenc.c
> >>> @@ -1303,7 +1303,7 @@ static int mov_write_av1c_tag(AVIOContext *pb, 
> >>> MOVTrack *track)
> >>>
> >>>  avio_wb32(pb, 0);
> >>>  ffio_wfourcc(pb, "av1C");
> >>> -ff_isom_write_av1c(pb, track->vos_data, track->vos_len, 1);
> >>> +ff_isom_write_av1c(pb, track->vos_data, track->vos_len, track->mode 
> >>> != MODE_AVIF);
> >>>  return update_size(pb, pos);
> >>>  }
> >>>
> >>> @@ -2004,12 +2004,13 @@ static int mov_write_colr_tag(AVIOContext *pb, 
> >>> MOVTrack *track, int prefer_icc)
> >>>  }
> >>>  }
> >>>
> >>> -/* We should only ever be called by MOV or MP4. */
> >>> -av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4);
> >>> +/* We should only ever be called for MOV, MP4 and AVIF. */
> >>> +av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4 ||
> >>> +   track->mode == MODE_AVIF);
> >>>
> >>>  avio_wb32(pb, 0); /* size */
> >>>  ffio_wfourcc(pb, "colr");
> >>> -if (track->mode == MODE_MP4)
> >>> +if (track->mode == MODE_MP4 || track->mode == MODE_AVIF)
> >>>  ffio_wfourcc(pb, "nclx");
> >>>  else
> >>>  ffio_wfourcc(pb, "nclc");
> >>> @@ -2019,7 +2020,7 @@ static int mov_write_colr_tag(AVIOContext *pb, 
> >>> MOVTrack *track, int prefer_icc)
> >>>  avio_wb16(pb, track->par->color_primaries);
> >>>  avio_wb16(pb, track->par->color_trc);
> >>>  avio_wb16(pb, track->par->color_space);
> >>> -if (track->mode == MODE_MP4) {
> >>> +if (track->mode == MODE_MP4 || track->mode == MODE_AVIF) {
> >>>  int full_range = track->par->color_range == AVCOL_RANGE_JPEG;
> >>>  avio_w8(pb, full_range << 7);
> >>>  }
> >>> @@ -2085,7 +2086,7 @@ static void find_compressor(char * compressor_name, 
> >>> int len, MOVTrack *track)
> >>>|| (track->par->width == 1440 && track->par->height == 
> >>> 1080)
> >>>|| (track->par->width == 1920 && track->par->height == 
> >>> 1080);
> >>>
> >>> -if (track->mode == MODE_MOV &&
> >>> +if ((track->mode == MODE_AVIF || track->mode == MODE_MOV) &&
> >>>  (encoder = av_dict_get(track->st->metadata, "encoder", NULL, 
> >>> 0))) {
> >>>  av_strlcpy(compressor_name, encoder->value, 32);
> >>>  } else if 

Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

2022-04-13 Thread Vignesh Venkatasubramanian
On Wed, Apr 13, 2022 at 2:01 PM Andreas Rheinhardt
 wrote:
>
> Vignesh Venkatasubramanian:
> > Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
> >
> > AVIF Specification: https://aomediacodec.github.io/av1-avif
> >
> > Sample usage for still image:
> > ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
> >
> > Sample usage for animated AVIF image:
> > ffmpeg -i video.mp4 animated.avif
> >
> > We can re-use any of the AV1 encoding options that will make
> > sense for image encoding (like bitrate, tiles, encoding speed,
> > etc).
> >
> > The files generated by this muxer has been verified to be valid
> > AVIF files by the following:
> > 1) Displays on Chrome (both still and animated images).
> > 2) Displays on Firefox (only still images, firefox does not support
> >animated AVIF yet).
> > 3) Verified to be valid by Compliance Warden:
> >https://github.com/gpac/ComplianceWarden
> >
> > Fixes the encoder/muxer part of Trac Ticket #7621
> >
> > Signed-off-by: Vignesh Venkatasubramanian 
> > ---
> >  configure|   1 +
> >  libavformat/allformats.c |   1 +
> >  libavformat/movenc.c | 337 ---
> >  libavformat/movenc.h |   5 +
> >  4 files changed, 319 insertions(+), 25 deletions(-)
> >
> > +static int avif_write_trailer(AVFormatContext *s)
> > +{
> > +AVIOContext *pb = s->pb;
> > +MOVMuxContext *mov = s->priv_data;
> > +int64_t pos_backup, mdat_pos;
> > +uint8_t *buf;
> > +int buf_size, moov_size;
> > +
> > +if (mov->moov_written) return 0;
>
> Can it happen that moov_written is true? What happens if it is? (I
> presume the file to be invalid.)
>

This is more of a sanity check. I don't think this will ever happen
(as long as write_trailer is not called more than once). If you
prefer, i can remove it.

> > +
> > +mov->is_animated_avif = s->streams[0]->nb_frames > 1;
> > +mov_write_identification(pb, s);
> > +mov_write_meta_tag(pb, mov, s);
> > +
> > +moov_size = get_moov_size(s);
> > +mov->tracks[0].data_offset = avio_tell(pb) + moov_size + 8;
> > +
> > +if (mov->is_animated_avif) {
> > +int ret;
> > +if ((ret = mov_write_moov_tag(pb, mov, s)) < 0)
> > +return ret;
> > +}
> > +
> > +buf_size = avio_get_dyn_buf(mov->mdat_buf, );
> > +avio_wb32(pb, buf_size + 8);
> > +ffio_wfourcc(pb, "mdat");
> > +mdat_pos = avio_tell(pb);
> > +
> > +if (mdat_pos != (uint32_t)mdat_pos) {
> > +av_log(s, AV_LOG_ERROR, "mdat offset does not fit in 32 bits\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +avio_write(pb, buf, buf_size);
> > +
> > +// write extent offset.
> > +pos_backup = avio_tell(pb);
> > +avio_seek(pb, mov->avif_extent_pos, SEEK_SET);
> > +avio_wb32(pb, mdat_pos); /* rewrite offset */
> > +avio_seek(pb, pos_backup, SEEK_SET);
> > +
> > +return 0;
> > +}
> > +
>
> - 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-requ...@ffmpeg.org with subject "unsubscribe".



-- 
Vignesh
___
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".


Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

2022-04-13 Thread Andreas Rheinhardt
Vignesh Venkatasubramanian:
> On Mon, Mar 21, 2022 at 1:46 PM Andreas Rheinhardt
>  wrote:
>>
>> Vignesh Venkatasubramanian:
>>> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
>>>
>>> AVIF Specifiation: https://aomediacodec.github.io/av1-avif
>>>
>>> Sample usage for still image:
>>> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
>>>
>>> Sample usage for animated AVIF image:
>>> ffmpeg -i video.mp4 animated.avif
>>>
>>> We can re-use any of the AV1 encoding options that will make
>>> sense for image encoding (like bitrate, tiles, encoding speed,
>>> etc).
>>>
>>> The files generated by this muxer has been verified to be valid
>>> AVIF files by the following:
>>> 1) Displays on Chrome (both still and animated images).
>>> 2) Displays on Firefox (only still images, firefox does not support
>>>animated AVIF yet).
>>> 3) Verfied to be valid by Compliance Warden:
>>>https://github.com/gpac/ComplianceWarden
>>>
>>> Fixes the encoder/muxer part of Trac Ticket #7621
>>>
>>> Signed-off-by: Vignesh Venkatasubramanian 
>>> ---
>>>  configure|   1 +
>>>  libavformat/allformats.c |   1 +
>>>  libavformat/movenc.c | 341 ---
>>>  libavformat/movenc.h |   5 +
>>>  4 files changed, 322 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index 8c69ab0c86..6d7020e96b 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3390,6 +3390,7 @@ asf_stream_muxer_select="asf_muxer"
>>>  av1_demuxer_select="av1_frame_merge_bsf av1_parser"
>>>  avi_demuxer_select="riffdec exif"
>>>  avi_muxer_select="riffenc"
>>> +avif_muxer_select="mov_muxer"
>>>  caf_demuxer_select="iso_media"
>>>  caf_muxer_select="iso_media"
>>>  dash_muxer_select="mp4_muxer"
>>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>>> index d066a7745b..400c17afbd 100644
>>> --- a/libavformat/allformats.c
>>> +++ b/libavformat/allformats.c
>>> @@ -81,6 +81,7 @@ extern const AVOutputFormat ff_au_muxer;
>>>  extern const AVInputFormat  ff_av1_demuxer;
>>>  extern const AVInputFormat  ff_avi_demuxer;
>>>  extern const AVOutputFormat ff_avi_muxer;
>>> +extern const AVOutputFormat ff_avif_muxer;
>>>  extern const AVInputFormat  ff_avisynth_demuxer;
>>>  extern const AVOutputFormat ff_avm2_muxer;
>>>  extern const AVInputFormat  ff_avr_demuxer;
>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> index 1a746a67fd..ff41579300 100644
>>> --- a/libavformat/movenc.c
>>> +++ b/libavformat/movenc.c
>>> @@ -1303,7 +1303,7 @@ static int mov_write_av1c_tag(AVIOContext *pb, 
>>> MOVTrack *track)
>>>
>>>  avio_wb32(pb, 0);
>>>  ffio_wfourcc(pb, "av1C");
>>> -ff_isom_write_av1c(pb, track->vos_data, track->vos_len, 1);
>>> +ff_isom_write_av1c(pb, track->vos_data, track->vos_len, track->mode != 
>>> MODE_AVIF);
>>>  return update_size(pb, pos);
>>>  }
>>>
>>> @@ -2004,12 +2004,13 @@ static int mov_write_colr_tag(AVIOContext *pb, 
>>> MOVTrack *track, int prefer_icc)
>>>  }
>>>  }
>>>
>>> -/* We should only ever be called by MOV or MP4. */
>>> -av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4);
>>> +/* We should only ever be called for MOV, MP4 and AVIF. */
>>> +av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4 ||
>>> +   track->mode == MODE_AVIF);
>>>
>>>  avio_wb32(pb, 0); /* size */
>>>  ffio_wfourcc(pb, "colr");
>>> -if (track->mode == MODE_MP4)
>>> +if (track->mode == MODE_MP4 || track->mode == MODE_AVIF)
>>>  ffio_wfourcc(pb, "nclx");
>>>  else
>>>  ffio_wfourcc(pb, "nclc");
>>> @@ -2019,7 +2020,7 @@ static int mov_write_colr_tag(AVIOContext *pb, 
>>> MOVTrack *track, int prefer_icc)
>>>  avio_wb16(pb, track->par->color_primaries);
>>>  avio_wb16(pb, track->par->color_trc);
>>>  avio_wb16(pb, track->par->color_space);
>>> -if (track->mode == MODE_MP4) {
>>> +if (track->mode == MODE_MP4 || track->mode == MODE_AVIF) {
>>>  int full_range = track->par->color_range == AVCOL_RANGE_JPEG;
>>>  avio_w8(pb, full_range << 7);
>>>  }
>>> @@ -2085,7 +2086,7 @@ static void find_compressor(char * compressor_name, 
>>> int len, MOVTrack *track)
>>>|| (track->par->width == 1440 && track->par->height == 
>>> 1080)
>>>|| (track->par->width == 1920 && track->par->height == 
>>> 1080);
>>>
>>> -if (track->mode == MODE_MOV &&
>>> +if ((track->mode == MODE_AVIF || track->mode == MODE_MOV) &&
>>>  (encoder = av_dict_get(track->st->metadata, "encoder", NULL, 0))) {
>>>  av_strlcpy(compressor_name, encoder->value, 32);
>>>  } else if (track->par->codec_id == AV_CODEC_ID_MPEG2VIDEO && 
>>> xdcam_res) {
>>> @@ -2106,6 +2107,25 @@ static void find_compressor(char * compressor_name, 
>>> int len, MOVTrack *track)
>>>  }
>>>  }
>>>
>>> +static int mov_write_ccst_tag(AVIOContext *pb)
>>> +{
>>> +int64_t pos = avio_tell(pb);
>>> +   

Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

2022-04-13 Thread Andreas Rheinhardt
Vignesh Venkatasubramanian:
> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
> 
> AVIF Specification: https://aomediacodec.github.io/av1-avif
> 
> Sample usage for still image:
> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
> 
> Sample usage for animated AVIF image:
> ffmpeg -i video.mp4 animated.avif
> 
> We can re-use any of the AV1 encoding options that will make
> sense for image encoding (like bitrate, tiles, encoding speed,
> etc).
> 
> The files generated by this muxer has been verified to be valid
> AVIF files by the following:
> 1) Displays on Chrome (both still and animated images).
> 2) Displays on Firefox (only still images, firefox does not support
>animated AVIF yet).
> 3) Verified to be valid by Compliance Warden:
>https://github.com/gpac/ComplianceWarden
> 
> Fixes the encoder/muxer part of Trac Ticket #7621
> 
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  configure|   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/movenc.c | 337 ---
>  libavformat/movenc.h |   5 +
>  4 files changed, 319 insertions(+), 25 deletions(-)
> 
> +static int avif_write_trailer(AVFormatContext *s)
> +{
> +AVIOContext *pb = s->pb;
> +MOVMuxContext *mov = s->priv_data;
> +int64_t pos_backup, mdat_pos;
> +uint8_t *buf;
> +int buf_size, moov_size;
> +
> +if (mov->moov_written) return 0;

Can it happen that moov_written is true? What happens if it is? (I
presume the file to be invalid.)

> +
> +mov->is_animated_avif = s->streams[0]->nb_frames > 1;
> +mov_write_identification(pb, s);
> +mov_write_meta_tag(pb, mov, s);
> +
> +moov_size = get_moov_size(s);
> +mov->tracks[0].data_offset = avio_tell(pb) + moov_size + 8;
> +
> +if (mov->is_animated_avif) {
> +int ret;
> +if ((ret = mov_write_moov_tag(pb, mov, s)) < 0)
> +return ret;
> +}
> +
> +buf_size = avio_get_dyn_buf(mov->mdat_buf, );
> +avio_wb32(pb, buf_size + 8);
> +ffio_wfourcc(pb, "mdat");
> +mdat_pos = avio_tell(pb);
> +
> +if (mdat_pos != (uint32_t)mdat_pos) {
> +av_log(s, AV_LOG_ERROR, "mdat offset does not fit in 32 bits\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +avio_write(pb, buf, buf_size);
> +
> +// write extent offset.
> +pos_backup = avio_tell(pb);
> +avio_seek(pb, mov->avif_extent_pos, SEEK_SET);
> +avio_wb32(pb, mdat_pos); /* rewrite offset */
> +avio_seek(pb, pos_backup, SEEK_SET);
> +
> +return 0;
> +}
> +

- 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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

2022-04-13 Thread Vignesh Venkatasubramanian
On Wed, Apr 13, 2022 at 10:22 AM James Zern  wrote:
>
> On Mon, Mar 28, 2022 at 1:49 PM Vignesh Venkatasubramanian
>  wrote:
> >
> > Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
> >
> > AVIF Specifiation: https://aomediacodec.github.io/av1-avif
> >
>
> Specification
>

Fixed.

> > Sample usage for still image:
> > ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
> >
> > Sample usage for animated AVIF image:
> > ffmpeg -i video.mp4 animated.avif
> >
> > We can re-use any of the AV1 encoding options that will make
> > sense for image encoding (like bitrate, tiles, encoding speed,
> > etc).
> >
> > The files generated by this muxer has been verified to be valid
> > AVIF files by the following:
> > 1) Displays on Chrome (both still and animated images).
> > 2) Displays on Firefox (only still images, firefox does not support
> >animated AVIF yet).
> > 3) Verfied to be valid by Compliance Warden:
>
> Verified
>

Fixed.

> >https://github.com/gpac/ComplianceWarden
> >
> > Fixes the encoder/muxer part of Trac Ticket #7621
> >
> > Signed-off-by: Vignesh Venkatasubramanian 
> > ---
> >  configure|   1 +
> >  libavformat/allformats.c |   1 +
> >  libavformat/movenc.c | 337 ---
> >  libavformat/movenc.h |   5 +
> >  4 files changed, 319 insertions(+), 25 deletions(-)
> >
>
> There might be some other issues, you can try tools/patcheck.
>

Thanks, i ran this and only found a couple of other "} before else-if"
warnings. In those cases, i was just being consistent with the code
around it.

> > [...]
> > @@ -5068,6 +5231,31 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
> > AVFormatContext *s)
> >  // compatible brand a second time.
> >  if (mov->mode == MODE_ISM) {
> >  ffio_wfourcc(pb, "piff");
> > +} else if (mov->mode == MODE_AVIF) {
> > +const AVPixFmtDescriptor *pix_fmt_desc =
> > +av_pix_fmt_desc_get(s->streams[0]->codecpar->format);
> > +const int depth = pix_fmt_desc->comp[0].depth;
> > +if (mov->is_animated_avif) {
> > +// For animated AVIF, major brand is "avis". Add "avif" as a
> > +// compatible brand.
> > +ffio_wfourcc(pb, "avif");
> > +ffio_wfourcc(pb, "msf1");
> > +ffio_wfourcc(pb, "iso8");
> > +}
> > +ffio_wfourcc(pb, "mif1");
> > +ffio_wfourcc(pb, "miaf");
> > +if (depth == 8 || depth == 10) {
> > +// MA1B and MA1A brands are based on AV1 profile. Short hand 
> > for
> > +// computing that is based on chroma subsampling type. 420 
> > chroma
> > +// subsampling is MA1B.  444 chroma subsampling is MA1A.
> > +if (pix_fmt_desc->log2_chroma_w == 0 && 
> > pix_fmt_desc->log2_chroma_h == 0) {
>
> !... is the preferred style.

Done.

>
> > @@ -6773,12 +6983,13 @@ static int mov_init(AVFormatContext *s)
> >  pix_fmt == AV_PIX_FMT_MONOWHITE ||
> >  pix_fmt == AV_PIX_FMT_MONOBLACK;
> >  }
> > -if (track->par->codec_id == AV_CODEC_ID_VP9 ||
> > -track->par->codec_id == AV_CODEC_ID_AV1) {
> > -if (track->mode != MODE_MP4) {
> > -av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n", 
> > avcodec_get_name(track->par->codec_id));
> > -return AVERROR(EINVAL);
> > -}
> > +if (track->par->codec_id == AV_CODEC_ID_VP9 && track->mode != 
> > MODE_MP4) {
> > +av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n", 
> > avcodec_get_name(track->par->codec_id));
> > +   return AVERROR(EINVAL);
>
> This is indented with tabs.

Oops, fixed.

-- 
Vignesh
___
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".


[FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

2022-04-13 Thread Vignesh Venkatasubramanian
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.

AVIF Specification: https://aomediacodec.github.io/av1-avif

Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif

Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif

We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).

The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
   animated AVIF yet).
3) Verified to be valid by Compliance Warden:
   https://github.com/gpac/ComplianceWarden

Fixes the encoder/muxer part of Trac Ticket #7621

Signed-off-by: Vignesh Venkatasubramanian 
---
 configure|   1 +
 libavformat/allformats.c |   1 +
 libavformat/movenc.c | 337 ---
 libavformat/movenc.h |   5 +
 4 files changed, 319 insertions(+), 25 deletions(-)

diff --git a/configure b/configure
index 358a614854..ef9d6cdc92 100755
--- a/configure
+++ b/configure
@@ -3398,6 +3398,7 @@ asf_stream_muxer_select="asf_muxer"
 av1_demuxer_select="av1_frame_merge_bsf av1_parser"
 avi_demuxer_select="riffdec exif"
 avi_muxer_select="riffenc"
+avif_muxer_select="mov_muxer"
 caf_demuxer_select="iso_media"
 caf_muxer_select="iso_media"
 dash_muxer_select="mp4_muxer"
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 7c1d0ac38f..320ddf9898 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -81,6 +81,7 @@ extern const AVOutputFormat ff_au_muxer;
 extern const AVInputFormat  ff_av1_demuxer;
 extern const AVInputFormat  ff_avi_demuxer;
 extern const AVOutputFormat ff_avi_muxer;
+extern const AVOutputFormat ff_avif_muxer;
 extern const AVInputFormat  ff_avisynth_demuxer;
 extern const AVOutputFormat ff_avm2_muxer;
 extern const AVInputFormat  ff_avr_demuxer;
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 4202d0b79a..302ee1fda5 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1334,7 +1334,7 @@ static int mov_write_av1c_tag(AVIOContext *pb, MOVTrack 
*track)
 
 avio_wb32(pb, 0);
 ffio_wfourcc(pb, "av1C");
-ff_isom_write_av1c(pb, track->vos_data, track->vos_len, 1);
+ff_isom_write_av1c(pb, track->vos_data, track->vos_len, track->mode != 
MODE_AVIF);
 return update_size(pb, pos);
 }
 
@@ -2035,12 +2035,13 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack 
*track, int prefer_icc)
 }
 }
 
-/* We should only ever be called by MOV or MP4. */
-av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4);
+/* We should only ever be called for MOV, MP4 and AVIF. */
+av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4 ||
+   track->mode == MODE_AVIF);
 
 avio_wb32(pb, 0); /* size */
 ffio_wfourcc(pb, "colr");
-if (track->mode == MODE_MP4)
+if (track->mode == MODE_MP4 || track->mode == MODE_AVIF)
 ffio_wfourcc(pb, "nclx");
 else
 ffio_wfourcc(pb, "nclc");
@@ -2050,7 +2051,7 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack 
*track, int prefer_icc)
 avio_wb16(pb, track->par->color_primaries);
 avio_wb16(pb, track->par->color_trc);
 avio_wb16(pb, track->par->color_space);
-if (track->mode == MODE_MP4) {
+if (track->mode == MODE_MP4 || track->mode == MODE_AVIF) {
 int full_range = track->par->color_range == AVCOL_RANGE_JPEG;
 avio_w8(pb, full_range << 7);
 }
@@ -2116,7 +2117,7 @@ static void find_compressor(char * compressor_name, int 
len, MOVTrack *track)
   || (track->par->width == 1440 && track->par->height == 1080)
   || (track->par->width == 1920 && track->par->height == 1080);
 
-if (track->mode == MODE_MOV &&
+if ((track->mode == MODE_AVIF || track->mode == MODE_MOV) &&
 (encoder = av_dict_get(track->st->metadata, "encoder", NULL, 0))) {
 av_strlcpy(compressor_name, encoder->value, 32);
 } else if (track->par->codec_id == AV_CODEC_ID_MPEG2VIDEO && xdcam_res) {
@@ -2137,6 +2138,25 @@ static void find_compressor(char * compressor_name, int 
len, MOVTrack *track)
 }
 }
 
+static int mov_write_ccst_tag(AVIOContext *pb)
+{
+int64_t pos = avio_tell(pb);
+// Write sane defaults:
+// all_ref_pics_intra = 0 : all samples can use any type of reference.
+// intra_pred_used = 1 : intra prediction may or may not be used.
+// max_ref_per_pic = 15 : reserved value to indicate that any number of
+//reference images can be used.
+uint8_t ccstValue = (0 << 7) |  /* all_ref_pics_intra */
+(1 << 6) |  /* intra_pred_used */
+(15 << 2);  /* max_ref_per_pic */
+avio_wb32(pb, 0); /* size */
+ffio_wfourcc(pb, "ccst");
+avio_wb32(pb, 0); /* Version 

[FFmpeg-devel] [PATCH 2/3] avformat/av1: Add a parameter to av1c to omit seq header

2022-04-13 Thread Vignesh Venkatasubramanian
Add a parameter to omit seq header when generating the av1C atom.

For now, this does not change any behavior. This will be used by a
follow-up patch to add AVIF support.

Signed-off-by: Vignesh Venkatasubramanian 
---
 libavformat/av1.c | 7 +--
 libavformat/av1.h | 4 +++-
 libavformat/matroskaenc.c | 4 ++--
 libavformat/movenc.c  | 2 +-
 4 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/libavformat/av1.c b/libavformat/av1.c
index 79065d0c9f..b6eaf50627 100644
--- a/libavformat/av1.c
+++ b/libavformat/av1.c
@@ -395,7 +395,8 @@ int ff_av1_parse_seq_header(AV1SequenceParameters *seq, 
const uint8_t *buf, int
 return is_av1c ? 0 : AVERROR_INVALIDDATA;
 }
 
-int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf, int size)
+int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf, int size,
+   int write_seq_header)
 {
 AVIOContext *meta_pb;
 AV1SequenceParameters seq_params;
@@ -485,7 +486,9 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf, 
int size)
 flush_put_bits();
 
 avio_write(pb, header, sizeof(header));
-avio_write(pb, seq, seq_size);
+if (write_seq_header) {
+avio_write(pb, seq, seq_size);
+}
 
 meta_size = avio_get_dyn_buf(meta_pb, );
 if (meta_size)
diff --git a/libavformat/av1.h b/libavformat/av1.h
index f57dabe986..a393fbb78f 100644
--- a/libavformat/av1.h
+++ b/libavformat/av1.h
@@ -96,9 +96,11 @@ int ff_av1_parse_seq_header(AV1SequenceParameters *seq, 
const uint8_t *buf, int
  * @param pb pointer to the AVIOContext where the av1C box shall be written
  * @param buf input data buffer
  * @param size size in bytes of the input data buffer
+ * @param write_seq_header If 1, Sequence Header OBU will be written inside the
+ *   av1C box. Otherwise, Sequence Header OBU will be omitted.
  *
  * @return >= 0 in case of success, a negative AVERROR code in case of failure
  */
-int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf, int size);
+int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf, int size, int 
write_seq_header);
 
 #endif /* AVFORMAT_AV1_H */
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 3b8ca11f28..d789a618a4 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1089,7 +1089,7 @@ static int mkv_write_native_codecprivate(AVFormatContext 
*s, AVIOContext *pb,
 case AV_CODEC_ID_AV1:
 if (par->extradata_size)
 return ff_isom_write_av1c(dyn_cp, par->extradata,
-  par->extradata_size);
+  par->extradata_size, 1);
 else
 put_ebml_void(pb, 4 + 3);
 break;
@@ -2665,7 +2665,7 @@ static int mkv_check_new_extra_data(AVFormatContext *s, 
const AVPacket *pkt)
 ret = avio_open_dyn_buf(_cp);
 if (ret < 0)
 return ret;
-ff_isom_write_av1c(dyn_cp, side_data, side_data_size);
+ff_isom_write_av1c(dyn_cp, side_data, side_data_size, 1);
 codecpriv_size = avio_get_dyn_buf(dyn_cp, );
 if ((ret = dyn_cp->error) < 0 ||
 !codecpriv_size && (ret = AVERROR_INVALIDDATA)) {
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b9956e699c..4202d0b79a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1334,7 +1334,7 @@ static int mov_write_av1c_tag(AVIOContext *pb, MOVTrack 
*track)
 
 avio_wb32(pb, 0);
 ffio_wfourcc(pb, "av1C");
-ff_isom_write_av1c(pb, track->vos_data, track->vos_len);
+ff_isom_write_av1c(pb, track->vos_data, track->vos_len, 1);
 return update_size(pb, pos);
 }
 
-- 
2.35.1.1178.g4f1659d476-goog

___
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".


[FFmpeg-devel] [PATCH 1/3] avcodec/libaomenc: Add parameter for avif single image encoding

2022-04-13 Thread Vignesh Venkatasubramanian
Add a parameter to libaom-av1 encoder to enforce some of the single
image constraints in the AV1 encoder. Setting this flag will limit
the encoder to producing exactly one frame and the sequence header
that is produced by the encoder will be conformant to the AVIF
specification [1].

Part of Fixing Trac ticket #7621

[1] https://aomediacodec.github.io/av1-avif

Signed-off-by:: Vignesh Venkatasubramanian 
---
 libavcodec/libaomenc.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 054903e6e2..0411773bbf 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -100,6 +100,7 @@ typedef struct AOMEncoderContext {
 int enable_restoration;
 int usage;
 int tune;
+int still_picture;
 int enable_rect_partitions;
 int enable_1to4_partitions;
 int enable_ab_partitions;
@@ -747,6 +748,18 @@ static av_cold int aom_init(AVCodecContext *avctx,
 if (res < 0)
 return res;
 
+if (ctx->still_picture) {
+// Set the maximum number of frames to 1. This will let libaom set
+// still_picture and reduced_still_picture_header to 1 in the Sequence
+// Header as required by AVIF still images.
+enccfg.g_limit = 1;
+// Reduce memory usage for still images.
+enccfg.g_lag_in_frames = 0;
+// All frames will be key frames.
+enccfg.kf_max_dist = 0;
+enccfg.kf_mode = AOM_KF_DISABLED;
+}
+
 /* Construct Encoder Context */
 res = aom_codec_enc_init(>encoder, iface, , flags);
 if (res != AOM_CODEC_OK) {
@@ -1291,6 +1304,7 @@ static const AVOption options[] = {
 { "psnr",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
AOM_TUNE_PSNR}, 0, 0, VE, "tune"},
 { "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
AOM_TUNE_SSIM}, 0, 0, VE, "tune"},
 FF_AV1_PROFILE_OPTS
+{ "still-picture", "Encode in single frame mode (typically used for still 
AVIF images).", OFFSET(still_picture), AV_OPT_TYPE_BOOL, {.i64 = 0}, -1, 1, VE 
},
 { "enable-rect-partitions", "Enable rectangular partitions", 
OFFSET(enable_rect_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-1to4-partitions", "Enable 1:4/4:1 partitions", 
OFFSET(enable_1to4_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-ab-partitions",   "Enable ab shape partitions",
OFFSET(enable_ab_partitions),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
-- 
2.35.1.1178.g4f1659d476-goog

___
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".


Re: [FFmpeg-devel] [PATCH 1/1] librtmp: use AVBPrint instead of char *

2022-04-13 Thread Martin Storsjö

On Wed, 13 Apr 2022, Marton Balint wrote:




On Wed, 13 Apr 2022, Martin Storsjö wrote:


On Mon, 11 Apr 2022, Tristan Matthews wrote:

 This avoids having to do one pass to calculate the full length to 

allocate

 followed by a second pass to actually append values.
 ---
 libavformat/librtmp.c | 123 +++---
 1 file changed, 32 insertions(+), 91 deletions(-)


Thanks, this patch looks good to me. I'll wait for a little while still if 
Marton wants to comment on it, before I go ahead and push it.


According to commit 865461099e062de5a3a109c2a5be98004c11d8bd the buffer 
passed to RTMP_SetupURL has to be kept as long as the RTMP context is 
alive.


Oh, excellent catch, thanks!

// Martin
___
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".


Re: [FFmpeg-devel] [PATCH 1/1] librtmp: use AVBPrint instead of char *

2022-04-13 Thread Marton Balint



On Wed, 13 Apr 2022, Martin Storsjö wrote:


On Mon, 11 Apr 2022, Tristan Matthews wrote:


 This avoids having to do one pass to calculate the full length to allocate
 followed by a second pass to actually append values.
 ---
 libavformat/librtmp.c | 123 +++---
 1 file changed, 32 insertions(+), 91 deletions(-)


Thanks, this patch looks good to me. I'll wait for a little while still if 
Marton wants to comment on it, before I go ahead and push it.


According to commit 865461099e062de5a3a109c2a5be98004c11d8bd the buffer 
passed to RTMP_SetupURL has to be kept as long as the RTMP context is 
alive.


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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

2022-04-13 Thread James Zern
On Mon, Mar 28, 2022 at 1:49 PM Vignesh Venkatasubramanian
 wrote:
>
> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
>
> AVIF Specifiation: https://aomediacodec.github.io/av1-avif
>

Specification

> Sample usage for still image:
> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
>
> Sample usage for animated AVIF image:
> ffmpeg -i video.mp4 animated.avif
>
> We can re-use any of the AV1 encoding options that will make
> sense for image encoding (like bitrate, tiles, encoding speed,
> etc).
>
> The files generated by this muxer has been verified to be valid
> AVIF files by the following:
> 1) Displays on Chrome (both still and animated images).
> 2) Displays on Firefox (only still images, firefox does not support
>animated AVIF yet).
> 3) Verfied to be valid by Compliance Warden:

Verified

>https://github.com/gpac/ComplianceWarden
>
> Fixes the encoder/muxer part of Trac Ticket #7621
>
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  configure|   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/movenc.c | 337 ---
>  libavformat/movenc.h |   5 +
>  4 files changed, 319 insertions(+), 25 deletions(-)
>

There might be some other issues, you can try tools/patcheck.

> [...]
> @@ -5068,6 +5231,31 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
> AVFormatContext *s)
>  // compatible brand a second time.
>  if (mov->mode == MODE_ISM) {
>  ffio_wfourcc(pb, "piff");
> +} else if (mov->mode == MODE_AVIF) {
> +const AVPixFmtDescriptor *pix_fmt_desc =
> +av_pix_fmt_desc_get(s->streams[0]->codecpar->format);
> +const int depth = pix_fmt_desc->comp[0].depth;
> +if (mov->is_animated_avif) {
> +// For animated AVIF, major brand is "avis". Add "avif" as a
> +// compatible brand.
> +ffio_wfourcc(pb, "avif");
> +ffio_wfourcc(pb, "msf1");
> +ffio_wfourcc(pb, "iso8");
> +}
> +ffio_wfourcc(pb, "mif1");
> +ffio_wfourcc(pb, "miaf");
> +if (depth == 8 || depth == 10) {
> +// MA1B and MA1A brands are based on AV1 profile. Short hand for
> +// computing that is based on chroma subsampling type. 420 chroma
> +// subsampling is MA1B.  444 chroma subsampling is MA1A.
> +if (pix_fmt_desc->log2_chroma_w == 0 && 
> pix_fmt_desc->log2_chroma_h == 0) {

!... is the preferred style.

> @@ -6773,12 +6983,13 @@ static int mov_init(AVFormatContext *s)
>  pix_fmt == AV_PIX_FMT_MONOWHITE ||
>  pix_fmt == AV_PIX_FMT_MONOBLACK;
>  }
> -if (track->par->codec_id == AV_CODEC_ID_VP9 ||
> -track->par->codec_id == AV_CODEC_ID_AV1) {
> -if (track->mode != MODE_MP4) {
> -av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n", 
> avcodec_get_name(track->par->codec_id));
> -return AVERROR(EINVAL);
> -}
> +if (track->par->codec_id == AV_CODEC_ID_VP9 && track->mode != 
> MODE_MP4) {
> +av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n", 
> avcodec_get_name(track->par->codec_id));
> +   return AVERROR(EINVAL);

This is indented with tabs.
___
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".


[FFmpeg-devel] [PATCH 2/2] avdevice/dshow: silence warnings about unused variable

2022-04-13 Thread James Almer
Use av_unused instead of wrapping the declaration under the DSHOWDEBUG check
in case future changes make use of it.

Signed-off-by: James Almer 
---
 libavdevice/dshow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index ac8b64366f..6277a27453 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -976,7 +976,7 @@ dshow_cycle_formats(AVFormatContext *avctx, enum 
dshowDeviceType devtype,
 }
 } else {
 WAVEFORMATEX *fx;
-AUDIO_STREAM_CONFIG_CAPS *acaps = caps;
+AUDIO_STREAM_CONFIG_CAPS av_unused *acaps = caps;
 #if DSHOWDEBUG
 ff_print_AUDIO_STREAM_CONFIG_CAPS(acaps);
 #endif
-- 
2.35.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-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 1/2] avdevice/dshow: remove unused variables

2022-04-13 Thread James Almer
Remnant from f125c504d8fece6420bb97767f9e72414c26312a

Signed-off-by: James Almer 
---
 libavdevice/dshow.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 1e69620880..ac8b64366f 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -814,10 +814,6 @@ dshow_cycle_formats(AVFormatContext *avctx, enum 
dshowDeviceType devtype,
 / 
ctx->requested_framerate.num : 0;
 int requested_width   = ctx->requested_width;
 int requested_height  = ctx->requested_height;
-// audio
-int requested_sample_rate = ctx->sample_rate;
-int requested_sample_size = ctx->sample_size;
-int requested_channels= ctx->channels;
 
 if (IPin_QueryInterface(pin, _IAMStreamConfig, (void **) ) != 
S_OK)
 return;
@@ -854,10 +850,6 @@ dshow_cycle_formats(AVFormatContext *avctx, enum 
dshowDeviceType devtype,
 requested_framerate  = fmt_info->framerate;
 requested_width  = fmt_info->width;
 requested_height = fmt_info->height;
-} else {
-requested_sample_rate = fmt_info->sample_rate;
-requested_sample_size = fmt_info->sample_size;
-requested_channels= fmt_info->channels;
 }
 av_free(fmt_info);  // free but don't set to NULL to enable 
below check
 }
-- 
2.35.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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/4] avcodec/avcodec: Don't reset decoder-fields for encoders when flushing

2022-04-13 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2022-04-13 17:58:08)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2022-04-13 16:49:51)
> >> -
> >> -avctx->pts_correction_last_pts =
> >> -avctx->pts_correction_last_dts = INT64_MIN;
> >> -
> >> -if (avci->bsf)
> > 
> > did you drop this check on purpose?
> > 
> 
> Yes. We currently open bsfs for all decoders (even if it is a null-bsf).

Then patch lgtm

-- 
Anton Khirnov
___
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".


Re: [FFmpeg-devel] [PATCH 3/4] avcodec/avcodec: Don't reset decoder-fields for encoders when flushing

2022-04-13 Thread Andreas Rheinhardt
Anton Khirnov:
> Quoting Andreas Rheinhardt (2022-04-13 16:49:51)
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> Needs to be applied before
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294507.html
>> or flushing an encoder will segfault.
>> Btw: All this stuff is unused by subtitle decoders,
>> so one could condition the else on that and avoid the allocations.
>>
>>  libavcodec/avcodec.c | 23 +++
>>  1 file changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
>> index ded6b5b307..0d971a61d4 100644
>> --- a/libavcodec/avcodec.c
>> +++ b/libavcodec/avcodec.c
>> @@ -422,6 +422,17 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
>>  }
>>  if (avci->in_frame)
>>  av_frame_unref(avci->in_frame);
>> +} else {
>> +av_packet_unref(avci->last_pkt_props);
>> +while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
>> +av_packet_unref(avci->last_pkt_props);
>> +
>> +av_packet_unref(avci->in_pkt);
>> +
>> +avctx->pts_correction_last_pts =
>> +avctx->pts_correction_last_dts = INT64_MIN;
>> +
>> +av_bsf_flush(avci->bsf);
>>  }
>>  
>>  avci->draining  = 0;
>> @@ -430,22 +441,10 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
>>  av_frame_unref(avci->buffer_frame);
>>  av_packet_unref(avci->buffer_pkt);
>>  
>> -av_packet_unref(avci->last_pkt_props);
>> -while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
>> -av_packet_unref(avci->last_pkt_props);
>> -
>> -av_packet_unref(avci->in_pkt);
>> -
>>  if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
>>  ff_thread_flush(avctx);
>>  else if (ffcodec(avctx->codec)->flush)
>>  ffcodec(avctx->codec)->flush(avctx);
>> -
>> -avctx->pts_correction_last_pts =
>> -avctx->pts_correction_last_dts = INT64_MIN;
>> -
>> -if (avci->bsf)
> 
> did you drop this check on purpose?
> 

Yes. We currently open bsfs for all decoders (even if it is a null-bsf).

- 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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/4] avcodec/encode: Fix check for encoders impl. encode-simple API

2022-04-13 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2022-04-13 16:43:28)
> FFCodec.cb is a union.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/encode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index 6ae47b736c..e7ae2cd4c1 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -589,7 +589,7 @@ int ff_encode_preinit(AVCodecContext *avctx)
>  if (avctx->codec_descriptor->props & AV_CODEC_PROP_INTRA_ONLY)
>  avctx->internal->intra_only_flag = AV_PKT_FLAG_KEY;
>  
> -if (ffcodec(avctx->codec)->cb.encode) {
> +if (ffcodec(avctx->codec)->cb_type == FF_CODEC_CB_TYPE_ENCODE) {
>  avci->in_frame = av_frame_alloc();
>  if (!avci->in_frame)
>  return AVERROR(ENOMEM);
> -- 
> 2.32.0

Patches 1, 2, 4 look good.

Thank you and sorry for the breakage.

-- 
Anton Khirnov
___
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".


Re: [FFmpeg-devel] [PATCH 3/4] avcodec/avcodec: Don't reset decoder-fields for encoders when flushing

2022-04-13 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2022-04-13 16:49:51)
> Signed-off-by: Andreas Rheinhardt 
> ---
> Needs to be applied before
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294507.html
> or flushing an encoder will segfault.
> Btw: All this stuff is unused by subtitle decoders,
> so one could condition the else on that and avoid the allocations.
> 
>  libavcodec/avcodec.c | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index ded6b5b307..0d971a61d4 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -422,6 +422,17 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
>  }
>  if (avci->in_frame)
>  av_frame_unref(avci->in_frame);
> +} else {
> +av_packet_unref(avci->last_pkt_props);
> +while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
> +av_packet_unref(avci->last_pkt_props);
> +
> +av_packet_unref(avci->in_pkt);
> +
> +avctx->pts_correction_last_pts =
> +avctx->pts_correction_last_dts = INT64_MIN;
> +
> +av_bsf_flush(avci->bsf);
>  }
>  
>  avci->draining  = 0;
> @@ -430,22 +441,10 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
>  av_frame_unref(avci->buffer_frame);
>  av_packet_unref(avci->buffer_pkt);
>  
> -av_packet_unref(avci->last_pkt_props);
> -while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
> -av_packet_unref(avci->last_pkt_props);
> -
> -av_packet_unref(avci->in_pkt);
> -
>  if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
>  ff_thread_flush(avctx);
>  else if (ffcodec(avctx->codec)->flush)
>  ffcodec(avctx->codec)->flush(avctx);
> -
> -avctx->pts_correction_last_pts =
> -avctx->pts_correction_last_dts = INT64_MIN;
> -
> -if (avci->bsf)

did you drop this check on purpose?

-- 
Anton Khirnov
___
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".


[FFmpeg-devel] Audiotoolbox fix missing decoder out properties

2022-04-13 Thread MCC CS
This is a repost of the patch by Chris Snowhill who originally sent this patch
on 31 December - which didn't receive any replies. As you can see
on https://trac.ffmpeg.org/ticket/9564 the patch is needed and works perfectly.

I have rebased it and recompiled it.

Original commit description:

Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm
surprised this didn't break any previous system versions.

Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on
Mac OS Monterey. Fixes likely bug that none of the AudioToolbox
decoders work on Monterey.
---
libavcodec/audiotoolboxdec.c | 5 +
1 file changed, 5 insertions(+)

diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index b8d0e868f7..daccf4abf8 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -375,6 +375,11 @@ static av_cold int ffat_create_decoder(AVCodecContext 
*avctx,
 avctx->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
 avctx->ch_layout.nb_channels = out_format.mChannelsPerFrame = 
in_format.mChannelsPerFrame;

+out_format.mBytesPerFrame =
+out_format.mChannelsPerFrame * (out_format.mBitsPerChannel / 8);
+out_format.mBytesPerPacket =
+out_format.mBytesPerFrame * out_format.mFramesPerPacket;
+
 if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_QT)
 in_format.mFramesPerPacket = 64;

--
2.35.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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v1] avformat/ipfsgateway: define PATH_MAX

2022-04-13 Thread Mark Gaiser
On Wed, Apr 13, 2022 at 5:21 PM Mark Gaiser  wrote:

> PATH_MAX is posix. Some compilers (MSVC) don't define this
> thus failing to compile the ipfsgateway file.
> Defining it fixes the compile.
>
> Signed-off-by: Mark Gaiser 
> ---
>  libavformat/ipfsgateway.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
> index ed37e552dd..9b0d3dea59 100644
> --- a/libavformat/ipfsgateway.c
> +++ b/libavformat/ipfsgateway.c
> @@ -25,6 +25,12 @@
>  #include "os_support.h"
>  #include "url.h"
>
> +// Define the posix PATH_MAX if not there already.
> +// This fixes a compile issue for MSVC.
> +#ifndef PATH_MAX
> +#define PATH_MAX 4096
> +#endif
> +
>  typedef struct IPFSGatewayContext {
>  AVClass *class;
>  URLContext *inner;
> --
> 2.35.1
>
> I did verify the size of PATH_MAX. On my pc (arch with GCC compiler) this
value is defined as 4096. That seems enough to me.
Another way to fix this is to add it in os_support.h. I didn't add it there
because ipfsgateway.c is currently the only cross-platform code that makes
use of this.

Lastly, I don't have an MSVC compiler and windows to test this on.
I hope someone else in that setup can verify that this does indeed fix the
ffmpeg master build?
___
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".


[FFmpeg-devel] [PATCH v1] avformat/ipfsgateway: define PATH_MAX

2022-04-13 Thread Mark Gaiser
PATH_MAX is posix. Some compilers (MSVC) don't define this
thus failing to compile the ipfsgateway file.
Defining it fixes the compile.

Signed-off-by: Mark Gaiser 
---
 libavformat/ipfsgateway.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
index ed37e552dd..9b0d3dea59 100644
--- a/libavformat/ipfsgateway.c
+++ b/libavformat/ipfsgateway.c
@@ -25,6 +25,12 @@
 #include "os_support.h"
 #include "url.h"
 
+// Define the posix PATH_MAX if not there already.
+// This fixes a compile issue for MSVC.
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
 typedef struct IPFSGatewayContext {
 AVClass *class;
 URLContext *inner;
-- 
2.35.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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v13 1/1] avformat: Add IPFS protocol support.

2022-04-13 Thread Mark Gaiser
On Wed, Apr 13, 2022 at 4:45 PM Hendrik Leppkes  wrote:

> On Wed, Apr 13, 2022 at 3:14 PM Mark Gaiser  wrote:
> >
> > On Wed, Apr 13, 2022 at 2:28 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> > > Mark Gaiser:
> > > > On Wed, Apr 13, 2022 at 1:10 AM James Almer 
> wrote:
> > > >
> > > >>
> > > >>
> > > >> On 4/12/2022 3:02 PM, Michael Niedermayer wrote:
> > > >>> On Sun, Apr 10, 2022 at 04:41:27PM +0200, Michael Niedermayer
> wrote:
> > >  On Wed, Apr 06, 2022 at 02:00:56PM +0200, Mark Gaiser wrote:
> > >  [...]
> > > 
> > > > +if (stat_ret < 0) {
> > > 
> > > > +av_log(h, AV_LOG_INFO, "Unable to find IPFS folder.
> We
> > > >> tried:\n");
> > > > +av_log(h, AV_LOG_INFO, "- $IPFS_PATH, which was
> > > >> empty.\n");
> > > > +av_log(h, AV_LOG_INFO, "- $HOME/.ipfs (full uri: %s)
> > > >> which doesn't exist.\n", ipfs_full_data_folder);
> > > 
> > >  The 3 av_log() can also be combined
> > > 
> > >  If nothing else is found then ill change that myself and apply in
> a
> > > day
> > > >> or 2
> > > >>>
> > > >>> applied
> > > >>>
> > > >>> thx
> > > >>
> > > >> This broke msvc
> > > >>
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
> > > >> error C2065: 'PATH_MAX': undeclared identifier
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
> > > >> error C2057: expected constant expression
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > > >> error C2065: 'PATH_MAX': undeclared identifier
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > > >> error C2057: expected constant expression
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > > >> error C2466: cannot allocate an array of constant size 0
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > > >> error C2133: 'ipfs_full_data_folder': unknown size
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > > >> error C2065: 'PATH_MAX': undeclared identifier
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > > >> error C2057: expected constant expression
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > > >> error C2466: cannot allocate an array of constant size 0
> > > >>>
> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > > >> error C2133: 'ipfs_gateway_file': unknown size
> > > >>
> > > >> PATH_MAX seems to be POSIX only.
> > > >>
> > > >
> > > > Seriously?
> > > >
> > > > Shouldn't that define work on windows too?
> > >
> > > For "that define" to work that define needs to exist. Windows has
> > > MAX_PATH, but it is pretty small (260).
> > >
> > > > And why didn't patchwork catch this?
> > > >
> > >
> > > Because there is no MSVC patchwork box.
> > >
> > > > What is the intended define to use for this?
> > > > Note that it used to be a fixed number in the code itself (4096?)
> but I
> > > > changed it to PATH_MAX as per review suggestions
> > >
> > > Then how about just adding
> > > #ifndef MAX_PATH
> > > #define MAX_PATH 4096
> > > #endif
> > > or something like that.
> > >
> >
> > I'm fine with that but given past feedback I'll wait a little longer for
> a
> > 2nd opinion too.
> >
>
> master is currently broken, waiting is a luxury for another time.
>

Fine. Patch incoming.


> - Hendrik
> ___
> 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".
>
___
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".


Re: [FFmpeg-devel] [PATCH 6/8] lavc/avcodec: only allocate decoding packets for decoders

2022-04-13 Thread Andreas Rheinhardt
Anton Khirnov:
> ---
>  libavcodec/avcodec.c | 7 +--
>  libavcodec/decode.c  | 8 
>  2 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index c7daa385e7..5fd988a41c 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -180,12 +180,7 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
> *avctx, const AVCodec *code
>  
>  avci->buffer_frame = av_frame_alloc();
>  avci->buffer_pkt = av_packet_alloc();
> -avci->in_pkt = av_packet_alloc();
> -avci->last_pkt_props = av_packet_alloc();
> -avci->pkt_props = av_fifo_alloc2(1, sizeof(*avci->last_pkt_props),
> - AV_FIFO_FLAG_AUTO_GROW);
> -if (!avci->buffer_frame || !avci->buffer_pkt  ||
> -!avci->in_pkt || !avci->last_pkt_props || !avci->pkt_props) {
> +if (!avci->buffer_frame || !avci->buffer_pkt) {
>  ret = AVERROR(ENOMEM);
>  goto free_and_end;
>  }
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 3733e6d4b8..bb3857afd9 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1527,6 +1527,7 @@ int ff_reget_buffer(AVCodecContext *avctx, AVFrame 
> *frame, int flags)
>  
>  int ff_decode_preinit(AVCodecContext *avctx)
>  {
> +AVCodecInternal *avci = avctx->internal;
>  int ret = 0;
>  
>  /* if the decoder init function was already called previously,
> @@ -1605,6 +1606,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  avctx->export_side_data |= AV_CODEC_EXPORT_DATA_MVS;
>  }
>  
> +avci->in_pkt = av_packet_alloc();
> +avci->last_pkt_props = av_packet_alloc();
> +avci->pkt_props  = av_fifo_alloc2(1, sizeof(*avci->last_pkt_props),
> +  AV_FIFO_FLAG_AUTO_GROW);
> +if (!avci->in_pkt || !avci->last_pkt_props || !avci->pkt_props)
> +return AVERROR(ENOMEM);
> +
>  ret = decode_bsfs_init(avctx);
>  if (ret < 0)
>  return ret;

https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295326.html needs
to be applied before this patch or flushing an encoder will segfault.

- 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-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 4/4] avcodec/avcodec: Simplify accessing AVSubtitleRect via dedicated pointer

2022-04-13 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/avcodec.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 0d971a61d4..d11f035481 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -452,12 +452,15 @@ void avsubtitle_free(AVSubtitle *sub)
 int i;
 
 for (i = 0; i < sub->num_rects; i++) {
-av_freep(>rects[i]->data[0]);
-av_freep(>rects[i]->data[1]);
-av_freep(>rects[i]->data[2]);
-av_freep(>rects[i]->data[3]);
-av_freep(>rects[i]->text);
-av_freep(>rects[i]->ass);
+AVSubtitleRect *const rect = sub->rects[i];
+
+av_freep(>data[0]);
+av_freep(>data[1]);
+av_freep(>data[2]);
+av_freep(>data[3]);
+av_freep(>text);
+av_freep(>ass);
+
 av_freep(>rects[i]);
 }
 
-- 
2.32.0

___
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".


[FFmpeg-devel] [PATCH 3/4] avcodec/avcodec: Don't reset decoder-fields for encoders when flushing

2022-04-13 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
Needs to be applied before
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294507.html
or flushing an encoder will segfault.
Btw: All this stuff is unused by subtitle decoders,
so one could condition the else on that and avoid the allocations.

 libavcodec/avcodec.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index ded6b5b307..0d971a61d4 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -422,6 +422,17 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
 }
 if (avci->in_frame)
 av_frame_unref(avci->in_frame);
+} else {
+av_packet_unref(avci->last_pkt_props);
+while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
+av_packet_unref(avci->last_pkt_props);
+
+av_packet_unref(avci->in_pkt);
+
+avctx->pts_correction_last_pts =
+avctx->pts_correction_last_dts = INT64_MIN;
+
+av_bsf_flush(avci->bsf);
 }
 
 avci->draining  = 0;
@@ -430,22 +441,10 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
 av_frame_unref(avci->buffer_frame);
 av_packet_unref(avci->buffer_pkt);
 
-av_packet_unref(avci->last_pkt_props);
-while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
-av_packet_unref(avci->last_pkt_props);
-
-av_packet_unref(avci->in_pkt);
-
 if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
 ff_thread_flush(avctx);
 else if (ffcodec(avctx->codec)->flush)
 ffcodec(avctx->codec)->flush(avctx);
-
-avctx->pts_correction_last_pts =
-avctx->pts_correction_last_dts = INT64_MIN;
-
-if (avci->bsf)
-av_bsf_flush(avci->bsf);
 }
 
 void avsubtitle_free(AVSubtitle *sub)
-- 
2.32.0

___
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".


[FFmpeg-devel] [PATCH 2/4] avcodec/avcodec: Avoid av_frame_unref(NULL)

2022-04-13 Thread Andreas Rheinhardt
It works, but it is not documented to work.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/avcodec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index e0f38ac42a..ded6b5b307 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -420,6 +420,8 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
"that doesn't support it\n");
 return;
 }
+if (avci->in_frame)
+av_frame_unref(avci->in_frame);
 }
 
 avci->draining  = 0;
@@ -432,7 +434,6 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
 while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
 av_packet_unref(avci->last_pkt_props);
 
-av_frame_unref(avci->in_frame);
 av_packet_unref(avci->in_pkt);
 
 if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
-- 
2.32.0

___
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".


Re: [FFmpeg-devel] [PATCH v13 1/1] avformat: Add IPFS protocol support.

2022-04-13 Thread Hendrik Leppkes
On Wed, Apr 13, 2022 at 3:14 PM Mark Gaiser  wrote:
>
> On Wed, Apr 13, 2022 at 2:28 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
> > Mark Gaiser:
> > > On Wed, Apr 13, 2022 at 1:10 AM James Almer  wrote:
> > >
> > >>
> > >>
> > >> On 4/12/2022 3:02 PM, Michael Niedermayer wrote:
> > >>> On Sun, Apr 10, 2022 at 04:41:27PM +0200, Michael Niedermayer wrote:
> >  On Wed, Apr 06, 2022 at 02:00:56PM +0200, Mark Gaiser wrote:
> >  [...]
> > 
> > > +if (stat_ret < 0) {
> > 
> > > +av_log(h, AV_LOG_INFO, "Unable to find IPFS folder. We
> > >> tried:\n");
> > > +av_log(h, AV_LOG_INFO, "- $IPFS_PATH, which was
> > >> empty.\n");
> > > +av_log(h, AV_LOG_INFO, "- $HOME/.ipfs (full uri: %s)
> > >> which doesn't exist.\n", ipfs_full_data_folder);
> > 
> >  The 3 av_log() can also be combined
> > 
> >  If nothing else is found then ill change that myself and apply in a
> > day
> > >> or 2
> > >>>
> > >>> applied
> > >>>
> > >>> thx
> > >>
> > >> This broke msvc
> > >>
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
> > >> error C2065: 'PATH_MAX': undeclared identifier
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
> > >> error C2057: expected constant expression
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > >> error C2065: 'PATH_MAX': undeclared identifier
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > >> error C2057: expected constant expression
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > >> error C2466: cannot allocate an array of constant size 0
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> > >> error C2133: 'ipfs_full_data_folder': unknown size
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > >> error C2065: 'PATH_MAX': undeclared identifier
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > >> error C2057: expected constant expression
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > >> error C2466: cannot allocate an array of constant size 0
> > >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> > >> error C2133: 'ipfs_gateway_file': unknown size
> > >>
> > >> PATH_MAX seems to be POSIX only.
> > >>
> > >
> > > Seriously?
> > >
> > > Shouldn't that define work on windows too?
> >
> > For "that define" to work that define needs to exist. Windows has
> > MAX_PATH, but it is pretty small (260).
> >
> > > And why didn't patchwork catch this?
> > >
> >
> > Because there is no MSVC patchwork box.
> >
> > > What is the intended define to use for this?
> > > Note that it used to be a fixed number in the code itself (4096?) but I
> > > changed it to PATH_MAX as per review suggestions
> >
> > Then how about just adding
> > #ifndef MAX_PATH
> > #define MAX_PATH 4096
> > #endif
> > or something like that.
> >
>
> I'm fine with that but given past feedback I'll wait a little longer for a
> 2nd opinion too.
>

master is currently broken, waiting is a luxury for another time.

- Hendrik
___
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".


[FFmpeg-devel] [PATCH 1/4] avcodec/encode: Fix check for encoders impl. encode-simple API

2022-04-13 Thread Andreas Rheinhardt
FFCodec.cb is a union.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 6ae47b736c..e7ae2cd4c1 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -589,7 +589,7 @@ int ff_encode_preinit(AVCodecContext *avctx)
 if (avctx->codec_descriptor->props & AV_CODEC_PROP_INTRA_ONLY)
 avctx->internal->intra_only_flag = AV_PKT_FLAG_KEY;
 
-if (ffcodec(avctx->codec)->cb.encode) {
+if (ffcodec(avctx->codec)->cb_type == FF_CODEC_CB_TYPE_ENCODE) {
 avci->in_frame = av_frame_alloc();
 if (!avci->in_frame)
 return AVERROR(ENOMEM);
-- 
2.32.0

___
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".


Re: [FFmpeg-devel] [PATCH v13 1/1] avformat: Add IPFS protocol support.

2022-04-13 Thread Mark Gaiser
On Wed, Apr 13, 2022 at 2:28 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Mark Gaiser:
> > On Wed, Apr 13, 2022 at 1:10 AM James Almer  wrote:
> >
> >>
> >>
> >> On 4/12/2022 3:02 PM, Michael Niedermayer wrote:
> >>> On Sun, Apr 10, 2022 at 04:41:27PM +0200, Michael Niedermayer wrote:
>  On Wed, Apr 06, 2022 at 02:00:56PM +0200, Mark Gaiser wrote:
>  [...]
> 
> > +if (stat_ret < 0) {
> 
> > +av_log(h, AV_LOG_INFO, "Unable to find IPFS folder. We
> >> tried:\n");
> > +av_log(h, AV_LOG_INFO, "- $IPFS_PATH, which was
> >> empty.\n");
> > +av_log(h, AV_LOG_INFO, "- $HOME/.ipfs (full uri: %s)
> >> which doesn't exist.\n", ipfs_full_data_folder);
> 
>  The 3 av_log() can also be combined
> 
>  If nothing else is found then ill change that myself and apply in a
> day
> >> or 2
> >>>
> >>> applied
> >>>
> >>> thx
> >>
> >> This broke msvc
> >>
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
> >> error C2065: 'PATH_MAX': undeclared identifier
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
> >> error C2057: expected constant expression
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> >> error C2065: 'PATH_MAX': undeclared identifier
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> >> error C2057: expected constant expression
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> >> error C2466: cannot allocate an array of constant size 0
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
> >> error C2133: 'ipfs_full_data_folder': unknown size
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> >> error C2065: 'PATH_MAX': undeclared identifier
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> >> error C2057: expected constant expression
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> >> error C2466: cannot allocate an array of constant size 0
> >>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
> >> error C2133: 'ipfs_gateway_file': unknown size
> >>
> >> PATH_MAX seems to be POSIX only.
> >>
> >
> > Seriously?
> >
> > Shouldn't that define work on windows too?
>
> For "that define" to work that define needs to exist. Windows has
> MAX_PATH, but it is pretty small (260).
>
> > And why didn't patchwork catch this?
> >
>
> Because there is no MSVC patchwork box.
>
> > What is the intended define to use for this?
> > Note that it used to be a fixed number in the code itself (4096?) but I
> > changed it to PATH_MAX as per review suggestions
>
> Then how about just adding
> #ifndef MAX_PATH
> #define MAX_PATH 4096
> #endif
> or something like that.
>

I'm fine with that but given past feedback I'll wait a little longer for a
2nd opinion too.


>
> > I grepped over the ffmpeg source. This code is indeed the first cross
> > platform code in ffmpeg that uses it. The sole other user is v4l2_m2m.h
> but
> > that's obviously for windows only.
>
> You mean "not for Windows".
>

Oops. Yes, exactly!


> - 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-requ...@ffmpeg.org with subject "unsubscribe".
>
___
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".


[FFmpeg-devel] [PATCH v2] avformat/hls: check IV size inside EXT-X-KEY

2022-04-13 Thread Zhao Zhili
Before the patch, an implicit padding on the right is applied for
incomplete IV in manifest. No padding is allowed for IV inside
EXT-X-KEY.
---
 libavformat/hls.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 83ff4cc607..312294f0c7 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -810,7 +810,12 @@ static int parse_playlist(HLSContext *c, const char *url,
 if (!strcmp(info.method, "SAMPLE-AES"))
 key_type = KEY_SAMPLE_AES;
 if (!av_strncasecmp(info.iv, "0x", 2)) {
-ff_hex_to_data(iv, info.iv + 2);
+int n = ff_hex_to_data(iv, info.iv + 2);
+if (n != 16) {
+av_log(c->ctx, AV_LOG_ERROR, "Incomplete IV '%s'\n", 
info.iv);
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 has_iv = 1;
 }
 av_strlcpy(key, info.uri, sizeof(key));
-- 
2.31.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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH RFC] avformat/hls: check IV size inside EXT-X-KEY

2022-04-13 Thread zhilizhao(赵志立)


> On Apr 13, 2022, at 7:53 PM, Anton Khirnov  wrote:
> 
> Quoting Zhao Zhili (2022-04-12 10:27:50)
>> IV should always be 128 bits. If the IV attribute was truncated
>> inside EXT-X-KEY, padding on the left which is the same as when
>> using sequence number as IV.
>> ---
>> I'm not sure which method is better: do padding or just return
>> AVERROR_INVALIDDATA?
> 
> I would say return error, unless there are known buggy producers of
> incomplete IVs that we want to support.

Make sense. Actually it’s a story about shoot myself in the foot. I
created a buggy manifest, and the bug is hidden by the default
padding on the tail. So the vide only works with ffmpeg/ffplay. Let’s
hope I’m the only one make such mistake.

Will send a patch to return error in this case.

> 
> -- 
> Anton Khirnov
> ___
> 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".

___
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".


Re: [FFmpeg-devel] [PATCH v13 1/1] avformat: Add IPFS protocol support.

2022-04-13 Thread Andreas Rheinhardt
Mark Gaiser:
> On Wed, Apr 13, 2022 at 1:10 AM James Almer  wrote:
> 
>>
>>
>> On 4/12/2022 3:02 PM, Michael Niedermayer wrote:
>>> On Sun, Apr 10, 2022 at 04:41:27PM +0200, Michael Niedermayer wrote:
 On Wed, Apr 06, 2022 at 02:00:56PM +0200, Mark Gaiser wrote:
 [...]

> +if (stat_ret < 0) {

> +av_log(h, AV_LOG_INFO, "Unable to find IPFS folder. We
>> tried:\n");
> +av_log(h, AV_LOG_INFO, "- $IPFS_PATH, which was
>> empty.\n");
> +av_log(h, AV_LOG_INFO, "- $HOME/.ipfs (full uri: %s)
>> which doesn't exist.\n", ipfs_full_data_folder);

 The 3 av_log() can also be combined

 If nothing else is found then ill change that myself and apply in a day
>> or 2
>>>
>>> applied
>>>
>>> thx
>>
>> This broke msvc
>>
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
>> error C2065: 'PATH_MAX': undeclared identifier
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(36):
>> error C2057: expected constant expression
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
>> error C2065: 'PATH_MAX': undeclared identifier
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
>> error C2057: expected constant expression
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
>> error C2466: cannot allocate an array of constant size 0
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(46):
>> error C2133: 'ipfs_full_data_folder': unknown size
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
>> error C2065: 'PATH_MAX': undeclared identifier
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
>> error C2057: expected constant expression
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
>> error C2466: cannot allocate an array of constant size 0
>>> C:/Dev/ffmpeg/fate/x86_32-msvc-MD/src/libavformat/ipfsgateway.c(47):
>> error C2133: 'ipfs_gateway_file': unknown size
>>
>> PATH_MAX seems to be POSIX only.
>>
> 
> Seriously?
> 
> Shouldn't that define work on windows too?

For "that define" to work that define needs to exist. Windows has
MAX_PATH, but it is pretty small (260).

> And why didn't patchwork catch this?
> 

Because there is no MSVC patchwork box.

> What is the intended define to use for this?
> Note that it used to be a fixed number in the code itself (4096?) but I
> changed it to PATH_MAX as per review suggestions

Then how about just adding
#ifndef MAX_PATH
#define MAX_PATH 4096
#endif
or something like that.

> I grepped over the ffmpeg source. This code is indeed the first cross
> platform code in ffmpeg that uses it. The sole other user is v4l2_m2m.h but
> that's obviously for windows only.

You mean "not for Windows".

- 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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH RFC] avformat/hls: check IV size inside EXT-X-KEY

2022-04-13 Thread Anton Khirnov
Quoting Zhao Zhili (2022-04-12 10:27:50)
> IV should always be 128 bits. If the IV attribute was truncated
> inside EXT-X-KEY, padding on the left which is the same as when
> using sequence number as IV.
> ---
> I'm not sure which method is better: do padding or just return
> AVERROR_INVALIDDATA?

I would say return error, unless there are known buggy producers of
incomplete IVs that we want to support.

-- 
Anton Khirnov
___
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".


Re: [FFmpeg-devel] [PATCH] avcodec: Pass the HDR10+ metadata to the packet side data in VP9 encoder

2022-04-13 Thread Michael Niedermayer
On Thu, Jun 17, 2021 at 10:20:44PM -0700, Mohammad Izadi wrote:
> HDR10+ metadata is stored in the bit stream for HEVC. The story is different 
> for VP9 and cannot store the metadata in the bit stream. HDR10+ should be 
> passed to packet side data an stored in the container (mkv) for VP9.
> 
> This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing 
> it to the AVPacket side data.
> ---
>  doc/APIchanges |  2 +
>  libavcodec/avpacket.c  |  1 +
>  libavcodec/decode.c|  1 +
>  libavcodec/libvpxenc.c | 91 ++
>  libavcodec/packet.h|  8 
>  libavcodec/version.h   |  4 +-
>  6 files changed, 105 insertions(+), 2 deletions(-)

Why is this HDR10+ metadata passing done inside libvpxenc.c and not
in generic code ?
in generic code it could be enabled for other encoders.
Supporting HDR10+ with other codecs in matroska would make sense

thx

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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".


Re: [FFmpeg-devel] [PATCH 3/3] lavc/encode: pick a sane default for bits_per_raw_sample if it's not set

2022-04-13 Thread Anton Khirnov
Quoting Paul B Mahol (2022-04-06 13:24:35)
> Ping for this. Current state is imho bad.

pushed

-- 
Anton Khirnov
___
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".


Re: [FFmpeg-devel] [PATCH 1/8] lavc/avcodec: simplify codec id/type validity checking

2022-04-13 Thread Anton Khirnov
pushed patches 1-3 + new patch dropping EncodeSimpleContext.

Will push the rest soonish if nobody objects.

-- 
Anton Khirnov
___
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".


Re: [FFmpeg-devel] [PATCH] lavc/snow: only allocate mconly_picture for decoding

2022-04-13 Thread Anton Khirnov
Quoting Michael Niedermayer (2022-04-11 21:28:10)
> On Mon, Apr 11, 2022 at 10:49:34AM +0200, Anton Khirnov wrote:
> > It is not used in the encoder.
> > ---
> > Does this fix the crash?
> > ---
> >  libavcodec/snow.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> This patch alone works fine
> 
> i havnt tested it in conjunction with other patches as i slightly 
> lost track but 1-3 + this seem not to build or i did something stupid

Probably conflicts with the AVCodec callback restructuring by Andreas.
This patch should not interact with the previous ones in any way, so it
should be fine if it works on its own

I also pushed the rebased versions of patches before this one, so you
can test it again if you prefer.

-- 
Anton Khirnov
___
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".


Re: [FFmpeg-devel] [PATCH 09/49] fftools/ffmpeg: store output format separately from the muxer context

2022-04-13 Thread Anton Khirnov
Quoting James Almer (2022-04-06 14:00:21)
> On 4/4/2022 8:29 AM, Anton Khirnov wrote:
> > Allows accessing it without going through the muxer context. This will
> > be useful in the following commits, where the muxer context will be
> > hidden.
> > ---
> >   fftools/ffmpeg.c | 18 ++
> >   fftools/ffmpeg.h |  2 ++
> >   fftools/ffmpeg_opt.c |  1 +
> >   3 files changed, 13 insertions(+), 8 deletions(-)
> 
> Patches 4 to 9 look ok.

Thank you, pushed patches up to 9

-- 
Anton Khirnov
___
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".


Re: [FFmpeg-devel] [PATCH v2 0/2] Add common V4L2 request API code

2022-04-13 Thread Elie Roudninski
Please disregard this patch series.
Since I sent those yesterday I have been contacted by the original
authors and was told that those are outdated.
Both LibreELEC and RPi devs are working on a different version of the
code that would need to be consolidated first before it can go
upstream.

Sorry for the noise.

Best regards,

Le mar. 12 avr. 2022 à 17:53,  a écrit :
>
> From: Elie ROUDNINSKI 
>
> This is the second iteration of 
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898
> but only covering the common V4L2 request API code without the support for 
> h264 codec.
>
> Changes in v2:
> * Addressed some styling comments
> * Removed libudev dependency
> * Device probing has been refactored
>
> This code (in one version or another) has been widely used by various projects
> like LibreELEC[1] for several years already.
> The uAPI has been stable for several kernel versions too and as of linux5.17,
> the following codecs are available:
> * mpeg2
> * h264
> * vp9
>
> HEVC is in the process of being stabilized too[2].
>
> I have tried to contact the original author of the code but I haven't got an 
> answer
> so far so I have kept them as commit author but added myself as co-author 
> since
> I have made substantial modifications to it. Happy to change this either way.
>
> It's my first contribution to FFmpeg, so I hope to have done everything right.
> Additionally, I must confess that I am not an expert of the V4L2 request APIs 
> but
> since I was frustrated of not being able to use standard FFmpeg on my ARM 
> boards
> to get hardware decoding working, I figured I might just try to give it a go.
> There are several comments in the original patch series that I won't have an 
> answer
> for but I hope that won't be a blocker. That's also why the v4l2-request 
> configure
> option has been marked as experimental.
>
> [1] 
> https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages/multimedia/ffmpeg/patches/v4l2-request
> [2] https://patchwork.kernel.org/project/linux-media/list/?series=630077
>
>
> Jonas Karlman (2):
>   avutil/buffer: add av_buffer_pool_flush()
>   avcodec: add common V4L2 request API code
>
>  configure |   7 +
>  doc/APIchanges|   3 +
>  libavcodec/Makefile   |   3 +-
>  libavcodec/hwconfig.h |   2 +
>  libavcodec/v4l2_buffers.c |   8 +-
>  libavcodec/v4l2_context.c |  80 ++--
>  libavcodec/v4l2_context.h |   5 +-
>  libavcodec/v4l2_device.c  | 229 ++
>  libavcodec/v4l2_device.h  |  60 +++
>  libavcodec/v4l2_m2m.c | 119 ++---
>  libavcodec/v4l2_m2m.h |   4 +-
>  libavcodec/v4l2_m2m_dec.c |  10 +-
>  libavcodec/v4l2_m2m_enc.c |   8 +-
>  libavcodec/v4l2_request.c | 892 ++
>  libavcodec/v4l2_request.h |  87 
>  libavutil/buffer.c|   7 +
>  libavutil/buffer.h|   5 +
>  libavutil/version.h   |   4 +-
>  18 files changed, 1399 insertions(+), 134 deletions(-)
>  create mode 100644 libavcodec/v4l2_device.c
>  create mode 100644 libavcodec/v4l2_device.h
>  create mode 100644 libavcodec/v4l2_request.c
>  create mode 100644 libavcodec/v4l2_request.h
>
> --
> 2.35.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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture

2022-04-13 Thread Nicolas George
Soft Works (12022-04-12):
> I have always asked you kindly

You have been repeatedly rude towards the people who know libavfilter
well.

On top of that, you have shown that you do not understand how
libavfilter currently works.

On top of that, you have refused to learn how libavfilter currently
works.

You made your bed.

-- 
  Nicolas George
___
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".


Re: [FFmpeg-devel] [PATCH 1/1] librtmp: use AVBPrint instead of char *

2022-04-13 Thread Martin Storsjö

On Mon, 11 Apr 2022, Tristan Matthews wrote:


This avoids having to do one pass to calculate the full length to allocate
followed by a second pass to actually append values.
---
libavformat/librtmp.c | 123 +++---
1 file changed, 32 insertions(+), 91 deletions(-)


Thanks, this patch looks good to me. I'll wait for a little while still 
if Marton wants to comment on it, before I go ahead and push it.


// Martin

___
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".


Re: [FFmpeg-devel] [PATCH 4/4] fate/oma: Use REMUX where appropriate

2022-04-13 Thread Martin Storsjö

On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:


Simplifies the checks.

Signed-off-by: Andreas Rheinhardt 
---
tests/fate/oma.mak | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/tests/fate/oma.mak b/tests/fate/oma.mak
index a088feff21..7e2020b7d0 100644
--- a/tests/fate/oma.mak
+++ b/tests/fate/oma.mak
@@ -8,14 +8,8 @@ fate-oma-atrac3p-remux: CMD = transcode oma 
$(TARGET_SAMPLES)/atrac3p/at3p_sampl
FATE_OMA_REMUX-$(CONFIG_WAV_DEMUXER) += fate-oma-atrac3-remux
fate-oma-atrac3-remux: CMD = transcode wav $(TARGET_SAMPLES)/atrac3/mc_sich_at3_132_small.wav oma 
"-c copy" "-c copy -t 0.1"

-FATE_OMA_FFMPEG-$(call ALLYES, FILE_PROTOCOL OMA_MUXER\
-   OMA_DEMUXER FRAMECRC_MUXER \
-   PIPE_PROTOCOL) \
-   += $(FATE_OMA_REMUX-yes)
-FATE_OMA_FFMPEG_FFPROBE-$(call ALLYES, FILE_PROTOCOL OMA_MUXER\
-   OMA_DEMUXER FRAMECRC_MUXER \
-   PIPE_PROTOCOL) \
-   += $(FATE_OMA_REMUX_FFPROBE-yes)
+FATE_OMA_FFMPEG-$(call REMUX, OMA) += $(FATE_OMA_REMUX-yes)
+FATE_OMA_FFMPEG_FFPROBE-$(call REMUX, OMA) += $(FATE_OMA_REMUX_FFPROBE-yes)
FATE_SAMPLES_FFMPEG += $(FATE_OMA_FFMPEG-yes)
FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_OMA_FFMPEG_FFPROBE-yes)
fate-oma: $(FATE_OMA_FFMPEG-yes) $(FATE_OMA_FFMPEG_FFPROBE-yes)
--
2.32.0


LGTM

// Martin

___
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".


Re: [FFmpeg-devel] [PATCH 3/4] fate/subtitles: Use REMUX where appropriate

2022-04-13 Thread Martin Storsjö

On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:


It also adds the missing depenencies on the file and pipe protocols
and the framecrc muxer.

Signed-off-by: Andreas Rheinhardt 
---
tests/fate/subtitles.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index 8375cf2898..bc464edce6 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -22,7 +22,7 @@ fate-binsub-mksenc: CMD = md5pipe -i 
$(TARGET_SAMPLES)/sub/1ededcbd7b.ass -c cop
FATE_SUBTITLES_ASS-$(call DEMDEC, JACOSUB, JACOSUB) += fate-sub-jacosub
fate-sub-jacosub: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/JACOsub_capability_tester.jss

-FATE_SUBTITLES-$(call DEMMUX, JACOSUB, JACOSUB) += fate-sub-jacosub-remux
+FATE_SUBTITLES-$(call REMUX, JACOSUB) += fate-sub-jacosub-remux
fate-sub-jacosub-remux: CMD = transcode jacosub $(TARGET_SAMPLES)/sub/JACOsub_capability_tester.jss 
jacosub "-map 0 -c copy" "-map 0 -c copy"
fate-sub-jacosub-remux: CMP = diff


LGTM

// Martin

___
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".


Re: [FFmpeg-devel] [PATCH 2/4] fate/image: Use TRANSCODE where appropriate

2022-04-13 Thread Martin Storsjö

On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:


This also adds previously forgotten requirements. E.g. fate-jpg-icc
actually depends on the png decoder, so that it should not be run
when e.g. zlib is disabled, yet it happens, see
http://fate.ffmpeg.org/report.cgi?time=20220411182746=x86_64-archlinux-gcc-disablezlib


Sorry for preempting this patchset yesterday, I hadn't checked the patch 
queue in detail before pushing the fix.



Signed-off-by: Andreas Rheinhardt 
---
tests/fate/image.mak | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 70be281411..63076f8ded 100644
--- a/tests/fate/image.mak
+++ b/tests/fate/image.mak
@@ -337,7 +337,7 @@ fate-jpg-12bpp: CMD = framecrc -idct simple -i 
$(TARGET_SAMPLES)/jpg/12bpp.jpg -
FATE_JPG += fate-jpg-jfif
fate-jpg-jfif: CMD = framecrc -idct simple -i $(TARGET_SAMPLES)/jpg/20242.jpg

-FATE_JPG_TRANSCODE-$(call ENCDEC, MJPEG, IMAGE2) += fate-jpg-icc
+FATE_JPG_TRANSCODE-$(call TRANSCODE, MJPEG, MJPEG IMAGE_JPEG_PIPE, 
IMAGE_PNG_PIPE_DEMUXER PNG_DECODER SCALE_FILTER) += fate-jpg-icc
fate-jpg-icc: CMD = transcode png_pipe $(TARGET_SAMPLES)/png1/lena-int_rgb24.png mjpeg "-vf scale" 
"" "" "-show_frames"

FATE_JPG-$(call DEMDEC, IMAGE2, MJPEG) += $(FATE_JPG)
@@ -389,7 +389,7 @@ FATE_PNG_PROBE += fate-png-side-data
fate-png-side-data: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_frames \
-i $(TARGET_SAMPLES)/png1/lena-int_rgb24.png

-FATE_PNG_TRANSCODE-$(call ENCDEC, PNG, IMAGE2) += fate-png-icc
+FATE_PNG_TRANSCODE-$(call TRANSCODE, PNG, IMAGE2 IMAGE_PNG_PIPE) += 
fate-png-icc
fate-png-icc: CMD = transcode png_pipe $(TARGET_SAMPLES)/png1/lena-int_rgb24.png image2 "-c png" "" 
"" "-show_frames"

FATE_PNG-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG)
--
2.32.0


Thanks, this looks correct to me after looking through the test execution 
again.


// Martin

___
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".


Re: [FFmpeg-devel] [PATCH 1/4] tests/Makefile: Add auxiliary functions for transcode and stream_remux

2022-04-13 Thread Martin Storsjö

On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:


Tests using the transcode and stream_remux functions have some common
requirements (namely the file and pipe protocols as well as the framecrc
muxer) and also other commonalities: The create a file and read it
immediately afterwards, so that they typically rely on a corresponding
muxer+demuxer pair which typically shares the same name; for transcode
(if it does not use stream copy) the same is true for encoders and
decoders. This means that using special Makefile-functions instead
of the general ALLYES is worthwhile. This commit adds such functions.

These functions allow to add arbitrary CONFIG-checks on top of the
aforementioned ones in order to satisfy special needs (for e.g. parsers,
filters) that several intended users have.

Signed-off-by: Andreas Rheinhardt 
---
tests/Makefile | 10 ++
1 file changed, 10 insertions(+)

diff --git a/tests/Makefile b/tests/Makefile
index e3b41a4f7b..5e4da2c42f 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -74,6 +74,16 @@ ENCDEC2 = $(call ALLYES, $(firstword $(1))_ENCODER 
$(lastword $(1))_DECODER  \
 $(firstword $(2))_ENCODER $(lastword $(2))_DECODER  \
 $(firstword $(3))_MUXER   $(lastword $(3))_DEMUXER)

+# RAWVIDEO_ENCODER and PCM_S16LE_ENCODER corresponds to the default codecs
+# for framecrc. These requirements are not always necessary.
+TRANSCODE = $(call ALLYES, $(firstword $(1))_ENCODER $(lastword $(1))_DECODER \
+   $(firstword $(2))_MUXER   $(lastword $(2))_DEMUXER \
+   $(3) FILE_PROTOCOL PIPE_PROTOCOL RAWVIDEO_ENCODER  \
+   PCM_S16LE_ENCODER FRAMECRC_MUXER)
+
+REMUX = $(call ALLYES, $(firstword $(1))_MUXER $(lastword $(1))_DEMUXER \
+   $(2) FILE_PROTOCOL PIPE_PROTOCOL FRAMECRC_MUXER)
+
DEMDEC  = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER))
ENCMUX  = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER)


This looks good to me (provided that the rest of the patches using it end 
up sensible).


// Martin

___
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".


Re: [FFmpeg-devel] [PATCH] avfilter/lensfun: add option db_path

2022-04-13 Thread Gyan Doshi

Pushed as 1405b65d22d8e05ae8bb74fc13e275be2ae6b9f9

On 2022-04-10 11:15 pm, Gyan Doshi wrote:

Plan to push tomorrow.

On 2022-04-10 11:36 am, Gyan Doshi wrote:

The lensfun filter, at present, loads its database from a path hardcoded
at build time. This may not be known or available to end users.

Added option db_path allows custom path.
---
  doc/filters.texi | 4 
  libavfilter/vf_lensfun.c | 8 +---
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 6a66b0ed11..9861f43c07 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14693,6 +14693,10 @@ required.
  The model of the lens (for example, "Canon EF-S 18-55mm f/3.5-5.6 
IS STM"). This

  option is required.
  +@item db_path
+The full path to the lens database folder. If not set, the filter 
will attempt to
+load the database from the install path when the library was built. 
Default is unset.

+
  @item mode
  The type of correction to apply. The following values are valid 
options:

  diff --git a/libavfilter/vf_lensfun.c b/libavfilter/vf_lensfun.c
index 596daed104..35c522a723 100644
--- a/libavfilter/vf_lensfun.c
+++ b/libavfilter/vf_lensfun.c
@@ -73,7 +73,7 @@ typedef struct DistortionCorrectionThreadData {
    typedef struct LensfunContext {
  const AVClass *class;
-    const char *make, *model, *lens_model;
+    const char *make, *model, *lens_model, *db_path;
  int mode;
  float focal_length;
  float aperture;
@@ -97,6 +97,7 @@ static const AVOption lensfun_options[] = {
  { "make", "set camera maker", OFFSET(make), AV_OPT_TYPE_STRING, 
{.str=NULL}, 0, 0, FLAGS },
  { "model", "set camera model", OFFSET(model), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
  { "lens_model", "set lens model", OFFSET(lens_model), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
+    { "db_path", "set path to database", OFFSET(db_path), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
  { "mode", "set mode", OFFSET(mode), AV_OPT_TYPE_INT, 
{.i64=GEOMETRY_DISTORTION}, 0, VIGNETTING | GEOMETRY_DISTORTION | 
SUBPIXEL_DISTORTION, FLAGS, "mode" },
  { "vignetting", "fix lens vignetting", 0, 
AV_OPT_TYPE_CONST, {.i64=VIGNETTING}, 0, 0, FLAGS, "mode" },
  { "geometry", "correct geometry distortion", 0, 
AV_OPT_TYPE_CONST, {.i64=GEOMETRY_DISTORTION}, 0, 0, FLAGS, "mode" },

@@ -136,9 +137,10 @@ static av_cold int init(AVFilterContext *ctx)
  const lfLens **lenses;
    db = lf_db_create();
-    if (lf_db_load(db) != LF_NO_ERROR) {
+    if ((lensfun->db_path ? lf_db_load_path(db, lensfun->db_path) : 
lf_db_load(db)) != LF_NO_ERROR) {

  lf_db_destroy(db);
-    av_log(ctx, AV_LOG_FATAL, "Failed to load lensfun database\n");
+    av_log(ctx, AV_LOG_FATAL, "Failed to load lensfun database 
from %s path\n",

+   lensfun->db_path ? lensfun->db_path : "default");
  return AVERROR_INVALIDDATA;
  }


___
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".


___
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".


Re: [FFmpeg-devel] [PATCH 1/2] libavutil/hwcontext_vulkan: Fix VK_FORMAT_R8G8_UNORM and VK_FORMAT_R16G16_UNORM map problem on Vulkan

2022-04-13 Thread Xiang, Haihao
On Wed, 2022-03-30 at 11:41 +0800, Wenbin Chen wrote:
> Vulkan map both DRM_FORMAT_RG88 and DRM_FORMAT_GR88 to
> VK_FORMAT_R8G8_UNORM. This cannot distinguish nv12/nv24 and nv21/nv42.
> Vulkan also map both DRM_FORMAT_RG1616 and DRM_FORMAT_GR1616 to
> VK_FORMAT_R16G16_UNORM. This causes issue when map back.
> VK_FORMAT_R16G16 will be mapped to DRM_FORMAT_GR1616, while p010 need
> DRM_FORMAT_RG1616.
> Add sw_format check to vulkan_fmt_to_drm() to fix this problem.
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavutil/hwcontext_vulkan.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
> index 237caa4bc0..791649001f 100644
> --- a/libavutil/hwcontext_vulkan.c
> +++ b/libavutil/hwcontext_vulkan.c
> @@ -3290,8 +3290,17 @@ static void vulkan_unmap_to_drm(AVHWFramesContext
> *hwfc, HWMapDescriptor *hwmap)
>  av_free(drm_desc);
>  }
>  
> -static inline uint32_t vulkan_fmt_to_drm(VkFormat vkfmt)
> +static inline uint32_t vulkan_fmt_to_drm(VkFormat vkfmt,
> + enum AVPixelFormat sw_format)
>  {
> +if (vkfmt == VK_FORMAT_R8G8_UNORM &&
> +   (sw_format == AV_PIX_FMT_NV12 || sw_format == AV_PIX_FMT_NV24))
> +return DRM_FORMAT_RG88;
> +
> +if (vkfmt == VK_FORMAT_R16G16_UNORM &&
> +   (sw_format == AV_PIX_FMT_P010 || sw_format == AV_PIX_FMT_P016))
> +return DRM_FORMAT_RG1616;
> +
>  for (int i = 0; i < FF_ARRAY_ELEMS(vulkan_drm_format_map); i++)
>  if (vulkan_drm_format_map[i].vk_format == vkfmt)
>  return vulkan_drm_format_map[i].drm_fourcc;
> @@ -3373,7 +3382,7 @@ static int vulkan_map_to_drm(AVHWFramesContext *hwfc,
> AVFrame *dst,
>  };
>  VkFormat plane_vkfmt = av_vkfmt_from_pixfmt(hwfc->sw_format)[i];
>  
> -drm_desc->layers[i].format= vulkan_fmt_to_drm(plane_vkfmt);
> +drm_desc->layers[i].format= vulkan_fmt_to_drm(plane_vkfmt, hwfc-
> >sw_format);
>  drm_desc->layers[i].nb_planes = 1;
>  
>  if (drm_desc->layers[i].format == DRM_FORMAT_INVALID) {

Patchset LGTM

-Haihao

___
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".