Re: [FFmpeg-devel] [PATCH 03/24] avcodec/subtitles: Introduce new frame-based subtitle decoding API

2022-01-14 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas
> Rheinhardt
> Sent: Friday, January 14, 2022 6:54 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 03/24] avcodec/subtitles: Introduce new
> frame-based subtitle decoding API
> 
> ffmpegagent:
> > From: softworkz 
> >
> > - Add avcodec_decode_subtitle3 which takes subtitle frames,
> >   serving as compatibility shim to legacy subtitle decoding
> > - Add additional methods for conversion between old and new API
> 
> This commit message is completely wrong.
> 
> >
> > Signed-off-by: softworkz 
> > ---
> >  libavcodec/avcodec.h|   8 +-
> >  libavcodec/codec_desc.c |  11 +++
> >  libavcodec/codec_desc.h |   8 ++
> >  libavcodec/decode.c |  56 ++--
> >  libavcodec/internal.h   |  22 +
> >  libavcodec/utils.c  | 184 
> >  6 files changed, 280 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index fe5a83cf85..9d59f6e840 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1675,7 +1675,7 @@ typedef struct AVCodecContext {
> >
> >  /**
> >   * Header containing style information for text subtitles.
> > - * For SUBTITLE_ASS subtitle type, it should contain the whole ASS
> > + * For AV_SUBTITLE_FMT_ASS subtitle type, it should contain the whole
> ASS
> >   * [Script Info] and [V4+ Styles] section, plus the [Events] line and
> >   * the Format line following. It shouldn't include any Dialogue line.
> >   * - encoding: Set/allocated/freed by user (before avcodec_open2())
> > @@ -2415,7 +2415,10 @@ int avcodec_close(AVCodecContext *avctx);
> >   * Free all allocated data in the given subtitle struct.
> >   *
> >   * @param sub AVSubtitle to free.
> > + *
> > + * @deprecated Use the regular frame based encode and decode APIs instead.
> >   */
> > +attribute_deprecated
> >  void avsubtitle_free(AVSubtitle *sub);
> >
> >  /**
> > @@ -2508,7 +2511,10 @@ enum AVChromaLocation avcodec_chroma_pos_to_enum(int
> xpos, int ypos);
> >   * must be freed with avsubtitle_free if *got_sub_ptr is
> set.
> >   * @param[in,out] got_sub_ptr Zero if no subtitle could be decompressed,
> otherwise, it is nonzero.
> >   * @param[in] avpkt The input AVPacket containing the input buffer.
> > + *
> > + * @deprecated Use the new decode API (avcodec_send_packet,
> avcodec_receive_frame) instead.
> >   */
> > +attribute_deprecated
> >  int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub,
> >  int *got_sub_ptr,
> >  AVPacket *avpkt);
> > diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> > index 0974ee03de..e48e4532ba 100644
> > --- a/libavcodec/codec_desc.c
> > +++ b/libavcodec/codec_desc.c
> > @@ -3548,3 +3548,14 @@ enum AVMediaType avcodec_get_type(enum AVCodecID
> codec_id)
> >  const AVCodecDescriptor *desc = avcodec_descriptor_get(codec_id);
> >  return desc ? desc->type : AVMEDIA_TYPE_UNKNOWN;
> >  }
> > +
> > +enum AVSubtitleType avcodec_descriptor_get_subtitle_format(const
> AVCodecDescriptor *codec_descriptor)
> > +{
> > +if(codec_descriptor->props & AV_CODEC_PROP_BITMAP_SUB)
> > +return AV_SUBTITLE_FMT_BITMAP;
> > +
> > +if(codec_descriptor->props & AV_CODEC_PROP_TEXT_SUB)
> > +return AV_SUBTITLE_FMT_ASS;
> > +
> > +return AV_SUBTITLE_FMT_UNKNOWN;
> > +}
> > diff --git a/libavcodec/codec_desc.h b/libavcodec/codec_desc.h
> > index 126b52df47..ba68d24e0e 100644
> > --- a/libavcodec/codec_desc.h
> > +++ b/libavcodec/codec_desc.h
> > @@ -121,6 +121,14 @@ const AVCodecDescriptor *avcodec_descriptor_next(const
> AVCodecDescriptor *prev);
> >   */
> >  const AVCodecDescriptor *avcodec_descriptor_get_by_name(const char *name);
> >
> > +/**
> > + * Return subtitle format from a codec descriptor
> > + *
> > + * @param codec_descriptor codec descriptor
> > + * @return the subtitle type (e.g. bitmap, text)
> > + */
> > +enum AVSubtitleType avcodec_descriptor_get_subtitle_format(const
> AVCodecDescriptor *codec_descriptor);
> > +
> >  /**
> >   * @}
> >   */
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 0912f86a14..ab8a6ea6ff 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -576,6 +576,39 @@ static int
> decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
> >  return ret;
> >  }
> >
> > +static int decode_subtitle2_priv(AVCodecContext *avctx, AVSubtitle *sub,
> > + int *got_sub_ptr, AVPacket *avpkt);
> > +
> > +static int decode_subtitle_shim(AVCodecContext *avctx, AVFrame *frame,
> AVPacket *avpkt)
> > +{
> > +int ret, got_sub_ptr = 0;
> > +AVSubtitle subtitle = { 0 };
> > +
> > +if (frame->buf[0])
> > +return AVERROR(EAGAIN);
> > +
> > +av_frame_unref(frame);
> > +
> > +ret = decode_subtitle2_priv(avctx, , 

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Fix path handling on Windows

2022-01-14 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas
> Rheinhardt
> Sent: Saturday, January 15, 2022 7:40 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Fix path handling on
> Windows
> 
> ffmpegagent:
> > From: softworkz 
> >
> > Signed-off-by: softworkz 
> > ---
> > avformat/hlsenc: Fix path handling on Windows
> >
> > Handling for DOS path separators was missing
> >
> > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-19%2Fsoftworkz%2Fsubmit_hlspath-v1
> > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> 19/softworkz/submit_hlspath-v1
> > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/19
> >
> >  libavformat/hlsenc.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index ef8973cea1..eff7f4212e 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -3028,6 +3028,10 @@ static int hls_init(AVFormatContext *s)
> >  }
> >
> >  p = strrchr(vs->m3u8_name, '/');
> > +#if HAVE_DOS_PATHS
> > +p = FFMAX(p, strrchr(vs->m3u8_name, '\\'));
> > +#endif
> > +
> >  if (p) {
> >  char tmp = *(++p);
> >  *p = '\0';
> >
> > base-commit: c936c319bd54f097cc1d75b1ee1c407d53215d71
> >
> 

Thanks for reviewing.

> 1. You seem to be under the impression that NULL <= all other pointers.
> This is wrong. Relational operators acting on pointers are only defined
> when both point to the same object (the case of "one past the last
> element of an array" is also allowed) and are undefined behaviour otherwise.

The case about NULL is interesting - I wasn't aware of that.
Is it practically relevant, i.e. is there any platform where casting 
(void *)0 does not evaluate to 0 ?

> 2. Apart from that: Your code would potentially evaluate strrchr()
> multiple times which is bad style (given that this function is likely
> marked as pure the compiler could probably optimize the second call
> away, but this is not a given).

It's not my code. It's code copied from avstring.c - so please blame
whoever that wrote.

Regarding performance, I'm not sure whether this is relevant in any way,
given the low frequency of execution and putting it into relation to 
all the other things that ffmpeg is doing usually.

> 3. The code in av_basename() is also wrong.

...

> 4. Is there actually a reason why you don't use av_basename() directly here?

Yes, multiple:

1. Different behavior - those functions are returning a "." when not found
2. The docs tell it's required to copy a string before supplying it to
   those functions (as they may changing the string).
3. The hlsenc code changes the string temporarily and restores it after
   wards. The same couldn't be done when using the avstring functions.

Thanks,
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] avformat/hlsenc: Fix path handling on Windows

2022-01-14 Thread Andreas Rheinhardt
ffmpegagent:
> From: softworkz 
> 
> Signed-off-by: softworkz 
> ---
> avformat/hlsenc: Fix path handling on Windows
> 
> Handling for DOS path separators was missing
> 
> Published-As: 
> https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-19%2Fsoftworkz%2Fsubmit_hlspath-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
> pr-ffstaging-19/softworkz/submit_hlspath-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/19
> 
>  libavformat/hlsenc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index ef8973cea1..eff7f4212e 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -3028,6 +3028,10 @@ static int hls_init(AVFormatContext *s)
>  }
>  
>  p = strrchr(vs->m3u8_name, '/');
> +#if HAVE_DOS_PATHS
> +p = FFMAX(p, strrchr(vs->m3u8_name, '\\'));
> +#endif
> +
>  if (p) {
>  char tmp = *(++p);
>  *p = '\0';
> 
> base-commit: c936c319bd54f097cc1d75b1ee1c407d53215d71
> 

1. You seem to be under the impression that NULL <= all other pointers.
This is wrong. Relational operators acting on pointers are only defined
when both point to the same object (the case of "one past the last
element of an array" is also allowed) and are undefined behaviour otherwise.
2. Apart from that: Your code would potentially evaluate strrchr()
multiple times which is bad style (given that this function is likely
marked as pure the compiler could probably optimize the second call
away, but this is not a given).
3. The code in av_basename() is also wrong.
4. Is there actually a reason why you don't use av_basename() directly here?

- 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] Website release notes for 5.0

2022-01-14 Thread Lynne
15 Jan 2022, 05:08 by ffm...@gyani.pro:

>
>
> On 2022-01-15 06:18 am, Lynne wrote:
>
>> 14 Jan 2022, 20:39 by d...@lynne.ee:
>>
>>> 14 Jan 2022, 20:32 by mich...@niedermayer.cc:
>>>
 On Fri, Jan 14, 2022 at 08:02:35PM +0100, Lynne wrote:

> 14 Jan 2022, 18:48 by mich...@niedermayer.cc:
>
>> On Tue, Jan 04, 2022 at 04:08:49PM +0100, Lynne wrote:
>>
>>> Since I couldn't find a codename preference, I went with "Desitter"
>>>
>> I just counted and i see
>> 2 for Desitter (the initial from the past and you)
>> 3 for Lorentz  (the initial from the past, jb and reto )
>>
> Changed the name locally to Lorentz.
>
 ive just tagged the release and am uploading the tar.* files
 so you can push this

>>>  
>>> I've pinged j-b, since he wanted the announcement to wait
>>> on something.
>>>
>> Okay, the release will be officially out on 16:00 UTC+1 (CET) on Monday, the 
>> 17th,
>> so I'll push the update to the webpage then.
>> Until then, go and test, or don't look back and hope a ninja 5.1 release 
>> won't be necessary :)
>>
>
> Michael has tagged, so it's already 'out' , no?
>

No. It's just a freeze, and if something really bad is found,
we can still redo it.
You generally shouldn't do releases on a Friday night, or
weekends, for obvious reasons.
___
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] Website release notes for 5.0

2022-01-14 Thread Gyan Doshi



On 2022-01-15 06:18 am, Lynne wrote:

14 Jan 2022, 20:39 by d...@lynne.ee:


14 Jan 2022, 20:32 by mich...@niedermayer.cc:


On Fri, Jan 14, 2022 at 08:02:35PM +0100, Lynne wrote:


14 Jan 2022, 18:48 by mich...@niedermayer.cc:


On Tue, Jan 04, 2022 at 04:08:49PM +0100, Lynne wrote:


Since I couldn't find a codename preference, I went with "Desitter"


I just counted and i see
2 for Desitter (the initial from the past and you)
3 for Lorentz  (the initial from the past, jb and reto )


Changed the name locally to Lorentz.


ive just tagged the release and am uploading the tar.* files
so you can push this


 
I've pinged j-b, since he wanted the announcement to wait
on something.


Okay, the release will be officially out on 16:00 UTC+1 (CET) on Monday, the 
17th,
so I'll push the update to the webpage then.
Until then, go and test, or don't look back and hope a ninja 5.1 release won't 
be necessary :)


Michael has tagged, so it's already 'out' , no?

Regards,
Gyan
___
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] avformat/hlsenc: Fix path handling on Windows

2022-01-14 Thread ffmpegagent
From: softworkz 

Signed-off-by: softworkz 
---
avformat/hlsenc: Fix path handling on Windows

Handling for DOS path separators was missing

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-19%2Fsoftworkz%2Fsubmit_hlspath-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-19/softworkz/submit_hlspath-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/19

 libavformat/hlsenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ef8973cea1..eff7f4212e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -3028,6 +3028,10 @@ static int hls_init(AVFormatContext *s)
 }
 
 p = strrchr(vs->m3u8_name, '/');
+#if HAVE_DOS_PATHS
+p = FFMAX(p, strrchr(vs->m3u8_name, '\\'));
+#endif
+
 if (p) {
 char tmp = *(++p);
 *p = '\0';

base-commit: c936c319bd54f097cc1d75b1ee1c407d53215d71
-- 
ffmpeg-codebot
___
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] Website release notes for 5.0

2022-01-14 Thread Lynne
14 Jan 2022, 20:39 by d...@lynne.ee:

> 14 Jan 2022, 20:32 by mich...@niedermayer.cc:
>
>> On Fri, Jan 14, 2022 at 08:02:35PM +0100, Lynne wrote:
>>
>>> 14 Jan 2022, 18:48 by mich...@niedermayer.cc:
>>>
>>> > On Tue, Jan 04, 2022 at 04:08:49PM +0100, Lynne wrote:
>>> >
>>> >> Since I couldn't find a codename preference, I went with "Desitter"
>>> >>
>>> >
>>> > I just counted and i see 
>>> > 2 for Desitter (the initial from the past and you)
>>> > 3 for Lorentz  (the initial from the past, jb and reto )
>>> >
>>>
>>> Changed the name locally to Lorentz.
>>>
>>
>> ive just tagged the release and am uploading the tar.* files
>> so you can push this
>>
>
>  
> I've pinged j-b, since he wanted the announcement to wait
> on something.
>

Okay, the release will be officially out on 16:00 UTC+1 (CET) on Monday, the 
17th,
so I'll push the update to the webpage then.
Until then, go and test, or don't look back and hope a ninja 5.1 release won't 
be necessary :)
___
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] Website release notes for 5.0

2022-01-14 Thread Lynne
14 Jan 2022, 20:32 by mich...@niedermayer.cc:

> On Fri, Jan 14, 2022 at 08:02:35PM +0100, Lynne wrote:
>
>> 14 Jan 2022, 18:48 by mich...@niedermayer.cc:
>>
>> > On Tue, Jan 04, 2022 at 04:08:49PM +0100, Lynne wrote:
>> >
>> >> Since I couldn't find a codename preference, I went with "Desitter"
>> >>
>> >
>> > I just counted and i see 
>> > 2 for Desitter (the initial from the past and you)
>> > 3 for Lorentz  (the initial from the past, jb and reto )
>> >
>>
>> Changed the name locally to Lorentz.
>>
>
> ive just tagged the release and am uploading the tar.* files
> so you can push this
>

 
I've pinged j-b, since he wanted the announcement to wait
on something.
___
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] Website release notes for 5.0

2022-01-14 Thread Michael Niedermayer
On Fri, Jan 14, 2022 at 08:02:35PM +0100, Lynne wrote:
> 14 Jan 2022, 18:48 by mich...@niedermayer.cc:
> 
> > On Tue, Jan 04, 2022 at 04:08:49PM +0100, Lynne wrote:
> >
> >> Since I couldn't find a codename preference, I went with "Desitter"
> >>
> >
> > I just counted and i see 
> > 2 for Desitter (the initial from the past and you)
> > 3 for Lorentz  (the initial from the past, jb and reto )
> >
> 
> Changed the name locally to Lorentz.

ive just tagged the release and am uploading the tar.* files
so you can push this

thx
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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] Website release notes for 5.0

2022-01-14 Thread Lynne
14 Jan 2022, 18:48 by mich...@niedermayer.cc:

> On Tue, Jan 04, 2022 at 04:08:49PM +0100, Lynne wrote:
>
>> Since I couldn't find a codename preference, I went with "Desitter"
>>
>
> I just counted and i see 
> 2 for Desitter (the initial from the past and you)
> 3 for Lorentz  (the initial from the past, jb and reto )
>

Changed the name locally to Lorentz.
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Andreas Rheinhardt
Thilo Borgmann:
> Am 14.01.22 um 19:05 schrieb Andreas Rheinhardt:
>> Thilo Borgmann:
>>> Am 14.01.22 um 14:17 schrieb "zhilizhao(赵志立)":


> On Jan 14, 2022, at 8:14 PM, Thilo Borgmann  
> wrote:
>
> Am 06.01.22 um 12:27 schrieb Thilo Borgmann:
>> Am 03.01.22 um 16:22 schrieb Thilo Borgmann:
>>> Am 29.12.21 um 12:46 schrieb Nicolas George:
 "zhilizhao(赵志立)" (12021-12-29):
> How about add a restriction like this:
>
> if (format.endsWith(“%S"))
>enable the feature
> else
>warning message
>
> It’s a useful feature, it shouldn't create unexpected results, but
> doesn’t need to support every use case.

 I would not oppose it, but I find it inelegant, especially because it
 requires a different expansion function, localtime_ms instead of
 localtime.

 What about this: with the original function "localtime", if the format
 ends in "%3N", then append the millisecond. It can later be expanded to
 support %xN at any place in the format for any value of x.
>>>
>>> I think best will be to scan the format string for %S and extend it 
>>> there with .ms part before expanding the rest of it, not? Shouldn't be 
>>> too expensive for the filter.
>>>
>>> Just need to find time to actually implement it. 
>>
>> Like v5 as attached.


> +if (tag == 'M' || tag == 'm') {
> +char *seconds = av_stristr(fmt, "%S");
> +if (seconds) {
> +seconds += 2;
> +int len = seconds - fmt + 1;
> +char *tmp = av_malloc(len);
> +av_strlcpy(tmp, fmt, len);

 Firstly, mixed variable declaration and statements.

 Secondly, I think you don’t need ’tmp’, something like

 av_asprintf(“%.*s.%03d%s", len, fmt, (int)(unow % 100) / 1000, 
 seconds);
>>>
>>> You know your printf format-string :)
>>>
>>> Thanks, v6 attached.
>>> -Thilo
>>>
>>>
>>
>>>
>>> +int len = seconds + 2 - fmt;
>>> +char *fmt_new = av_asprintf("%.*s.%03d%s", len, fmt, 
>>> (int)(unow % 100) / 1000, seconds + 2);
>>> +av_bprint_strftime(bp, fmt_new, );
>>> +return 0;
>>> +}
>>
>> I see an unchecked allocation and a leak. 
> 
> Ok fmt_new might be null, where is the leak?
> 

Where is fmt_new freed?

> 
>> And it seems you are using a
>> format string that comes from the user. This is undefined behaviour if
>> this string contains an invalid conversion specifier.
> 
> I think that was unfortunately true before the patch as well, was it not?

Seems so.

> And if true or not, do we have something in place to check a user string?
> 

Afaik no.

- 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 v2] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Thilo Borgmann
Am 14.01.22 um 19:08 schrieb Nicolas George:
> Thilo Borgman (12022-01-14):
>> Ah and I misunderstood your other remark about it.
>>
>> What about adding an option for ms precision and stick to the existing
>> expansions localtime/gmtime, then add .ms if set by option?
> 
> I am not sure what you are suggesting.
> 
> How does it look like from the point of view of the user?

v6 does:

$> ffmpeg ... drawtext="fontfile=...:text='%{localtime   \:%a %b %d %Y %S}'"
   (seconds)
$> ffmpeg ... drawtext="fontfile=...:text='%{localtime_ms\:%a %b %d %Y %S}'"
   (milliseconds)

I suggest v7 should according to your remark:

$> ffmpeg ... drawtext="fontfile=...:text='%{localtime   \:%a %b %d %Y %S}'"
   (seconds)
$> ffmpeg ... drawtext="fontfile=...:text='%{localtime   \:%a %b %d %Y 
%S}':show_ms=1" (milliseconds)

Good?

-Thilo
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Thilo Borgmann
Am 14.01.22 um 19:05 schrieb Andreas Rheinhardt:
> Thilo Borgmann:
>> Am 14.01.22 um 14:17 schrieb "zhilizhao(赵志立)":
>>>
>>>
 On Jan 14, 2022, at 8:14 PM, Thilo Borgmann  wrote:

 Am 06.01.22 um 12:27 schrieb Thilo Borgmann:
> Am 03.01.22 um 16:22 schrieb Thilo Borgmann:
>> Am 29.12.21 um 12:46 schrieb Nicolas George:
>>> "zhilizhao(赵志立)" (12021-12-29):
 How about add a restriction like this:

 if (format.endsWith(“%S"))
enable the feature
 else
warning message

 It’s a useful feature, it shouldn't create unexpected results, but
 doesn’t need to support every use case.
>>>
>>> I would not oppose it, but I find it inelegant, especially because it
>>> requires a different expansion function, localtime_ms instead of
>>> localtime.
>>>
>>> What about this: with the original function "localtime", if the format
>>> ends in "%3N", then append the millisecond. It can later be expanded to
>>> support %xN at any place in the format for any value of x.
>>
>> I think best will be to scan the format string for %S and extend it 
>> there with .ms part before expanding the rest of it, not? Shouldn't be 
>> too expensive for the filter.
>>
>> Just need to find time to actually implement it. 
>
> Like v5 as attached.
>>>
>>>
 +if (tag == 'M' || tag == 'm') {
 +char *seconds = av_stristr(fmt, "%S");
 +if (seconds) {
 +seconds += 2;
 +int len = seconds - fmt + 1;
 +char *tmp = av_malloc(len);
 +av_strlcpy(tmp, fmt, len);
>>>
>>> Firstly, mixed variable declaration and statements.
>>>
>>> Secondly, I think you don’t need ’tmp’, something like
>>>
>>> av_asprintf(“%.*s.%03d%s", len, fmt, (int)(unow % 100) / 1000, seconds);
>>
>> You know your printf format-string :)
>>
>> Thanks, v6 attached.
>> -Thilo
>>
>>
> 
>>
>> +int len = seconds + 2 - fmt;
>> +char *fmt_new = av_asprintf("%.*s.%03d%s", len, fmt, (int)(unow 
>> % 100) / 1000, seconds + 2);
>> +av_bprint_strftime(bp, fmt_new, );
>> +return 0;
>> +}
> 
> I see an unchecked allocation and a leak. 

Ok fmt_new might be null, where is the leak?


> And it seems you are using a
> format string that comes from the user. This is undefined behaviour if
> this string contains an invalid conversion specifier.

I think that was unfortunately true before the patch as well, was it not?
And if true or not, do we have something in place to check a user string?

Thanks,
Thilo


___
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 v9 1/3] libavdevice/avfoundation.m: use AudioConvert, extend supported formats

2022-01-14 Thread Thilo Borgmann
Am 14.01.22 um 18:57 schrieb Romain Beauxis:
> Le ven. 14 janv. 2022 à 11:47, Thilo Borgmann  a 
> écrit :
>>
>> Am 14.01.22 um 13:57 schrieb Marvin Scholz:
>>>
>>>
>>> On 6 Jan 2022, at 15:24, Romain Beauxis wrote:
>>>
 * Implement support for AudioConverter
 * Switch to AudioConverter's API to convert unsupported PCM
   formats (non-interleaved, non-packed) to supported formats
 * Minimize data copy.

 This fixes: https://trac.ffmpeg.org/ticket/9502

 API ref:
 https://developer.apple.com/documentation/audiotoolbox/audio_converter_services

 Signed-off-by: Romain Beauxis 
 ---
 This is the first patch of a series of 3 that fix, cleanup and enhance the
 avfoundation implementation for libavdevice.

 These patches come from an actual user-facing application relying on
 libavdevice’s implementation of avfoundation audio input. Without them,
 Avfoundation is practically unusable as it will:
 * Refuse to process certain specific audio input format that are actually
 returned by the OS for some users (packed PCM audio)
 * Drop audio frames, resulting in corrupted audio input. This might have 
 been
 unnoticed with video frames but this makes avfoundation essentially 
 unusable
 for audio.

 The patches are now being included in our production build so they are 
 tested
 and usable in production.

>>>
>>> Hi,
>>>
>>> the patches are still corrupt and do not apply.
>>> As stated earlier, please either use git send-email or attach the patch
>>> to the mail instead of putting its contents in it, as apparently Mail.app
>>> messes them up.
>>
>> Still the same for me. Do you use git send-email or git format-patch?
> 
> Thanks for checking on this y'all and sorry about these complications.
> 

> I used git format-patches. I might try git send-email or the github PR
> bridge, that seems like a neat trick.

github PR sounds like something you don't want.

I use format-patch as well and attach the file (not sending via mail.app 
though).



> 
> I'm working on a new revision of the patches, I discovered more issues
> with audio conversion, possibly linked to bugs with the AudioConverter
> API.
> 
> I also discovered an API to do the conversion internally without
> having to deal with manually reconverting. Hopefully, this also fixes
> the issues we uncovered.
> 
> Will post once we have done more testing. All in all, macos sound APIs
> are pretty confusing and buggy around the edges it seems.

Cool.

-Thilo
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Nicolas George
Thilo Borgman (12022-01-14):
> Ah and I misunderstood your other remark about it.
> 
> What about adding an option for ms precision and stick to the existing
> expansions localtime/gmtime, then add .ms if set by option?

I am not sure what you are suggesting.

How does it look like from the point of view of the user?

Regards,

-- 
  Nicolas George


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 v2] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Andreas Rheinhardt
Thilo Borgmann:
> Am 14.01.22 um 14:17 schrieb "zhilizhao(赵志立)":
>>
>>
>>> On Jan 14, 2022, at 8:14 PM, Thilo Borgmann  wrote:
>>>
>>> Am 06.01.22 um 12:27 schrieb Thilo Borgmann:
 Am 03.01.22 um 16:22 schrieb Thilo Borgmann:
> Am 29.12.21 um 12:46 schrieb Nicolas George:
>> "zhilizhao(赵志立)" (12021-12-29):
>>> How about add a restriction like this:
>>>
>>> if (format.endsWith(“%S"))
>>>enable the feature
>>> else
>>>warning message
>>>
>>> It’s a useful feature, it shouldn't create unexpected results, but
>>> doesn’t need to support every use case.
>>
>> I would not oppose it, but I find it inelegant, especially because it
>> requires a different expansion function, localtime_ms instead of
>> localtime.
>>
>> What about this: with the original function "localtime", if the format
>> ends in "%3N", then append the millisecond. It can later be expanded to
>> support %xN at any place in the format for any value of x.
>
> I think best will be to scan the format string for %S and extend it there 
> with .ms part before expanding the rest of it, not? Shouldn't be too 
> expensive for the filter.
>
> Just need to find time to actually implement it. 

 Like v5 as attached.
>>
>>
>>> +if (tag == 'M' || tag == 'm') {
>>> +char *seconds = av_stristr(fmt, "%S");
>>> +if (seconds) {
>>> +seconds += 2;
>>> +int len = seconds - fmt + 1;
>>> +char *tmp = av_malloc(len);
>>> +av_strlcpy(tmp, fmt, len);
>>
>> Firstly, mixed variable declaration and statements.
>>
>> Secondly, I think you don’t need ’tmp’, something like
>>
>> av_asprintf(“%.*s.%03d%s", len, fmt, (int)(unow % 100) / 1000, seconds);
> 
> You know your printf format-string :)
> 
> Thanks, v6 attached.
> -Thilo
> 
> 

> 
> +int len = seconds + 2 - fmt;
> +char *fmt_new = av_asprintf("%.*s.%03d%s", len, fmt, (int)(unow 
> % 100) / 1000, seconds + 2);
> +av_bprint_strftime(bp, fmt_new, );
> +return 0;
> +}

I see an unchecked allocation and a leak. And it seems you are using a
format string that comes from the user. This is undefined behaviour if
this string contains an invalid conversion specifier.

- 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 v2] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Thilo Borgmann
Am 14.01.22 um 18:57 schrieb Nicolas George:
> Thilo Borgman (12022-01-14):
 I think best will be to scan the format string for %S and extend it
 there with .ms part before expanding the rest of it, not? Shouldn't
 be too expensive for the filter.

 Just need to find time to actually implement it. 
> 
> Sorry, I completely missed you reply.
> 
> No, I do not think it is best: your solution requires the user to use a
> different function, I find this inelegant and not user friendly. I like
> the solution where the option is enabled by the format string itself
> much more user friendly. But we can discuss it.

Ah and I misunderstood your other remark about it.

What about adding an option for ms precision and stick to the existing 
expansions localtime/gmtime, then add .ms if set by option?

Thanks,
Thilo
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Zhao Zhili


> On Jan 15, 2022, at 1:40 AM, Thilo Borgmann  wrote:
>> 
>>> +if (tag == 'M' || tag == 'm') {
>>> +char *seconds = av_stristr(fmt, "%S");
>>> +if (seconds) {
>>> +seconds += 2;
>>> +int len = seconds - fmt + 1;
>>> +char *tmp = av_malloc(len);
>>> +av_strlcpy(tmp, fmt, len);
>> 
>> Firstly, mixed variable declaration and statements.
>> 
>> Secondly, I think you don’t need ’tmp’, something like
>> 
>> av_asprintf(“%.*s.%03d%s", len, fmt, (int)(unow % 100) / 1000, seconds);
> 
> You know your printf format-string :)
> 
> Thanks, v6 attached.

LGTM now. Looking forward to use it for end-to-end latency test.

> -Thilo
> 
> 
> ___
> 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 v9 1/3] libavdevice/avfoundation.m: use AudioConvert, extend supported formats

2022-01-14 Thread Romain Beauxis
Le ven. 14 janv. 2022 à 11:47, Thilo Borgmann  a écrit :
>
> Am 14.01.22 um 13:57 schrieb Marvin Scholz:
> >
> >
> > On 6 Jan 2022, at 15:24, Romain Beauxis wrote:
> >
> >> * Implement support for AudioConverter
> >> * Switch to AudioConverter's API to convert unsupported PCM
> >>   formats (non-interleaved, non-packed) to supported formats
> >> * Minimize data copy.
> >>
> >> This fixes: https://trac.ffmpeg.org/ticket/9502
> >>
> >> API ref:
> >> https://developer.apple.com/documentation/audiotoolbox/audio_converter_services
> >>
> >> Signed-off-by: Romain Beauxis 
> >> ---
> >> This is the first patch of a series of 3 that fix, cleanup and enhance the
> >> avfoundation implementation for libavdevice.
> >>
> >> These patches come from an actual user-facing application relying on
> >> libavdevice’s implementation of avfoundation audio input. Without them,
> >> Avfoundation is practically unusable as it will:
> >> * Refuse to process certain specific audio input format that are actually
> >> returned by the OS for some users (packed PCM audio)
> >> * Drop audio frames, resulting in corrupted audio input. This might have 
> >> been
> >> unnoticed with video frames but this makes avfoundation essentially 
> >> unusable
> >> for audio.
> >>
> >> The patches are now being included in our production build so they are 
> >> tested
> >> and usable in production.
> >>
> >
> > Hi,
> >
> > the patches are still corrupt and do not apply.
> > As stated earlier, please either use git send-email or attach the patch
> > to the mail instead of putting its contents in it, as apparently Mail.app
> > messes them up.
>
> Still the same for me. Do you use git send-email or git format-patch?

Thanks for checking on this y'all and sorry about these complications.

I used git format-patches. I might try git send-email or the github PR
bridge, that seems like a neat trick.

I'm working on a new revision of the patches, I discovered more issues
with audio conversion, possibly linked to bugs with the AudioConverter
API.

I also discovered an API to do the conversion internally without
having to deal with manually reconverting. Hopefully, this also fixes
the issues we uncovered.

Will post once we have done more testing. All in all, macos sound APIs
are pretty confusing and buggy around the edges it seems.

Thanks again!
-- Romain
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Nicolas George
Thilo Borgman (12022-01-14):
> >> I think best will be to scan the format string for %S and extend it
> >> there with .ms part before expanding the rest of it, not? Shouldn't
> >> be too expensive for the filter.
> >>
> >> Just need to find time to actually implement it. 

Sorry, I completely missed you reply.

No, I do not think it is best: your solution requires the user to use a
different function, I find this inelegant and not user friendly. I like
the solution where the option is enabled by the format string itself
much more user friendly. But we can discuss it.

Regards,

-- 
  Nicolas George


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 03/24] avcodec/subtitles: Introduce new frame-based subtitle decoding API

2022-01-14 Thread Andreas Rheinhardt
ffmpegagent:
> From: softworkz 
> 
> - Add avcodec_decode_subtitle3 which takes subtitle frames,
>   serving as compatibility shim to legacy subtitle decoding
> - Add additional methods for conversion between old and new API

This commit message is completely wrong.

> 
> Signed-off-by: softworkz 
> ---
>  libavcodec/avcodec.h|   8 +-
>  libavcodec/codec_desc.c |  11 +++
>  libavcodec/codec_desc.h |   8 ++
>  libavcodec/decode.c |  56 ++--
>  libavcodec/internal.h   |  22 +
>  libavcodec/utils.c  | 184 
>  6 files changed, 280 insertions(+), 9 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fe5a83cf85..9d59f6e840 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1675,7 +1675,7 @@ typedef struct AVCodecContext {
>  
>  /**
>   * Header containing style information for text subtitles.
> - * For SUBTITLE_ASS subtitle type, it should contain the whole ASS
> + * For AV_SUBTITLE_FMT_ASS subtitle type, it should contain the whole ASS
>   * [Script Info] and [V4+ Styles] section, plus the [Events] line and
>   * the Format line following. It shouldn't include any Dialogue line.
>   * - encoding: Set/allocated/freed by user (before avcodec_open2())
> @@ -2415,7 +2415,10 @@ int avcodec_close(AVCodecContext *avctx);
>   * Free all allocated data in the given subtitle struct.
>   *
>   * @param sub AVSubtitle to free.
> + *
> + * @deprecated Use the regular frame based encode and decode APIs instead.
>   */
> +attribute_deprecated
>  void avsubtitle_free(AVSubtitle *sub);
>  
>  /**
> @@ -2508,7 +2511,10 @@ enum AVChromaLocation avcodec_chroma_pos_to_enum(int 
> xpos, int ypos);
>   * must be freed with avsubtitle_free if *got_sub_ptr is set.
>   * @param[in,out] got_sub_ptr Zero if no subtitle could be decompressed, 
> otherwise, it is nonzero.
>   * @param[in] avpkt The input AVPacket containing the input buffer.
> + *
> + * @deprecated Use the new decode API (avcodec_send_packet, 
> avcodec_receive_frame) instead.
>   */
> +attribute_deprecated
>  int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub,
>  int *got_sub_ptr,
>  AVPacket *avpkt);
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 0974ee03de..e48e4532ba 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -3548,3 +3548,14 @@ enum AVMediaType avcodec_get_type(enum AVCodecID 
> codec_id)
>  const AVCodecDescriptor *desc = avcodec_descriptor_get(codec_id);
>  return desc ? desc->type : AVMEDIA_TYPE_UNKNOWN;
>  }
> +
> +enum AVSubtitleType avcodec_descriptor_get_subtitle_format(const 
> AVCodecDescriptor *codec_descriptor)
> +{
> +if(codec_descriptor->props & AV_CODEC_PROP_BITMAP_SUB)
> +return AV_SUBTITLE_FMT_BITMAP;
> +
> +if(codec_descriptor->props & AV_CODEC_PROP_TEXT_SUB)
> +return AV_SUBTITLE_FMT_ASS;
> +
> +return AV_SUBTITLE_FMT_UNKNOWN;
> +}
> diff --git a/libavcodec/codec_desc.h b/libavcodec/codec_desc.h
> index 126b52df47..ba68d24e0e 100644
> --- a/libavcodec/codec_desc.h
> +++ b/libavcodec/codec_desc.h
> @@ -121,6 +121,14 @@ const AVCodecDescriptor *avcodec_descriptor_next(const 
> AVCodecDescriptor *prev);
>   */
>  const AVCodecDescriptor *avcodec_descriptor_get_by_name(const char *name);
>  
> +/**
> + * Return subtitle format from a codec descriptor
> + *
> + * @param codec_descriptor codec descriptor
> + * @return the subtitle type (e.g. bitmap, text)
> + */
> +enum AVSubtitleType avcodec_descriptor_get_subtitle_format(const 
> AVCodecDescriptor *codec_descriptor);
> +
>  /**
>   * @}
>   */
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 0912f86a14..ab8a6ea6ff 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -576,6 +576,39 @@ static int decode_receive_frame_internal(AVCodecContext 
> *avctx, AVFrame *frame)
>  return ret;
>  }
>  
> +static int decode_subtitle2_priv(AVCodecContext *avctx, AVSubtitle *sub,
> + int *got_sub_ptr, AVPacket *avpkt);
> +
> +static int decode_subtitle_shim(AVCodecContext *avctx, AVFrame *frame, 
> AVPacket *avpkt)
> +{
> +int ret, got_sub_ptr = 0;
> +AVSubtitle subtitle = { 0 };
> +
> +if (frame->buf[0])
> +return AVERROR(EAGAIN);
> +
> +av_frame_unref(frame);
> +
> +ret = decode_subtitle2_priv(avctx, , _sub_ptr, avpkt);
> +
> +if (ret >= 0 && got_sub_ptr) {
> +frame->type = AVMEDIA_TYPE_SUBTITLE;
> +frame->format = subtitle.format;
> +ret = av_frame_get_buffer2(frame, 0);
> +
> +if (ret >= 0)
> +ret = ff_frame_put_subtitle(frame, );
> +
> +frame->width = avctx->width;
> +frame->height = avctx->height;
> +frame->pkt_dts = avpkt->dts;
> +}
> +
> +avsubtitle_free();
> +
> +return ret;
> +}
> +
>  int 

Re: [FFmpeg-devel] [PATCH] Website release notes for 5.0

2022-01-14 Thread Michael Niedermayer
On Tue, Jan 04, 2022 at 04:08:49PM +0100, Lynne wrote:
> Since I couldn't find a codename preference, I went with "Desitter"

I just counted and i see 
2 for Desitter (the initial from the past and you)
3 for Lorentz  (the initial from the past, jb and reto )



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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 v9 1/3] libavdevice/avfoundation.m: use AudioConvert, extend supported formats

2022-01-14 Thread Thilo Borgmann
Am 14.01.22 um 13:57 schrieb Marvin Scholz:
> 
> 
> On 6 Jan 2022, at 15:24, Romain Beauxis wrote:
> 
>> * Implement support for AudioConverter
>> * Switch to AudioConverter's API to convert unsupported PCM
>>   formats (non-interleaved, non-packed) to supported formats
>> * Minimize data copy.
>>
>> This fixes: https://trac.ffmpeg.org/ticket/9502
>>
>> API ref:
>> https://developer.apple.com/documentation/audiotoolbox/audio_converter_services
>>
>> Signed-off-by: Romain Beauxis 
>> ---
>> This is the first patch of a series of 3 that fix, cleanup and enhance the
>> avfoundation implementation for libavdevice.
>>
>> These patches come from an actual user-facing application relying on
>> libavdevice’s implementation of avfoundation audio input. Without them,
>> Avfoundation is practically unusable as it will:
>> * Refuse to process certain specific audio input format that are actually
>> returned by the OS for some users (packed PCM audio)
>> * Drop audio frames, resulting in corrupted audio input. This might have been
>> unnoticed with video frames but this makes avfoundation essentially unusable
>> for audio.
>>
>> The patches are now being included in our production build so they are tested
>> and usable in production.
>>
> 
> Hi,
> 
> the patches are still corrupt and do not apply.
> As stated earlier, please either use git send-email or attach the patch
> to the mail instead of putting its contents in it, as apparently Mail.app
> messes them up.

Still the same for me. Do you use git send-email or git format-patch?

-Thilo
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Thilo Borgmann
Am 14.01.22 um 14:17 schrieb "zhilizhao(赵志立)":
> 
> 
>> On Jan 14, 2022, at 8:14 PM, Thilo Borgmann  wrote:
>>
>> Am 06.01.22 um 12:27 schrieb Thilo Borgmann:
>>> Am 03.01.22 um 16:22 schrieb Thilo Borgmann:
 Am 29.12.21 um 12:46 schrieb Nicolas George:
> "zhilizhao(赵志立)" (12021-12-29):
>> How about add a restriction like this:
>>
>> if (format.endsWith(“%S"))
>>enable the feature
>> else
>>warning message
>>
>> It’s a useful feature, it shouldn't create unexpected results, but
>> doesn’t need to support every use case.
>
> I would not oppose it, but I find it inelegant, especially because it
> requires a different expansion function, localtime_ms instead of
> localtime.
>
> What about this: with the original function "localtime", if the format
> ends in "%3N", then append the millisecond. It can later be expanded to
> support %xN at any place in the format for any value of x.

 I think best will be to scan the format string for %S and extend it there 
 with .ms part before expanding the rest of it, not? Shouldn't be too 
 expensive for the filter.

 Just need to find time to actually implement it. 
>>>
>>> Like v5 as attached.
> 
> 
>> +if (tag == 'M' || tag == 'm') {
>> +char *seconds = av_stristr(fmt, "%S");
>> +if (seconds) {
>> +seconds += 2;
>> +int len = seconds - fmt + 1;
>> +char *tmp = av_malloc(len);
>> +av_strlcpy(tmp, fmt, len);
> 
> Firstly, mixed variable declaration and statements.
> 
> Secondly, I think you don’t need ’tmp’, something like
> 
> av_asprintf(“%.*s.%03d%s", len, fmt, (int)(unow % 100) / 1000, seconds);

You know your printf format-string :)

Thanks, v6 attached.
-Thilo

From 603a52a2bb86e558acdd754d8322e89e984dad08 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Fri, 14 Jan 2022 18:38:14 +0100
Subject: [PATCH v6] lavfi/drawtext: Add localtime_ms for millisecond precision

Suggested-By: ffm...@fb.com
---
 doc/filters.texi  |  8 
 libavfilter/vf_drawtext.c | 20 ++--
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 05d4b1a56e..967021e48b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11379,10 +11379,18 @@ It can be used to add padding with zeros from the 
left.
 The time at which the filter is running, expressed in UTC.
 It can accept an argument: a strftime() format string.
 
+@item gmtime_ms
+Same as @code{gmtime} but with millisecond precision.
+It can accept an argument: a strftime() format string.
+
 @item localtime
 The time at which the filter is running, expressed in the local time zone.
 It can accept an argument: a strftime() format string.
 
+@item localtime_ms
+Same as @code{localtime} but with millisecond precision.
+It can accept an argument: a strftime() format string.
+
 @item metadata
 Frame metadata. Takes one or two arguments.
 
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 2a88692cbd..7e3771fdca 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -51,6 +51,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/random_seed.h"
 #include "libavutil/parseutils.h"
+#include "libavutil/time.h"
 #include "libavutil/timecode.h"
 #include "libavutil/time_internal.h"
 #include "libavutil/tree.h"
@@ -1045,14 +1046,27 @@ static int func_strftime(AVFilterContext *ctx, AVBPrint 
*bp,
  char *fct, unsigned argc, char **argv, int tag)
 {
 const char *fmt = argc ? argv[0] : "%Y-%m-%d %H:%M:%S";
+int64_t unow;
 time_t now;
 struct tm tm;
 
-time();
-if (tag == 'L')
+unow = av_gettime();
+now  = unow / 100;
+if (tag == 'L' || tag == 'm')
 localtime_r(, );
 else
 tm = *gmtime_r(, );
+
+if (tag == 'M' || tag == 'm') {
+char *seconds = av_stristr(fmt, "%S");
+if (seconds) {
+int len = seconds + 2 - fmt;
+char *fmt_new = av_asprintf("%.*s.%03d%s", len, fmt, (int)(unow % 
100) / 1000, seconds + 2);
+av_bprint_strftime(bp, fmt_new, );
+return 0;
+}
+}
+
 av_bprint_strftime(bp, fmt, );
 return 0;
 }
@@ -1152,7 +1166,9 @@ static const struct drawtext_function {
 { "pict_type", 0, 0, 0,   func_pict_type },
 { "pts",   0, 3, 0,   func_pts  },
 { "gmtime",0, 1, 'G', func_strftime },
+{ "gmtime_ms", 0, 1, 'M', func_strftime },
 { "localtime", 0, 1, 'L', func_strftime },
+{ "localtime_ms", 0, 1, 'm', func_strftime },
 { "frame_num", 0, 0, 0,   func_frame_num },
 { "n", 0, 0, 0,   func_frame_num },
 { "metadata",  1, 2, 0,   func_metadata },
-- 
2.20.1 (Apple Git-117)

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

To unsubscribe, visit 

Re: [FFmpeg-devel] [PATCH] vf_paletteuse: fix color cache lookup for Bayer dithering mode.

2022-01-14 Thread Gyan Doshi

O

On 2022-01-14 10:53 pm, Thierry Foucu wrote:

On Mon, Jan 10, 2022 at 10:32 AM Paul B Mahol  wrote:


LGTM


Any chance to push this change?


On Sunday, if no one else does.

Regards,
Gyan
___
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] vf_paletteuse: fix color cache lookup for Bayer dithering mode.

2022-01-14 Thread Thierry Foucu
On Mon, Jan 10, 2022 at 10:32 AM Paul B Mahol  wrote:

> LGTM
>

Any chance to push this change?


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


-- 

Thierry Foucu
___
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 06/24] avcodec/subtitles: Migrate subtitle encoders to frame-based API

2022-01-14 Thread Michael Niedermayer
On Fri, Jan 14, 2022 at 01:13:15AM +, ffmpegagent wrote:
> From: softworkz 
> 
> and provide a compatibility shim for the legacy api
> 
> Signed-off-by: softworkz 
> ---
>  libavcodec/assenc.c| 189 ++---
>  libavcodec/avcodec.h   |   5 +-
>  libavcodec/dvbsubenc.c |  96 ++-
>  libavcodec/dvdsubenc.c | 102 
>  libavcodec/encode.c|  57 ++-
>  libavcodec/movtextenc.c| 114 --
>  libavcodec/srtenc.c| 108 ++---
>  libavcodec/tests/avcodec.c |   2 -
>  libavcodec/ttmlenc.c   | 101 +++-
>  libavcodec/webvttenc.c |  86 -
>  libavcodec/xsubenc.c   |  88 ++---
>  11 files changed, 685 insertions(+), 263 deletions(-)

is this supposed to pass make fate without the later patches ?

it seems not here:

--- ./tests/ref/fate/sub-webvtt22022-01-13 23:24:22.195685643 +0100
+++ tests/data/fate/sub-webvtt2 2022-01-14 18:04:09.528302263 +0100
@@ -11,15 +11,3 @@
 
 [Events]
 Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
-Dialogue: 0,0:00:00.00,0:00:20.00,Default,,0,0,0,,Hi, my name is Fred
-Dialogue: 0,0:00:02.50,0:00:22.50,Default,,0,0,0,,Hi, I’m Bill
-Dialogue: 0,0:00:05.00,0:00:25.00,Default,,0,0,0,,Would you like to get a 
coffee?
-Dialogue: 0,0:00:07.50,0:00:27.50,Default,,0,0,0,,Sure! I’ve only had one 
today.
-Dialogue: 0,0:00:10.00,0:00:30.00,Default,,0,0,0,,This is my fourth!
-Dialogue: 0,0:00:12.50,0:00:32.50,Default,,0,0,0,,OK, let’s go.
-Dialogue: 0,0:00:38.00,0:00:43.00,Default,,0,0,0,,I want to 愛あい love 
you\NThat's not proper English!
-Dialogue: 0,0:00:43.00,0:00:46.00,Default,,0,0,0,,{\i1}キツネ{\i0}じゃない 
キツネじゃない\N乙女おとめは
-Dialogue: 0,0:00:50.00,0:00:55.00,Default,,0,0,0,,Some time ago in a rather 
distant place
-Dialogue: 0,0:00:55.00,0:01:00.00,Default,,0,0,0,,Descending: 
123456\NAscending: 123456
-Dialogue: 0,0:01:00.00,0:01:05.00,Default,,0,0,0,,>> Never gonna give you up 
Never gonna let you down\NNever\hgonna\hrun\haround & desert\hyou
-Dialogue: 0,0:55:00.00,1:00:00.00,Default,,0,0,0,,Transcrit par Célestes™
Test sub-webvtt2 failed. Look at tests/data/fate/sub-webvtt2.err for details.
tests/Makefile:256: recipe for target 'fate-sub-webvtt2' failed
make: *** [fate-sub-webvtt2] Error 139

if you cannot reproduce then say so and ill get e better backtrace

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in  ()
#1  0x55c7d2cf in avcodec_encode_subtitle ()
#2  0x55744daa in transcode_subtitles ()
#3  0x5574b9eb in process_input_packet ()
#4  0x5574d64d in transcode ()
#5  0x55725ebc in main ()



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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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 21/24] fftools/ffmpeg: Introduce subtitle filtering new frame-based subtitle encoding

2022-01-14 Thread Michael Niedermayer
On Fri, Jan 14, 2022 at 01:13:30AM +, ffmpegagent wrote:
> From: softworkz 
> 
> This commit actually enables subtitle filtering in ffmpeg by
> sending and receiving subtitle frames to and from a filtergraph.
> 
> The heartbeat functionality from the previous sub2video implementation
> is removed and now provided by the 'subfeed' filter.
> The other part of sub2video functionality is retained by
> auto-insertion of the new graphicsub2video filter.
> 
> Justification for changed test refs:
> 
> - sub2video
>   The new results are identical excepting the last frame which
>   is due to the implementation changes
> 
> - sub2video_basic
>   The previous results had some incorrect output because multiple
>   frames had the same dts
>   The non-empty content frames are visually identical, the different
>   CRC is due to the different blending algorithm that is being used.
> 
> - sub2video_time_limited
>   The third frame in the previous ref was a repetition, which doesn't
>   happen anymore with the new subtitle filtering.
> 
> - sub-dvb
>   Running ffprobe -show_frames on the source file shows that there
>   are 7 subtitle frames with 0 rects in the source at the start
>   and 2 at the end. This translates to the 14 and 4 additional
>   entries in the new test results.
> 
> - filter-overlay-dvdsub-2397
>   Overlay results have slightly different CRCs due to different
>   blending implementation
> 
> Signed-off-by: softworkz 
> ---
>  fftools/ffmpeg.c  |  493 
>  fftools/ffmpeg.h  |   13 +-
>  fftools/ffmpeg_filter.c   |  235 ++--
>  fftools/ffmpeg_hw.c   |2 +-
>  fftools/ffmpeg_opt.c  |3 +-
>  tests/ref/fate/filter-overlay-dvdsub-2397 |  182 +--
>  tests/ref/fate/sub-dvb|  162 +--
>  tests/ref/fate/sub2video  | 1091 +-
>  tests/ref/fate/sub2video_basic| 1239 +++--
>  tests/ref/fate/sub2video_time_limited |   78 +-
>  10 files changed, 2829 insertions(+), 669 deletions(-)

./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' 
-qscale 2  -t 3 f.avi

Press [q] to stop, [?] for help
Auto-inserting subfeed filter
Auto-inserting graphicsub2video filter
Assertion c > 0 failed at libavutil/mathematics.c:60
Aborted (core dumped)


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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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] avfilter: Added siti filter

2022-01-14 Thread Thilo Borgmann
Hi,

Am 19.01.21 um 05:49 schrieb Lynne:
> Jan 19, 2021, 01:07 by borba...@fb.com:
> 
>> Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as 
>> defined
>> in ITU-T P.910: Subjective video quality assessment methods for multimedia
>> applications.
>>
>> Update: Fixed bracket style.
>>
> 
> Thanks, looks much neater now.
> 
> 
> 
>> I'm already adding the data to the frame's metadata, is the suggestion to 
>> remove the file option altogether?
>>
> 
> Yes. We want to avoid filters having their own file in/out options rather
> than using generic ones.

Updated the patch to apply to git HEAD.
Removed file output.
Made printing summary to console optional.


>> +
>> +#include "libavutil/imgutils.h"
>> +#include "libavutil/internal.h"
>> +#include "libavutil/opt.h"
>> +
>> +#include "avfilter.h"
>> +#include "formats.h"
>> +#include "internal.h"
>> +#include "video.h"
>> +
>> +static const int X_FILTER[9] = {
>> +1, 0, -1,
>> +2, 0, -2,
>> +1, 0, -1
>> +};
>> +
>> +static const int Y_FILTER[9] = {
>> +1, 2, 1,
>> +0, 0, 0,
>> +-1, -2, -1
>> +};
>>
> 
> We have optimized assembly to apply 3x3 matrices. Check out
> libavfilter/x86/vf_convolution.asm:ff_filter_3x3_sse4
>  vf_convolution already applies a sobel filter that way. Maybe
> look into sharing some DSP code with it?

I checked a bit since I also want a common sobel for vf_edgedetect / my patch 
for vf_blurriness.

For sobel, there is no direct asm implementation. We have a generic filter_3x3 
with sse4 optimization. To use sobel with that, you'd need to run two times 
filter_3x3 plus one pass for gradient calculation.

As another difference, this filter (SITI) does on-the-fly conversion to 
full-range pixel values during its sobel. While vf_edgedetect / vf_bluriness 
use an abbreviation for the gradients during its sobel. Which makes them both 
distinct enough not to fit into a general filter_3x3 or filter_sobel from 
vf_convolution easily (and more overhead). So I think it's not worth the effort 
to force them into a common function? (Especially since we don't have a 
sobel_sse4 or something)

Patch without a common sobel attached.

-Thilo


From 4744ce289f3ddfd797886a6240971aff0359b937 Mon Sep 17 00:00:00 2001
From: Boris Baracaldo 
Date: Fri, 14 Jan 2022 16:11:54 +0100
Subject: [PATCH 1/2] lavfilter: Add SITI filter

Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as 
defined
in ITU-T P.910: Subjective video quality assessment methods for multimedia
applications.
---
 Changelog|   1 +
 doc/filters.texi |  24 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/version.h|   2 +-
 libavfilter/vf_siti.c| 296 +++
 6 files changed, 324 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vf_siti.c

diff --git a/Changelog b/Changelog
index 3dde3326be..dcb2c368d2 100644
--- a/Changelog
+++ b/Changelog
@@ -132,6 +132,7 @@ version 4.4:
 - msad video filter
 - gophers protocol
 - RIST protocol via librist
+- siti filter
 
 
 version 4.3:
diff --git a/doc/filters.texi b/doc/filters.texi
index 05d4b1a56e..dca7171a95 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19875,6 +19875,30 @@ ffmpeg -i input1.mkv -i input2.mkv -filter_complex 
"[0:v][1:v] signature=nb_inpu
 
 @end itemize
 
+@anchor{siti}
+@section siti
+
+Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as 
defined
+in ITU-T P.910: Subjective video quality assessment methods for multimedia
+applications. Available PDF at 
@url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
+Per frame metrics can be written into a file in csv format.
+
+It accepts the following option:
+
+@table @option
+@item print_summary
+If set to 1, Summary statistics will be printed to the console. Default 0.
+@end table
+
+@subsection Examples
+@itemize
+@item
+To calculate SI/TI metrics and print summary:
+@example
+ffmpeg -i input.mp4 -vf siti=print_summary=1 -f null -
+@end example
+@end itemize
+
 @anchor{smartblur}
 @section smartblur
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1adbea75bd..3261d05311 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -454,6 +454,7 @@ OBJS-$(CONFIG_SMARTBLUR_FILTER)  += 
vf_smartblur.o
 OBJS-$(CONFIG_SOBEL_FILTER)  += vf_convolution.o
 OBJS-$(CONFIG_SOBEL_OPENCL_FILTER)   += vf_convolution_opencl.o 
opencl.o \
 opencl/convolution.o
+OBJS-$(CONFIG_SITI_FILTER)   += vf_siti.o
 OBJS-$(CONFIG_SPLIT_FILTER)  += split.o
 OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
 OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 4325a3e557..808c172b28 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -430,6 +430,7 @@ extern const AVFilter 

[FFmpeg-devel] [PATCH] avcodec/libmp3lame: check channel count after the lame_init_params()

2022-01-14 Thread James Almer
LAME will silently change the channel count value if you pass it an unsupported
one.
This should normally not be an issue as we ensure only 1 and 2 channel streams
are ever initialized, but since LAME could make changes outside our control
anytime, add an extra check for this.

Signed-off-by: James Almer 
---
A crash can be triggered if you remove the AVCodec.channel_layouts array, in
which case non-mono and non-stereo streams will be initialized, but LAME will
try to encode them as if they were stereo.

I decided to not make this an assert() since, like i said above and even if
unlikely to happen, LAME could make changes and suddenly the list of valid
layouts we defined is no longer correct.

 libavcodec/libmp3lame.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index 5675864bb2..93d2ef348a 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -142,6 +142,15 @@ static av_cold int mp3lame_encode_init(AVCodecContext 
*avctx)
 goto error;
 }
 
+/* LAME does not error out on unsupported channel values and silently
+ * changes it to a supported one. Look for this and abort.
+ */
+if (lame_get_num_channels(s->gfp) != avctx->channels) {
+av_log(avctx, AV_LOG_ERROR, "Incosistent channel count\n");
+ret = AVERROR_EXTERNAL;
+goto error;
+}
+
 /* get encoder delay */
 avctx->initial_padding = lame_get_encoder_delay(s->gfp) + 528 + 1;
 ff_af_queue_init(avctx, >afq);
-- 
2.34.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 v3 2/3] avcodec/libopenh264enc: make the profile configuablable correctly

2022-01-14 Thread lance . lmwang
On Fri, Jan 14, 2022 at 02:07:26PM +0200, Martin Storsjö wrote:
> On Fri, 14 Jan 2022, lance.lmw...@gmail.com wrote:
> 
> > From: Limin Wang 
> > 
> > due to the limitations set in d3a7bdd4ac54349aea9150a234478635d50ebd87,
> > you weren't able to use main profile with OpenH264 1.8, or high profile
> > with older versions
> > 
> > Reviewed-by: Martin Storsjö 
> > Signed-off-by: Limin Wang 
> > ---
> > libavcodec/libopenh264enc.c | 8 
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> > index 5b5914c..1bad233 100644
> > --- a/libavcodec/libopenh264enc.c
> > +++ b/libavcodec/libopenh264enc.c
> > @@ -220,26 +220,25 @@ static av_cold int svc_encode_init(AVCodecContext 
> > *avctx)
> > #endif
> > 
> > switch (s->profile) {
> > -#if OPENH264_VER_AT_LEAST(1, 8)
> > case FF_PROFILE_H264_HIGH:
> > param.iEntropyCodingModeFlag = 1;
> > av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
> > "select EProfileIdc PRO_HIGH in libopenh264.\n");
> > break;
> > -#else
> > case FF_PROFILE_H264_MAIN:
> > param.iEntropyCodingModeFlag = 1;
> > av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
> > "select EProfileIdc PRO_MAIN in libopenh264.\n");
> > break;
> > -#endif
> > -case FF_PROFILE_H264_CONSTRAINED_BASELINE:
> > case FF_PROFILE_UNKNOWN:
> > +s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
> > +case FF_PROFILE_H264_CONSTRAINED_BASELINE:
> 
> I don't think it's specifically necessary to move the case labels around
> like this; you could just leave both case labels above it, and the
> assignment would be a no-op for one case. (No need to resend the patch for
> that, do whichever form you prefer.)

OK, will not move the case lables as suggestion.

> 
> > param.iEntropyCodingModeFlag = 0;
> > av_log(avctx, AV_LOG_VERBOSE, "Using CAVLC, "
> >"select EProfileIdc PRO_BASELINE in libopenh264.\n");
> > break;
> > default:
> > +s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
> > param.iEntropyCodingModeFlag = 0;
> > av_log(avctx, AV_LOG_WARNING, "Unsupported profile, "
> >"select EProfileIdc PRO_BASELINE in libopenh264.\n");
> > @@ -251,6 +250,7 @@ static av_cold int svc_encode_init(AVCodecContext 
> > *avctx)
> > param.sSpatialLayers[0].fFrameRate  = param.fMaxFrameRate;
> > param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
> > param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
> > +param.sSpatialLayers[0].uiProfileIdc= s->profile;
> 
> Thanks, this seems sensible to me. This is ok if you've tested that setting
> profile to FF_PROFILE_H264_CONSTRAINED_BASELINE (as opposed to PRO_BASELINE)
> does work with both some old and some recent version of OpenH264.

Yes, have tested with v1.4.0, v1.7.0 and master.

> 
> // Martin


-- 
Thanks,
Limin Wang
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread zhilizhao(赵志立)


> On Jan 14, 2022, at 8:14 PM, Thilo Borgmann  wrote:
> 
> Am 06.01.22 um 12:27 schrieb Thilo Borgmann:
>> Am 03.01.22 um 16:22 schrieb Thilo Borgmann:
>>> Am 29.12.21 um 12:46 schrieb Nicolas George:
 "zhilizhao(赵志立)" (12021-12-29):
> How about add a restriction like this:
> 
> if (format.endsWith(“%S"))
>enable the feature
> else
>warning message
> 
> It’s a useful feature, it shouldn't create unexpected results, but
> doesn’t need to support every use case.
 
 I would not oppose it, but I find it inelegant, especially because it
 requires a different expansion function, localtime_ms instead of
 localtime.
 
 What about this: with the original function "localtime", if the format
 ends in "%3N", then append the millisecond. It can later be expanded to
 support %xN at any place in the format for any value of x.
>>> 
>>> I think best will be to scan the format string for %S and extend it there 
>>> with .ms part before expanding the rest of it, not? Shouldn't be too 
>>> expensive for the filter.
>>> 
>>> Just need to find time to actually implement it. 
>> 
>> Like v5 as attached.


> +if (tag == 'M' || tag == 'm') {
> +char *seconds = av_stristr(fmt, "%S");
> +if (seconds) {
> +seconds += 2;
> +int len = seconds - fmt + 1;
> +char *tmp = av_malloc(len);
> +av_strlcpy(tmp, fmt, len);

Firstly, mixed variable declaration and statements.

Secondly, I think you don’t need ’tmp’, something like

av_asprintf(“%.*s.%03d%s", len, fmt, (int)(unow % 100) / 1000, seconds);

> +
> +char *fmt_new = av_asprintf("%s.%03d%s", tmp, (int)(unow % 
> 100) / 1000, seconds);
> +av_bprint_strftime(bp, fmt_new, );
> +
> +av_freep();
> +av_freep(_new);
> +
> +return 0;
> +}
> +}


> 
> Ping ^
> 
> -Thilo
> ___
> 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 v2] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread James Almer



On 1/6/2022 8:27 AM, Thilo Borgmann wrote:

Am 03.01.22 um 16:22 schrieb Thilo Borgmann:

Am 29.12.21 um 12:46 schrieb Nicolas George:

"zhilizhao(赵志立)" (12021-12-29):

How about add a restriction like this:

if (format.endsWith(“%S"))
 enable the feature
else
 warning message

It’s a useful feature, it shouldn't create unexpected results, but
doesn’t need to support every use case.


I would not oppose it, but I find it inelegant, especially because it
requires a different expansion function, localtime_ms instead of
localtime.

What about this: with the original function "localtime", if the format
ends in "%3N", then append the millisecond. It can later be expanded to
support %xN at any place in the format for any value of x.


I think best will be to scan the format string for %S and extend it there with 
.ms part before expanding the rest of it, not? Shouldn't be too expensive for 
the filter.

Just need to find time to actually implement it.


Like v5 as attached.

Thanks,
Thilo




From c7f7c7a1cedc4ccc51977fc92645e1131608ac95 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Thu, 6 Jan 2022 12:24:46 +0100
Subject: [PATCH v5] lavfi/drawtext: Add localtime_ms for millisecond precision

Suggested-By: ffm...@fb.com
---
 doc/filters.texi  |  8 
 libavfilter/vf_drawtext.c | 28 ++--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 05d4b1a56e..967021e48b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11379,10 +11379,18 @@ It can be used to add padding with zeros from the 
left.
 The time at which the filter is running, expressed in UTC.
 It can accept an argument: a strftime() format string.
 
+@item gmtime_ms

+Same as @code{gmtime} but with millisecond precision.
+It can accept an argument: a strftime() format string.
+
 @item localtime
 The time at which the filter is running, expressed in the local time zone.
 It can accept an argument: a strftime() format string.
 
+@item localtime_ms

+Same as @code{localtime} but with millisecond precision.
+It can accept an argument: a strftime() format string.
+
 @item metadata
 Frame metadata. Takes one or two arguments.
 
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c

index 2a88692cbd..723473f299 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -51,6 +51,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/random_seed.h"
 #include "libavutil/parseutils.h"
+#include "libavutil/time.h"
 #include "libavutil/timecode.h"
 #include "libavutil/time_internal.h"
 #include "libavutil/tree.h"
@@ -1045,14 +1046,35 @@ static int func_strftime(AVFilterContext *ctx, AVBPrint 
*bp,
  char *fct, unsigned argc, char **argv, int tag)
 {
 const char *fmt = argc ? argv[0] : "%Y-%m-%d %H:%M:%S";
+int64_t unow;
 time_t now;
 struct tm tm;
 
-time();

-if (tag == 'L')
+unow = av_gettime();
+now  = unow / 100;
+if (tag == 'L' || tag == 'm')
 localtime_r(, );
 else
 tm = *gmtime_r(, );
+
+if (tag == 'M' || tag == 'm') {
+char *seconds = av_stristr(fmt, "%S");
+if (seconds) {
+seconds += 2;
+int len = seconds - fmt + 1;


Should be size_t. Also, mixed declarations and code.


+char *tmp = av_malloc(len);
+av_strlcpy(tmp, fmt, len);
+
+char *fmt_new = av_asprintf("%s.%03d%s", tmp, (int)(unow % 
100) / 1000, seconds);


Same.


+av_bprint_strftime(bp, fmt_new, );
+
+av_freep();
+av_freep(_new);
+
+return 0;
+}
+}
+
 av_bprint_strftime(bp, fmt, );
 return 0;
 }
@@ -1152,7 +1174,9 @@ static const struct drawtext_function {
 { "pict_type", 0, 0, 0,   func_pict_type },
 { "pts",   0, 3, 0,   func_pts  },
 { "gmtime",0, 1, 'G', func_strftime },
+{ "gmtime_ms", 0, 1, 'M', func_strftime },
 { "localtime", 0, 1, 'L', func_strftime },
+{ "localtime_ms", 0, 1, 'm', func_strftime },
 { "frame_num", 0, 0, 0,   func_frame_num },
 { "n", 0, 0, 0,   func_frame_num },
 { "metadata",  1, 2, 0,   func_metadata },
--
2.20.1 (Apple Git-117)


___
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 v9 1/3] libavdevice/avfoundation.m: use AudioConvert, extend supported formats

2022-01-14 Thread Marvin Scholz



On 6 Jan 2022, at 15:24, Romain Beauxis wrote:


* Implement support for AudioConverter
* Switch to AudioConverter's API to convert unsupported PCM
  formats (non-interleaved, non-packed) to supported formats
* Minimize data copy.

This fixes: https://trac.ffmpeg.org/ticket/9502

API ref:
https://developer.apple.com/documentation/audiotoolbox/audio_converter_services

Signed-off-by: Romain Beauxis 
---
This is the first patch of a series of 3 that fix, cleanup and enhance 
the

avfoundation implementation for libavdevice.

These patches come from an actual user-facing application relying on
libavdevice’s implementation of avfoundation audio input. Without 
them,

Avfoundation is practically unusable as it will:
* Refuse to process certain specific audio input format that are 
actually

returned by the OS for some users (packed PCM audio)
* Drop audio frames, resulting in corrupted audio input. This might 
have been
unnoticed with video frames but this makes avfoundation essentially 
unusable

for audio.

The patches are now being included in our production build so they are 
tested

and usable in production.



Hi,

the patches are still corrupt and do not apply.
As stated earlier, please either use git send-email or attach the patch
to the mail instead of putting its contents in it, as apparently 
Mail.app

messes them up.


Changelog for this patch:
* v2: None
* v3: None
* v4: None
* v5: Fix indentation/wrapping
* v6: None
* v7: Removed use of kAudioConverterPropertyCalculateOutputBufferSize
to calculate output buffer size. The calculation is trivial and this 
call was

randomly failing for no reason
* v8: None
* v9: None

libavdevice/avfoundation.m | 255 +
1 file changed, 145 insertions(+), 110 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 0cd6e646d5..738cd93375 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -111,16 +111,11 @@

int num_video_devices;

-int audio_channels;
-int audio_bits_per_sample;
-int audio_float;
-int audio_be;
-int audio_signed_integer;
-int audio_packed;
-int audio_non_interleaved;
-
-int32_t *audio_buffer;
-int audio_buffer_size;
+UInt32audio_buffers;
+UInt32audio_channels;
+UInt32input_bytes_per_sample;
+UInt32output_bytes_per_sample;
+AudioConverterRef audio_converter;

enum AVPixelFormat pixel_format;

@@ -299,7 +294,10 @@ static void destroy_context(AVFContext* ctx)
ctx->avf_delegate= NULL;
ctx->avf_audio_delegate = NULL;

-av_freep(>audio_buffer);
+if (ctx->audio_converter) {
+  AudioConverterDispose(ctx->audio_converter);
+  ctx->audio_converter = NULL;
+}

pthread_mutex_destroy(>frame_lock);

@@ -673,6 +671,10 @@ static int get_audio_config(AVFormatContext *s)
AVFContext *ctx = (AVFContext*)s->priv_data;
CMFormatDescriptionRef format_desc;
AVStream* stream = avformat_new_stream(s, NULL);
+AudioStreamBasicDescription output_format = {0};
+int audio_bits_per_sample, audio_float, audio_be;
+int audio_signed_integer, audio_packed, audio_non_interleaved;
+int must_convert = 0;

if (!stream) {
return 1;
@@ -690,60 +692,97 @@ static int get_audio_config(AVFormatContext *s)
avpriv_set_pts_info(stream, 64, 1, avf_time_base);

format_desc = 
CMSampleBufferGetFormatDescription(ctx->current_audio_frame);
-const AudioStreamBasicDescription *basic_desc = 
CMAudioFormatDescriptionGetStreamBasicDescription(format_desc);
+const AudioStreamBasicDescription *input_format = 
CMAudioFormatDescriptionGetStreamBasicDescription(format_desc);


-if (!basic_desc) {
+if (!input_format) {
unlock_frames(ctx);
av_log(s, AV_LOG_ERROR, "audio format not available\n");
return 1;
}

+if (input_format->mFormatID != kAudioFormatLinearPCM) {
+unlock_frames(ctx);
+av_log(s, AV_LOG_ERROR, "only PCM audio format are supported 
at the moment\n");

+return 1;
+}
+
stream->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
-stream->codecpar->sample_rate= basic_desc->mSampleRate;
-stream->codecpar->channels   = basic_desc->mChannelsPerFrame;
+stream->codecpar->sample_rate= input_format->mSampleRate;
+stream->codecpar->channels   = 
input_format->mChannelsPerFrame;
stream->codecpar->channel_layout = 
av_get_default_channel_layout(stream->codecpar->channels);


-ctx->audio_channels= basic_desc->mChannelsPerFrame;
-ctx->audio_bits_per_sample = basic_desc->mBitsPerChannel;
-ctx->audio_float   = basic_desc->mFormatFlags & 
kAudioFormatFlagIsFloat;
-ctx->audio_be  = basic_desc->mFormatFlags & 
kAudioFormatFlagIsBigEndian;
-ctx->audio_signed_integer  

Re: [FFmpeg-devel] [PATCH v2] lavfi/drawtext: Add localtime_ms for millisecond precision

2022-01-14 Thread Thilo Borgmann
Am 06.01.22 um 12:27 schrieb Thilo Borgmann:
> Am 03.01.22 um 16:22 schrieb Thilo Borgmann:
>> Am 29.12.21 um 12:46 schrieb Nicolas George:
>>> "zhilizhao(赵志立)" (12021-12-29):
 How about add a restriction like this:

 if (format.endsWith(“%S"))
 enable the feature
 else
 warning message

 It’s a useful feature, it shouldn't create unexpected results, but
 doesn’t need to support every use case.
>>>
>>> I would not oppose it, but I find it inelegant, especially because it
>>> requires a different expansion function, localtime_ms instead of
>>> localtime.
>>>
>>> What about this: with the original function "localtime", if the format
>>> ends in "%3N", then append the millisecond. It can later be expanded to
>>> support %xN at any place in the format for any value of x.
>>
>> I think best will be to scan the format string for %S and extend it there 
>> with .ms part before expanding the rest of it, not? Shouldn't be too 
>> expensive for the filter.
>>
>> Just need to find time to actually implement it. 
> 
> Like v5 as attached.

Ping ^

-Thilo
___
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 v3 2/3] avcodec/libopenh264enc: make the profile configuablable correctly

2022-01-14 Thread Martin Storsjö

On Fri, 14 Jan 2022, lance.lmw...@gmail.com wrote:


From: Limin Wang 

due to the limitations set in d3a7bdd4ac54349aea9150a234478635d50ebd87,
you weren't able to use main profile with OpenH264 1.8, or high profile
with older versions

Reviewed-by: Martin Storsjö 
Signed-off-by: Limin Wang 
---
libavcodec/libopenh264enc.c | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 5b5914c..1bad233 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -220,26 +220,25 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
#endif

switch (s->profile) {
-#if OPENH264_VER_AT_LEAST(1, 8)
case FF_PROFILE_H264_HIGH:
param.iEntropyCodingModeFlag = 1;
av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
"select EProfileIdc PRO_HIGH in libopenh264.\n");
break;
-#else
case FF_PROFILE_H264_MAIN:
param.iEntropyCodingModeFlag = 1;
av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
"select EProfileIdc PRO_MAIN in libopenh264.\n");
break;
-#endif
-case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_UNKNOWN:
+s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
+case FF_PROFILE_H264_CONSTRAINED_BASELINE:


I don't think it's specifically necessary to move the case labels around 
like this; you could just leave both case labels above it, and the 
assignment would be a no-op for one case. (No need to resend the patch for 
that, do whichever form you prefer.)



param.iEntropyCodingModeFlag = 0;
av_log(avctx, AV_LOG_VERBOSE, "Using CAVLC, "
   "select EProfileIdc PRO_BASELINE in libopenh264.\n");
break;
default:
+s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
param.iEntropyCodingModeFlag = 0;
av_log(avctx, AV_LOG_WARNING, "Unsupported profile, "
   "select EProfileIdc PRO_BASELINE in libopenh264.\n");
@@ -251,6 +250,7 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
param.sSpatialLayers[0].fFrameRate  = param.fMaxFrameRate;
param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
+param.sSpatialLayers[0].uiProfileIdc= s->profile;


Thanks, this seems sensible to me. This is ok if you've tested that 
setting profile to FF_PROFILE_H264_CONSTRAINED_BASELINE (as opposed to 
PRO_BASELINE) does work with both some old and some recent version of 
OpenH264.


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


[FFmpeg-devel] [PATCH v3 3/3] avcodec/libopenh264enc: set iEntropyCodingModeFlag by coder option

2022-01-14 Thread lance . lmwang
From: Limin Wang 

For high/main profile, user can choose to use cavlc by specify "-coder cavlc",
for default, it'll will use cabac, if it's baseline, we'll use cavlc by specs 
anyway.

ffmpeg -y -f lavfi -i testsrc -c:v libopenh264 -profile:v main -coder cavlc 
-frames:v 1 -bsf trace_headers -f null -
before the patch:
entropy_coding_mode_flag0 = 1

after the patch:
entropy_coding_mode_flag0 = 0

Reviewed-by: Martin Storsjö 
Signed-off-by: Limin Wang 
---
 libavcodec/libopenh264enc.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 1bad233..a1e78c9 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -193,7 +193,7 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 #endif
 param.bPrefixNalAddingCtrl   = 0;
 param.iLoopFilterDisableIdc  = !s->loopfilter;
-param.iEntropyCodingModeFlag = 0;
+param.iEntropyCodingModeFlag = s->coder >= 0 ? s->coder : 1;
 param.iMultipleThreadIdc = avctx->thread_count;
 
 /* Allow specifying the libopenh264 profile through AVCodecContext. */
@@ -221,14 +221,14 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 
 switch (s->profile) {
 case FF_PROFILE_H264_HIGH:
-param.iEntropyCodingModeFlag = 1;
-av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
-"select EProfileIdc PRO_HIGH in libopenh264.\n");
+av_log(avctx, AV_LOG_VERBOSE, "Using %s, "
+"select EProfileIdc PRO_HIGH in libopenh264.\n",
+param.iEntropyCodingModeFlag ? "CABAC" : "CAVLC");
 break;
 case FF_PROFILE_H264_MAIN:
-param.iEntropyCodingModeFlag = 1;
-av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
-"select EProfileIdc PRO_MAIN in libopenh264.\n");
+av_log(avctx, AV_LOG_VERBOSE, "Using %s, "
+"select EProfileIdc PRO_MAIN in libopenh264.\n",
+param.iEntropyCodingModeFlag ? "CABAC" : "CAVLC");
 break;
 case FF_PROFILE_UNKNOWN:
 s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
-- 
1.8.3.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 v3 2/3] avcodec/libopenh264enc: make the profile configuablable correctly

2022-01-14 Thread lance . lmwang
From: Limin Wang 

due to the limitations set in d3a7bdd4ac54349aea9150a234478635d50ebd87,
you weren't able to use main profile with OpenH264 1.8, or high profile
with older versions

Reviewed-by: Martin Storsjö 
Signed-off-by: Limin Wang 
---
 libavcodec/libopenh264enc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 5b5914c..1bad233 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -220,26 +220,25 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 #endif
 
 switch (s->profile) {
-#if OPENH264_VER_AT_LEAST(1, 8)
 case FF_PROFILE_H264_HIGH:
 param.iEntropyCodingModeFlag = 1;
 av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
 "select EProfileIdc PRO_HIGH in libopenh264.\n");
 break;
-#else
 case FF_PROFILE_H264_MAIN:
 param.iEntropyCodingModeFlag = 1;
 av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
 "select EProfileIdc PRO_MAIN in libopenh264.\n");
 break;
-#endif
-case FF_PROFILE_H264_CONSTRAINED_BASELINE:
 case FF_PROFILE_UNKNOWN:
+s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
+case FF_PROFILE_H264_CONSTRAINED_BASELINE:
 param.iEntropyCodingModeFlag = 0;
 av_log(avctx, AV_LOG_VERBOSE, "Using CAVLC, "
"select EProfileIdc PRO_BASELINE in libopenh264.\n");
 break;
 default:
+s->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
 param.iEntropyCodingModeFlag = 0;
 av_log(avctx, AV_LOG_WARNING, "Unsupported profile, "
"select EProfileIdc PRO_BASELINE in libopenh264.\n");
@@ -251,6 +250,7 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 param.sSpatialLayers[0].fFrameRate  = param.fMaxFrameRate;
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
+param.sSpatialLayers[0].uiProfileIdc= s->profile;
 
 #if OPENH264_VER_AT_LEAST(1, 7)
 if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den) {
-- 
1.8.3.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 v3 1/3] avcodec/libopenh264enc: support for colorspace and range information

2022-01-14 Thread lance . lmwang
From: Limin Wang 

Reviewed-by: Martin Storsjö 
Signed-off-by: Limin Wang 
---
 libavcodec/libopenh264enc.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index de4b85c..5b5914c 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -330,6 +330,28 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 }
 }
 
+#if OPENH264_VER_AT_LEAST(1, 6)
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;
+if (avctx->color_range != AVCOL_RANGE_UNSPECIFIED) {
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].bFullRange = (avctx->color_range == 
AVCOL_RANGE_JPEG);
+}
+
+if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED  ||
+avctx->color_primaries != AVCOL_PRI_UNSPECIFIED ||
+avctx->color_trc != AVCOL_TRC_UNSPECIFIED) {
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+}
+
+if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED)
+param.sSpatialLayers[0].uiColorMatrix = avctx->colorspace;
+if (avctx->color_primaries != AVCOL_PRI_UNSPECIFIED)
+param.sSpatialLayers[0].uiColorPrimaries = avctx->color_primaries;
+if (avctx->color_trc != AVCOL_TRC_UNSPECIFIED)
+param.sSpatialLayers[0].uiTransferCharacteristics = avctx->color_trc;
+#endif
+
 if ((*s->encoder)->InitializeExt(s->encoder, ) != cmResultSuccess) {
 av_log(avctx, AV_LOG_ERROR, "Initialize failed\n");
 return AVERROR_UNKNOWN;
-- 
1.8.3.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 v2 2/3] avcodec/libopenh264enc: make the profile configuablable correctly

2022-01-14 Thread lance . lmwang
On Fri, Jan 14, 2022 at 11:28:14AM +0200, Martin Storsjö wrote:
> On Fri, 14 Jan 2022, lance.lmw...@gmail.com wrote:
> 
> > From: Limin Wang 
> > 
> > d3a7bdd4ac54349aea9150a234478635d50ebd87 was based on incorrect conclusions
> > because we had missed to set uiProfileIdc.
> > 
> > If the version of libopenh264 >= 1.8, we can't configured main profile as
> > expected, below is the testing cli:
> > 
> > ffmpeg -y -f lavfi -i testsrc -c:v libopenh264 -profile:v main -frames:v 1 
> > test.ts
> > It'll report:
> > [libopenh264 @ 0x5638300] Unsupported profile, select EProfileIdc 
> > PRO_BASELINE in libopenh264.
> 
> Given the referenced commit, the fact that you can't use main profile with
> 1.8 (or high profile with older) isn't a surprise as that was part of the
> deliberate design in that commit, so I'm not sure if this is a good example
> to include. Or reword it to say that "due to the limitations set in
> , you weren't able to use main profile with OpenH264 1.8, or high
> profile with older versions".

Sure, will reword the message as suggestion.

> 
> > Signed-off-by: Limin Wang 
> > ---
> > libavcodec/libopenh264enc.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> > index 5b5914c..8e27edb 100644
> > --- a/libavcodec/libopenh264enc.c
> > +++ b/libavcodec/libopenh264enc.c
> > @@ -220,19 +220,16 @@ static av_cold int svc_encode_init(AVCodecContext 
> > *avctx)
> > #endif
> > 
> > switch (s->profile) {
> > -#if OPENH264_VER_AT_LEAST(1, 8)
> > case FF_PROFILE_H264_HIGH:
> > param.iEntropyCodingModeFlag = 1;
> > av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
> > "select EProfileIdc PRO_HIGH in libopenh264.\n");
> > break;
> > -#else
> > case FF_PROFILE_H264_MAIN:
> > param.iEntropyCodingModeFlag = 1;
> > av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
> > "select EProfileIdc PRO_MAIN in libopenh264.\n");
> > break;
> > -#endif
> > case FF_PROFILE_H264_CONSTRAINED_BASELINE:
> > case FF_PROFILE_UNKNOWN:
> > param.iEntropyCodingModeFlag = 0;
> 
> For this fallback case, I think we should set s->profile to
> FF_PROFILE_H264_CONSTRAINED_BASELINE or something similar (does OpenH264
> work correctly with FF_PROFILE_H264_CONSTRAINED_BASELINE too, or only with
> FF_PROFILE_H264_BASELINE which is equal to PRO_BASELINE), as we otherwise
> would be setting unknown values into uiProfileIdc.

Sure, will update to set profile to FF_PROFILE_H264_CONSTRAINED_BASELINE for 
unknown case.

> 
> // Martin
> 

-- 
Thanks,
Limin Wang
___
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 3/3] avcodec/libopenh264enc: set iEntropyCodingModeFlag by coder option

2022-01-14 Thread Martin Storsjö

On Fri, 14 Jan 2022, lance.lmw...@gmail.com wrote:


From: Limin Wang 

For high/main profile, user can choose to use cavlc by specify "-coder cavlc",
for default, it'll will use cabac, if it's baseline, we'll use cavlc by specs 
anyway.

ffmpeg -y -f lavfi -i testsrc -c:v libopenh264 -profile:v main -coder cavlc 
-frames:v 1 -bsf trace_headers -f null -
before the patch:
entropy_coding_mode_flag0 = 1

after the patch:
entropy_coding_mode_flag0 = 0

Signed-off-by: Limin Wang 
---
libavcodec/libopenh264enc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 8e27edb..4c0997b 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -193,7 +193,7 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
#endif
param.bPrefixNalAddingCtrl   = 0;
param.iLoopFilterDisableIdc  = !s->loopfilter;
-param.iEntropyCodingModeFlag = 0;
+param.iEntropyCodingModeFlag = s->coder >= 0 ? s->coder : 1;
param.iMultipleThreadIdc = avctx->thread_count;

/* Allow specifying the libopenh264 profile through AVCodecContext. */
@@ -221,14 +221,14 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)

switch (s->profile) {
case FF_PROFILE_H264_HIGH:
-param.iEntropyCodingModeFlag = 1;
-av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
-"select EProfileIdc PRO_HIGH in libopenh264.\n");
+av_log(avctx, AV_LOG_VERBOSE, "Using %s, "
+"select EProfileIdc PRO_HIGH in libopenh264.\n",
+param.iEntropyCodingModeFlag ? "CABAC" : "CAVLC");
break;
case FF_PROFILE_H264_MAIN:
-param.iEntropyCodingModeFlag = 1;
-av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
-"select EProfileIdc PRO_MAIN in libopenh264.\n");
+av_log(avctx, AV_LOG_VERBOSE, "Using %s, "
+"select EProfileIdc PRO_MAIN in libopenh264.\n",
+param.iEntropyCodingModeFlag ? "CABAC" : "CAVLC");
break;
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_UNKNOWN:
--
1.8.3.1


This looks good to me now I think, 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 v2 2/3] avcodec/libopenh264enc: make the profile configuablable correctly

2022-01-14 Thread Martin Storsjö

On Fri, 14 Jan 2022, lance.lmw...@gmail.com wrote:


From: Limin Wang 

d3a7bdd4ac54349aea9150a234478635d50ebd87 was based on incorrect conclusions
because we had missed to set uiProfileIdc.

If the version of libopenh264 >= 1.8, we can't configured main profile as
expected, below is the testing cli:

ffmpeg -y -f lavfi -i testsrc -c:v libopenh264 -profile:v main -frames:v 1 
test.ts
It'll report:
[libopenh264 @ 0x5638300] Unsupported profile, select EProfileIdc PRO_BASELINE 
in libopenh264.


Given the referenced commit, the fact that you can't use main profile with 
1.8 (or high profile with older) isn't a surprise as that was part of the 
deliberate design in that commit, so I'm not sure if this 
is a good example to include. Or reword it to say that "due to the 
limitations set in , you weren't able to use main profile with 
OpenH264 1.8, or high profile with older versions".



Signed-off-by: Limin Wang 
---
libavcodec/libopenh264enc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 5b5914c..8e27edb 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -220,19 +220,16 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
#endif

switch (s->profile) {
-#if OPENH264_VER_AT_LEAST(1, 8)
case FF_PROFILE_H264_HIGH:
param.iEntropyCodingModeFlag = 1;
av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
"select EProfileIdc PRO_HIGH in libopenh264.\n");
break;
-#else
case FF_PROFILE_H264_MAIN:
param.iEntropyCodingModeFlag = 1;
av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
"select EProfileIdc PRO_MAIN in libopenh264.\n");
break;
-#endif
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_UNKNOWN:
param.iEntropyCodingModeFlag = 0;


For this fallback case, I think we should set s->profile to 
FF_PROFILE_H264_CONSTRAINED_BASELINE or something similar (does OpenH264 
work correctly with FF_PROFILE_H264_CONSTRAINED_BASELINE too, or only with 
FF_PROFILE_H264_BASELINE which is equal to PRO_BASELINE), as we otherwise 
would be setting unknown values into uiProfileIdc.


// 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 v2 1/3] avcodec/libopenh264enc: support for colorspace and range information

2022-01-14 Thread Martin Storsjö

On Fri, 14 Jan 2022, lance.lmw...@gmail.com wrote:


From: Limin Wang 

Signed-off-by: Limin Wang 
---
libavcodec/libopenh264enc.c | 22 ++
1 file changed, 22 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index de4b85c..5b5914c 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -330,6 +330,28 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
}
}

+#if OPENH264_VER_AT_LEAST(1, 6)
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;
+if (avctx->color_range != AVCOL_RANGE_UNSPECIFIED) {
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].bFullRange = (avctx->color_range == 
AVCOL_RANGE_JPEG);
+}
+
+if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED  ||
+avctx->color_primaries != AVCOL_PRI_UNSPECIFIED ||
+avctx->color_trc != AVCOL_TRC_UNSPECIFIED) {
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+}
+
+if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED)
+param.sSpatialLayers[0].uiColorMatrix = avctx->colorspace;
+if (avctx->color_primaries != AVCOL_PRI_UNSPECIFIED)
+param.sSpatialLayers[0].uiColorPrimaries = avctx->color_primaries;
+if (avctx->color_trc != AVCOL_TRC_UNSPECIFIED)
+param.sSpatialLayers[0].uiTransferCharacteristics = avctx->color_trc;
+#endif


Thanks, this looks correct to me.

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


[FFmpeg-devel] [PATCH v2 3/3] avcodec/libopenh264enc: set iEntropyCodingModeFlag by coder option

2022-01-14 Thread lance . lmwang
From: Limin Wang 

For high/main profile, user can choose to use cavlc by specify "-coder cavlc",
for default, it'll will use cabac, if it's baseline, we'll use cavlc by specs 
anyway.

ffmpeg -y -f lavfi -i testsrc -c:v libopenh264 -profile:v main -coder cavlc 
-frames:v 1 -bsf trace_headers -f null -
before the patch:
entropy_coding_mode_flag0 = 1

after the patch:
entropy_coding_mode_flag0 = 0

Signed-off-by: Limin Wang 
---
 libavcodec/libopenh264enc.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 8e27edb..4c0997b 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -193,7 +193,7 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 #endif
 param.bPrefixNalAddingCtrl   = 0;
 param.iLoopFilterDisableIdc  = !s->loopfilter;
-param.iEntropyCodingModeFlag = 0;
+param.iEntropyCodingModeFlag = s->coder >= 0 ? s->coder : 1;
 param.iMultipleThreadIdc = avctx->thread_count;
 
 /* Allow specifying the libopenh264 profile through AVCodecContext. */
@@ -221,14 +221,14 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 
 switch (s->profile) {
 case FF_PROFILE_H264_HIGH:
-param.iEntropyCodingModeFlag = 1;
-av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
-"select EProfileIdc PRO_HIGH in libopenh264.\n");
+av_log(avctx, AV_LOG_VERBOSE, "Using %s, "
+"select EProfileIdc PRO_HIGH in libopenh264.\n",
+param.iEntropyCodingModeFlag ? "CABAC" : "CAVLC");
 break;
 case FF_PROFILE_H264_MAIN:
-param.iEntropyCodingModeFlag = 1;
-av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
-"select EProfileIdc PRO_MAIN in libopenh264.\n");
+av_log(avctx, AV_LOG_VERBOSE, "Using %s, "
+"select EProfileIdc PRO_MAIN in libopenh264.\n",
+param.iEntropyCodingModeFlag ? "CABAC" : "CAVLC");
 break;
 case FF_PROFILE_H264_CONSTRAINED_BASELINE:
 case FF_PROFILE_UNKNOWN:
-- 
1.8.3.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 v2 2/3] avcodec/libopenh264enc: make the profile configuablable correctly

2022-01-14 Thread lance . lmwang
From: Limin Wang 

d3a7bdd4ac54349aea9150a234478635d50ebd87 was based on incorrect conclusions
because we had missed to set uiProfileIdc.

If the version of libopenh264 >= 1.8, we can't configured main profile as
expected, below is the testing cli:

ffmpeg -y -f lavfi -i testsrc -c:v libopenh264 -profile:v main -frames:v 1 
test.ts
It'll report:
[libopenh264 @ 0x5638300] Unsupported profile, select EProfileIdc PRO_BASELINE 
in libopenh264.

Signed-off-by: Limin Wang 
---
 libavcodec/libopenh264enc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 5b5914c..8e27edb 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -220,19 +220,16 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 #endif
 
 switch (s->profile) {
-#if OPENH264_VER_AT_LEAST(1, 8)
 case FF_PROFILE_H264_HIGH:
 param.iEntropyCodingModeFlag = 1;
 av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
 "select EProfileIdc PRO_HIGH in libopenh264.\n");
 break;
-#else
 case FF_PROFILE_H264_MAIN:
 param.iEntropyCodingModeFlag = 1;
 av_log(avctx, AV_LOG_VERBOSE, "Using CABAC, "
 "select EProfileIdc PRO_MAIN in libopenh264.\n");
 break;
-#endif
 case FF_PROFILE_H264_CONSTRAINED_BASELINE:
 case FF_PROFILE_UNKNOWN:
 param.iEntropyCodingModeFlag = 0;
@@ -251,6 +248,7 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 param.sSpatialLayers[0].fFrameRate  = param.fMaxFrameRate;
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
+param.sSpatialLayers[0].uiProfileIdc= s->profile;
 
 #if OPENH264_VER_AT_LEAST(1, 7)
 if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den) {
-- 
1.8.3.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 v2 1/3] avcodec/libopenh264enc: support for colorspace and range information

2022-01-14 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/libopenh264enc.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index de4b85c..5b5914c 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -330,6 +330,28 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
 }
 }
 
+#if OPENH264_VER_AT_LEAST(1, 6)
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;
+if (avctx->color_range != AVCOL_RANGE_UNSPECIFIED) {
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].bFullRange = (avctx->color_range == 
AVCOL_RANGE_JPEG);
+}
+
+if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED  ||
+avctx->color_primaries != AVCOL_PRI_UNSPECIFIED ||
+avctx->color_trc != AVCOL_TRC_UNSPECIFIED) {
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+}
+
+if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED)
+param.sSpatialLayers[0].uiColorMatrix = avctx->colorspace;
+if (avctx->color_primaries != AVCOL_PRI_UNSPECIFIED)
+param.sSpatialLayers[0].uiColorPrimaries = avctx->color_primaries;
+if (avctx->color_trc != AVCOL_TRC_UNSPECIFIED)
+param.sSpatialLayers[0].uiTransferCharacteristics = avctx->color_trc;
+#endif
+
 if ((*s->encoder)->InitializeExt(s->encoder, ) != cmResultSuccess) {
 av_log(avctx, AV_LOG_ERROR, "Initialize failed\n");
 return AVERROR_UNKNOWN;
-- 
1.8.3.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".