Re: [FFmpeg-devel] [PATCH v2] fate/hevc-conformance: add clip for persistent_rice_adaptation_enabled_flag

2020-11-21 Thread Guangxin Xu
ping.

On Thu, Nov 19, 2020 at 11:01 PM Guangxin Xu  wrote:

> Hi folks,
> Could you help upload the bits file in
> https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/WPP_HIGH_TP_444_8BIT_RExt_Apple_2.zip
> ?
> it's required by
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201115023622.17605-1-oddst...@gmail.com
> and
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201115023653.17657-1-oddst...@gmail.com/
>
> thanks
>
> On Sun, Nov 15, 2020 at 10:46 AM Xu Guangxin  wrote:
>
>> you can download it from:
>>
>> https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/WPP_HIGH_TP_444_8BIT_RExt_Apple_2.zip
>>
>> Signed-off-by: Xu Guangxin 
>> ---
>>  tests/fate/hevc.mak   | 1 +
>>  .../hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2| 8 
>>  2 files changed, 9 insertions(+)
>>  create mode 100644
>> tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2
>>
>> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
>> index 9a32a7d74c..97edb49781 100644
>> --- a/tests/fate/hevc.mak
>> +++ b/tests/fate/hevc.mak
>> @@ -141,6 +141,7 @@ HEVC_SAMPLES =  \
>>  WPP_D_ericsson_MAIN_2   \
>>  WPP_E_ericsson_MAIN_2   \
>>  WPP_F_ericsson_MAIN_2   \
>> +WPP_HIGH_TP_444_8BIT_RExt_Apple_2 \
>>
>>  HEVC_SAMPLES_10BIT =\
>>  DBLK_A_MAIN10_VIXS_3\
>> diff --git
>> a/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2
>> b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2
>> new file mode 100644
>> index 00..fcb1d2894a
>> --- /dev/null
>> +++ b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2
>> @@ -0,0 +1,8 @@
>> +#tb 0: 1/25
>> +#media_type 0: video
>> +#codec_id 0: rawvideo
>> +#dimensions 0: 1024x768
>> +#sar 0: 0/1
>> +0,  0,  0,1,  1179648, 0x78e55a69
>> +0,  1,  1,1,  1179648, 0x5babb3cb
>> +0,  2,  2,1,  1179648, 0x65935648
>> --
>> 2.17.1
>>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 0/3] add vvc raw demuxer

2020-11-21 Thread Nuo Mi
Thanks for the replies.

On Sun, Nov 22, 2020 at 5:53 AM James Almer  wrote:

> On 11/21/2020 2:18 PM, Mark Thompson wrote:
> > On 21/11/2020 02:19, James Almer wrote:
> >> On 11/20/2020 10:55 PM, Nuo Mi wrote:
> >>> Hi Mark, James and all,
> >>> There are two ways to implement the parser.
> >>> 1. use cbs like av1 parser.
> >>> 2. follow h264/h265 parser method.
> >>> Which is your preferred?
> >>>
> >>> thanks
> >>
> >> A CBS module for VVC is needed regardless of how the parser is
> >> ultimately implemented (There will be other uses, like bitstream
> >> filters), so might as well use it for it, like with AV1.
> >
> > +1.
> >
> > Attached is some initial investigation I did recently into CBS
> > implementation.  The non-CBS parts are all hacks to get a raw stream fed
> > into trace_headers, and can be ignored for non-test purposes.
> >
> > My thoughts emerging from that:
> >
> > * The commonality with H.26[45] is sufficient that it's probably best to
> > extend that into CBS H.26[456].
> >* All of the styling is the same, so doing that avoids duplicating a
> > lot of templating code.
> >* I haven't done that here because it was easier to hack in by
> > starting with a new file.
> >* Separately I've been looking at merging the implementation of more
> > common elements of H.26[45], and that will apply here too (SEI in
> > particular, where H.274 matches in parts as well).

Fully agreed with this. I  did some homework after James replied to me. See
attachment.
The code is far behind complete, it's similar to your code and aligned with
James's suggestion.
Seems we need pretty large work to enable the h266 cbs. Is it possible to
open some branch on GitHub, so I can offload your work?



>
> > * There is /a lot/ of boilerplate needed to get even a minimal version
> > working.
> >* The parameter sets are even bigger and more complex than they were
> > in H.265 (and the VUI that you want for metadata is still right at the
> > end of the SPS).
> >* The clean specification is very appreciated - I haven't found any
> > nasty interdependencies yet, though I haven't read all of it in detail.
> >* Given the huge surface area for errors here, it may not be a good
> > idea to include it until we have the full conformance test suite (like
> > H.265.1) to test it with.
>
 The vvc is finalized, it supposes will not have big syntax changes.
I download my conformance clips here
https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft5/

>
> > * It seemed like the right choice on naming was to use H.266 as the name
> > everywhere and always refer to that:
> >* It stays consistent with the most common name for H.264 (still the
> > most-used codec).
> >* It's a formal standard, unlike the JVET drafts.
> >* Anyone can download the full specification for free
> > (), unlike the ISO/IEC
> > 23090-3 version.
>

 thanks for the link, better than my JVET docuemnet, Let me use it.


> The CBS module i absolutely agree should be named h266. Same with
> h2645_parse, which should be renamed to h26x_parse once adapted to also
> split H266 NALUs.
> But for the decoder and parser, it will depend on how the codec turns
> out to be best known as. Take for example h265, which is called HEVC
> everywhere, and unlike h264 where AVC is seemingly not used as much.
> Right now, VVC seems to get more relevant hits on google than h266.
>
> And we can add two codec ids for it, like h265/HEVC (Or rather one, and
> a #define alias).
>
> >
> > I'm not working on this right now, but I'll probably come back to it in
> > the not-too-distant future.
> >
> > So, any thoughts welcome - given the scope of this we should probably
> > agree roughly what the intended structure will be before writing much
> more.
>
> My opinion, judging by current name usage in most news articles and
> announcements:
>
> h26x_parse
> cbs_h26x (using h26x_parse for NAL splitting)
> cbs_h266_syntax_template
> h266_metadata_bsf (Using CBS)
> vvc_parser (Using CBS for parameter set and frame header parsing. Raw
> bitstream merging is separate)
> vvc_decoder (Maybe using CBS?


Native vvc decoder is a huge task. Before this, maybe we can integrate the
vvdec(https://github.com/fraunhoferhhi/vvdec) to verify the parser and cbs.
vvdec optimized for x86. it's about 37 fps@1080P on my 4 years old i7.








AV_CODEC_ID_VVC
> #define AV_CODEC_ID_H266 AV_CODEC_ID_VVC
>
> >
> > Thanks,
> >
> > - Mark
> >
> > ___
> > 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

Re: [FFmpeg-devel] [PATCH] avformat/utils: Change compute_chapters_end() from O(n²) to O(n log n)

2020-11-21 Thread Lynne
Nov 21, 2020, 18:24 by mich...@niedermayer.cc:

> Fixes: Timeout (49sec -> 9sec)
> Fixes: 
> 27427/clusterfuzz-testcase-minimized-ffmpeg_dem_FFMETADATA_fuzzer-5140589838073856
>
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c | 43 +++
>  1 file changed, 43 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 503e583ad0..9fac3fc2aa 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3191,15 +3191,58 @@ enum AVCodecID av_codec_get_id(const AVCodecTag 
> *const *tags, unsigned int tag)
>  return AV_CODEC_ID_NONE;
>  }
>  
> +static int chapter_start_cmp(const void *p1, const void *p2)
> +{
> +AVChapter *ch1 = *(AVChapter**)p1;
> +AVChapter *ch2 = *(AVChapter**)p2;
> +int delta = av_compare_ts(ch1->start, ch1->time_base, ch2->start, 
> ch2->time_base);
> +if (delta)
> +return delta;
> +return (ch1 > ch2) - (ch1 < ch2);
> +}
> +
>  static void compute_chapters_end(AVFormatContext *s)
>  {
>  unsigned int i, j;
>  int64_t max_time = 0;
> +int computations = 0;
>  
>  if (s->duration > 0 && s->start_time < INT64_MAX - s->duration)
>  max_time = s->duration +
>  ((s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time);
>  
> +for (i = 0; i < s->nb_chapters; i++)
> +if (s->chapters[i]->end == AV_NOPTS_VALUE)
> +computations ++;
> +
> +if (computations > 5) {
> +AVChapter **timetable = av_malloc(s->nb_chapters * 
> sizeof(*timetable));
> +if (timetable) {
>

Its a void function, but shouldn't you change it to make it return
AVERROR(ENOMEM) and then handle that in the caller?
No memory is pretty catastrophic.
___
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 0/3] add vvc raw demuxer

2020-11-21 Thread James Almer

On 11/21/2020 2:18 PM, Mark Thompson wrote:

On 21/11/2020 02:19, James Almer wrote:

On 11/20/2020 10:55 PM, Nuo Mi wrote:

Hi Mark, James and all,
There are two ways to implement the parser.
1. use cbs like av1 parser.
2. follow h264/h265 parser method.
Which is your preferred?

thanks


A CBS module for VVC is needed regardless of how the parser is 
ultimately implemented (There will be other uses, like bitstream 
filters), so might as well use it for it, like with AV1.


+1.

Attached is some initial investigation I did recently into CBS 
implementation.  The non-CBS parts are all hacks to get a raw stream fed 
into trace_headers, and can be ignored for non-test purposes.


My thoughts emerging from that:

* The commonality with H.26[45] is sufficient that it's probably best to 
extend that into CBS H.26[456].
   * All of the styling is the same, so doing that avoids duplicating a 
lot of templating code.
   * I haven't done that here because it was easier to hack in by 
starting with a new file.
   * Separately I've been looking at merging the implementation of more 
common elements of H.26[45], and that will apply here too (SEI in 
particular, where H.274 matches in parts as well).


* There is /a lot/ of boilerplate needed to get even a minimal version 
working.
   * The parameter sets are even bigger and more complex than they were 
in H.265 (and the VUI that you want for metadata is still right at the 
end of the SPS).
   * The clean specification is very appreciated - I haven't found any 
nasty interdependencies yet, though I haven't read all of it in detail.
   * Given the huge surface area for errors here, it may not be a good 
idea to include it until we have the full conformance test suite (like 
H.265.1) to test it with.


* It seemed like the right choice on naming was to use H.266 as the name 
everywhere and always refer to that:
   * It stays consistent with the most common name for H.264 (still the 
most-used codec).

   * It's a formal standard, unlike the JVET drafts.
   * Anyone can download the full specification for free 
(), unlike the ISO/IEC 
23090-3 version.


The CBS module i absolutely agree should be named h266. Same with 
h2645_parse, which should be renamed to h26x_parse once adapted to also 
split H266 NALUs.
But for the decoder and parser, it will depend on how the codec turns 
out to be best known as. Take for example h265, which is called HEVC 
everywhere, and unlike h264 where AVC is seemingly not used as much.

Right now, VVC seems to get more relevant hits on google than h266.

And we can add two codec ids for it, like h265/HEVC (Or rather one, and 
a #define alias).




I'm not working on this right now, but I'll probably come back to it in 
the not-too-distant future.


So, any thoughts welcome - given the scope of this we should probably 
agree roughly what the intended structure will be before writing much more.


My opinion, judging by current name usage in most news articles and 
announcements:


h26x_parse
cbs_h26x (using h26x_parse for NAL splitting)
cbs_h266_syntax_template
h266_metadata_bsf (Using CBS)
vvc_parser (Using CBS for parameter set and frame header parsing. Raw 
bitstream merging is separate)

vvc_decoder (Maybe using CBS?)
AV_CODEC_ID_VVC
#define AV_CODEC_ID_H266 AV_CODEC_ID_VVC



Thanks,

- Mark

___
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] avcodec/cuviddec: fix CUDA_ERROR_INVALID_CONTEXT error found by cuda-memcheck tool

2020-11-21 Thread Timo Rothenpieler

applied
___
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/utils: Change compute_chapters_end() from O(n²) to O(n log n)

2020-11-21 Thread Michael Niedermayer
On Sat, Nov 21, 2020 at 07:32:31PM +0100, Lynne wrote:
> Nov 21, 2020, 18:24 by mich...@niedermayer.cc:
> 
> > Fixes: Timeout (49sec -> 9sec)
> > Fixes: 
> > 27427/clusterfuzz-testcase-minimized-ffmpeg_dem_FFMETADATA_fuzzer-5140589838073856
> >
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/utils.c | 43 +++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 503e583ad0..9fac3fc2aa 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -3191,15 +3191,58 @@ enum AVCodecID av_codec_get_id(const AVCodecTag 
> > *const *tags, unsigned int tag)
> >  return AV_CODEC_ID_NONE;
> >  }
> >  
> > +static int chapter_start_cmp(const void *p1, const void *p2)
> > +{
> > +AVChapter *ch1 = *(AVChapter**)p1;
> > +AVChapter *ch2 = *(AVChapter**)p2;
> > +int delta = av_compare_ts(ch1->start, ch1->time_base, ch2->start, 
> > ch2->time_base);
> > +if (delta)
> > +return delta;
> > +return (ch1 > ch2) - (ch1 < ch2);
> > +}
> > +
> >  static void compute_chapters_end(AVFormatContext *s)
> >  {
> >  unsigned int i, j;
> >  int64_t max_time = 0;
> > +int computations = 0;
> >  
> >  if (s->duration > 0 && s->start_time < INT64_MAX - s->duration)
> >  max_time = s->duration +
> >  ((s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time);
> >  
> > +for (i = 0; i < s->nb_chapters; i++)
> > +if (s->chapters[i]->end == AV_NOPTS_VALUE)
> > +computations ++;
> > +
> > +if (computations > 5) {
> > +AVChapter **timetable = av_malloc(s->nb_chapters * 
> > sizeof(*timetable));
> > +if (timetable) {
> >
> 
> Its a void function, but shouldn't you change it to make it return
> AVERROR(ENOMEM) and then handle that in the caller?
> No memory is pretty catastrophic.

you are probably correct, that fallback isnt worth it, ill drop it and
return failure

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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 1/4] avformat/iff: Check size before skip

2020-11-21 Thread Michael Niedermayer
On Sat, Nov 14, 2020 at 11:26:25PM +0100, Michael Niedermayer wrote:
> Fixes: Infinite loop
> Fixes: 
> 27292/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-5731168991051776
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/iff.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply patchset

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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 2/2] avformat/rmdec: Check for EOF in index packet reading

2020-11-21 Thread Michael Niedermayer
On Sat, Nov 14, 2020 at 11:18:15AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout(>10sec -> 1ms)
> Fixes: 
> 27284/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-630420985728
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/rmdec.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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] avformat/movenc: allow Apple Lossless inside mp4

2020-11-21 Thread Jan Ekström
On Fri, Nov 20, 2020 at 10:53 PM Jan Ekström  wrote:
>
> On Fri, Nov 20, 2020 at 7:02 PM Leo Izen  wrote:
> >
> > MP4 already supports Apple Lossless, and it can be put inside by using
> > muxer=ipod, but it's not tagged as supported in mp4. The mp4ra lists
> > alac as a valid fourcc inside mp4, so it should be supported by spec.
> >
> > See: https://mp4ra.org/#/codecs
>
> I would just note in the paragraph that the identifier has been
> registered to ISO and thus towards ISOBMFF (which we usually call
> "mp4") at the MP4 registration authority.
>
> This can be changed when applying the patch, so no second revision
> needed for this change.
>
> > ---
> >  libavformat/movenc.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index fea8a86192..18fa3f9b5e 100644
> > --- a/libavformat/movenc.c
> > +++ b/libavformat/movenc.c
> > @@ -7128,6 +7128,7 @@ static const AVCodecTag codec_mp4_tags[] = {
> >  { AV_CODEC_ID_VP9, MKTAG('v', 'p', '0', '9') },
> >  { AV_CODEC_ID_AV1, MKTAG('a', 'v', '0', '1') },
> >  { AV_CODEC_ID_AAC, MKTAG('m', 'p', '4', 'a') },
> > +{ AV_CODEC_ID_ALAC,MKTAG('a', 'l', 'a', 'c') },
> >  { AV_CODEC_ID_MP4ALS,  MKTAG('m', 'p', '4', 'a') },
> >  { AV_CODEC_ID_MP3, MKTAG('m', 'p', '4', 'a') },
> >  { AV_CODEC_ID_MP2, MKTAG('m', 'p', '4', 'a') },
> > --
> > 2.29.2
> >
>
> Not sure of the location in the list (this matches the ipod muxer's
> ordering, while additional formats seem to have just been added into
> their list/group as they popped up - that said since this is a static
> symbol I would expect even if the addition was in the middle, it
> should be a-OK), but after taking a quick look at the ALAC code paths
> this seems to cause writing of boxes that seem to make sense (audio
> description plus whatever is in the extradata).
>
> I will attempt to check tomorrow if there's a spec for this to
> double-check against, but preliminarily this looks good to me.

Verified against the spec
(https://github.com/macosforge/alac/blob/master/ALACMagicCookieDescription.txt#L177).

As we already had the non-legacy (mode != MOV) support in place, the
output - as expected - matches the specification (checked with
L-SMASH's boxdumper).

Thus, the change itself is LGTM.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_h265_syntax_template: Better check for num_long_term_sps

2020-11-21 Thread Mark Thompson

On 21/11/2020 17:37, Michael Niedermayer wrote:

On Sun, Nov 15, 2020 at 09:37:45PM +, Mark Thompson wrote:

On 14/11/2020 10:18, Michael Niedermayer wrote:

Fixes: index 26 out of bounds for type 'uint8_t [16]'
Fixes: 
24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
   libavcodec/cbs_h265_syntax_template.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 48fae82d04..8eb6e159f4 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1405,6 +1405,8 @@ static int 
FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
   infer(num_long_term_sps, 0);
   idx_size = 0;
   }
+if (HEVC_MAX_REFS < current->num_long_term_sps)
+return AVERROR_INVALIDDATA;


Please don't put isolated tests in the middle of the template.  If it 
constrains a value then add it to the constraints on that value.


   ue(num_long_term_pics, 0, HEVC_MAX_REFS - 
current->num_long_term_sps);
   for (i = 0; i < current->num_long_term_sps +



It would be good if the commit message could include an explanation derived 
from the standard, too.

As far as I can tell the constraint doesn't appear explicitly, but the SPS is 
allowed to define more possible long term frames than are actually allowed to 
be present at any given moment so we need the tighter bound.


Is the change below what you had in mind ?

commit 72c6c46bb2b31b2822331aff461acccd0a4f9159 (HEAD -> master)
Author: Michael Niedermayer 
Date:   Fri Nov 13 23:15:52 2020 +0100

 avcodec/cbs_h265_syntax_template: Better check for num_long_term_sps
 
 As far as we can tell the constraint doesn't appear explicitly, but the SPS is allowed to

 define more possible long term frames than are actually allowed to be 
present at any given moment so we need the tighter bound.


I meant write a commit message which explains where in the standard the 
constraint is coming from.  I wrote that because I didn't see any extra 
constraint written in the standard for num_long_term_sps but 
num_long_term_ref_pics_sps is indeed bigger, so presumably it must be implied 
by something else.

 
 Fixes: index 26 out of bounds for type 'uint8_t [16]'

 Fixes: 
24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880
 
 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg

 Signed-off-by: Michael Niedermayer 

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 48fae82d04..30f2bd328c 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1399,7 +1399,7 @@ static int 
FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
  unsigned int idx_size;
  
  if (sps->num_long_term_ref_pics_sps > 0) {

-ue(num_long_term_sps, 0, sps->num_long_term_ref_pics_sps);
+ue(num_long_term_sps, 0, 
FFMIN(sps->num_long_term_ref_pics_sps, HEVC_MAX_REFS));


Yes to this part.


  idx_size = av_log2(sps->num_long_term_ref_pics_sps - 1) + 
1;
  } else {
  infer(num_long_term_sps, 0);

[...]


- Mark
___
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] hwcontext_drm: issue DMA_BUF_IOCTL_SYNC when mapping FDs

2020-11-21 Thread Mark Thompson

On 20/11/2020 17:26, Lynne wrote:

This improves performance and helps a little when given FDs without
any synchronization fences.

Patch attached.
 > From b4b0b8038bef08cf3dae9daa78eca3a675b67f89 Mon Sep 17 00:00:00 2001

> From: Lynne 
> Date: Fri, 20 Nov 2020 18:23:42 +0100
> Subject: [PATCH] hwcontext_drm: issue DMA_BUF_IOCTL_SYNC when mapping FDs
>
> This improves performance and helps a little when given FDs without
> any synchronization fences.
> ---
>  libavutil/hwcontext_drm.c | 36 +++-
>  1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/libavutil/hwcontext_drm.c b/libavutil/hwcontext_drm.c
> index 32cbde82eb..ceacf683a0 100644
> --- a/libavutil/hwcontext_drm.c
> +++ b/libavutil/hwcontext_drm.c
> @@ -19,6 +19,8 @@
>  #include 
>  #include 
>  #include 
> +#include 

Is it possible that adding raw ioctl() calls will cause problems on non-Linux 
platforms with libdrm, like FreeBSD?  (Maybe they implement the same ioctl()s, 
I don't know.)

> +#include 
>
>  #include 
>  #include 
> @@ -85,6 +87,8 @@ static int drm_get_buffer(AVHWFramesContext *hwfc, AVFrame 
*frame)
>  typedef struct DRMMapping {
>  // Address and length of each mmap()ed region.
>  int nb_regions;
> +int sync_flags;
> +int object[AV_DRM_MAX_PLANES];
>  void *address[AV_DRM_MAX_PLANES];
>  size_t length[AV_DRM_MAX_PLANES];
>  } DRMMapping;
> @@ -93,10 +97,16 @@ static void drm_unmap_frame(AVHWFramesContext *hwfc,
>  HWMapDescriptor *hwmap)
>  {
>  DRMMapping *map = hwmap->priv;
> -int i;
> -
> -for (i = 0; i < map->nb_regions; i++)
> +struct dma_buf_sync sync = { .flags = DMA_BUF_SYNC_END | map->sync_flags 
};
> +int i, ret;
> +
> +for (i = 0; i < map->nb_regions; i++) {
> +ret = ioctl(map->object[i], DMA_BUF_IOCTL_SYNC, &sync);
> +if (ret)
> +av_log(hwfc, AV_LOG_ERROR, "Failed to issue ioctl sync to DRM object 
"
> +   "%d: %d.\n", map->object[i], errno);
>  munmap(map->address[i], map->length[i]);
> +}
>
>  av_free(map);
>  }
> @@ -105,6 +115,7 @@ static int drm_map_frame(AVHWFramesContext *hwfc,
>   AVFrame *dst, const AVFrame *src, int flags)
>  {
>  const AVDRMFrameDescriptor *desc = (AVDRMFrameDescriptor*)src->data[0];
> +struct dma_buf_sync sync_start = { 0 };
>  DRMMapping *map;
>  int err, i, p, plane;
>  int mmap_prot;
> @@ -115,10 +126,16 @@ static int drm_map_frame(AVHWFramesContext *hwfc,
>  return AVERROR(ENOMEM);
>
>  mmap_prot = 0;
> -if (flags & AV_HWFRAME_MAP_READ)
> +if (flags & AV_HWFRAME_MAP_READ) {
>  mmap_prot |= PROT_READ;
> -if (flags & AV_HWFRAME_MAP_WRITE)
> +map->sync_flags |= DMA_BUF_SYNC_READ;
> +}
> +if (flags & AV_HWFRAME_MAP_WRITE) {
>  mmap_prot |= PROT_WRITE;
> +map->sync_flags |= DMA_BUF_SYNC_WRITE;
> +}
> +
> +sync_start.flags = DMA_BUF_SYNC_START | map->sync_flags;
>
>  av_assert0(desc->nb_objects <= AV_DRM_MAX_PLANES);
>  for (i = 0; i < desc->nb_objects; i++) {
> @@ -133,6 +150,15 @@ static int drm_map_frame(AVHWFramesContext *hwfc,
>
>  map->address[i] = addr;
>  map->length[i]  = desc->objects[i].size;
> +map->object[i] = desc->objects[i].fd;
> +
> +err = ioctl(desc->objects[i].fd, DMA_BUF_IOCTL_SYNC, &sync_start);
> +if (err) {
> +err = AVERROR(errno);
> +av_log(hwfc, AV_LOG_ERROR, "Failed to issue ioctl sync to DRM object 
"
> +   "%d: %d.\n", desc->objects[i].fd, errno);
> +goto fail;
> +}
>  }
>  map->nb_regions = i;
>
> --
> 2.29.2
>

Patch LGTM if we can check the compatibility.

Thanks,

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_h265_syntax_template: Better check for num_long_term_sps

2020-11-21 Thread Michael Niedermayer
On Sun, Nov 15, 2020 at 09:37:45PM +, Mark Thompson wrote:
> On 14/11/2020 10:18, Michael Niedermayer wrote:
> > Fixes: index 26 out of bounds for type 'uint8_t [16]'
> > Fixes: 
> > 24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavcodec/cbs_h265_syntax_template.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavcodec/cbs_h265_syntax_template.c 
> > b/libavcodec/cbs_h265_syntax_template.c
> > index 48fae82d04..8eb6e159f4 100644
> > --- a/libavcodec/cbs_h265_syntax_template.c
> > +++ b/libavcodec/cbs_h265_syntax_template.c
> > @@ -1405,6 +1405,8 @@ static int 
> > FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
> >   infer(num_long_term_sps, 0);
> >   idx_size = 0;
> >   }
> > +if (HEVC_MAX_REFS < current->num_long_term_sps)
> > +return AVERROR_INVALIDDATA;
> 
> Please don't put isolated tests in the middle of the template.  If it 
> constrains a value then add it to the constraints on that value.
> 
> >   ue(num_long_term_pics, 0, HEVC_MAX_REFS - 
> > current->num_long_term_sps);
> >   for (i = 0; i < current->num_long_term_sps +
> > 
> 
> It would be good if the commit message could include an explanation derived 
> from the standard, too.
> 
> As far as I can tell the constraint doesn't appear explicitly, but the SPS is 
> allowed to define more possible long term frames than are actually allowed to 
> be present at any given moment so we need the tighter bound.

Is the change below what you had in mind ?

commit 72c6c46bb2b31b2822331aff461acccd0a4f9159 (HEAD -> master)
Author: Michael Niedermayer 
Date:   Fri Nov 13 23:15:52 2020 +0100

avcodec/cbs_h265_syntax_template: Better check for num_long_term_sps

As far as we can tell the constraint doesn't appear explicitly, but the SPS 
is allowed to
define more possible long term frames than are actually allowed to be 
present at any given moment so we need the tighter bound.

Fixes: index 26 out of bounds for type 'uint8_t [16]'
Fixes: 
24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 48fae82d04..30f2bd328c 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1399,7 +1399,7 @@ static int 
FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
 unsigned int idx_size;
 
 if (sps->num_long_term_ref_pics_sps > 0) {
-ue(num_long_term_sps, 0, sps->num_long_term_ref_pics_sps);
+ue(num_long_term_sps, 0, 
FFMIN(sps->num_long_term_ref_pics_sps, HEVC_MAX_REFS));
 idx_size = av_log2(sps->num_long_term_ref_pics_sps - 1) + 
1;
 } else {
 infer(num_long_term_sps, 0);

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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

[FFmpeg-devel] [PATCH] avformat/utils: Change compute_chapters_end() from O(n²) to O(n log n)

2020-11-21 Thread Michael Niedermayer
Fixes: Timeout (49sec -> 9sec)
Fixes: 
27427/clusterfuzz-testcase-minimized-ffmpeg_dem_FFMETADATA_fuzzer-5140589838073856

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 503e583ad0..9fac3fc2aa 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3191,15 +3191,58 @@ enum AVCodecID av_codec_get_id(const AVCodecTag *const 
*tags, unsigned int tag)
 return AV_CODEC_ID_NONE;
 }
 
+static int chapter_start_cmp(const void *p1, const void *p2)
+{
+AVChapter *ch1 = *(AVChapter**)p1;
+AVChapter *ch2 = *(AVChapter**)p2;
+int delta = av_compare_ts(ch1->start, ch1->time_base, ch2->start, 
ch2->time_base);
+if (delta)
+return delta;
+return (ch1 > ch2) - (ch1 < ch2);
+}
+
 static void compute_chapters_end(AVFormatContext *s)
 {
 unsigned int i, j;
 int64_t max_time = 0;
+int computations = 0;
 
 if (s->duration > 0 && s->start_time < INT64_MAX - s->duration)
 max_time = s->duration +
((s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time);
 
+for (i = 0; i < s->nb_chapters; i++)
+if (s->chapters[i]->end == AV_NOPTS_VALUE)
+computations ++;
+
+if (computations > 5) {
+AVChapter **timetable = av_malloc(s->nb_chapters * sizeof(*timetable));
+if (timetable) {
+for (i = 0; i < s->nb_chapters; i++)
+timetable[i] = s->chapters[i];
+qsort(timetable, s->nb_chapters, sizeof(*timetable), 
chapter_start_cmp);
+
+for (i = 0; i < s->nb_chapters; i++)
+if (timetable[i]->end == AV_NOPTS_VALUE) {
+AVChapter *ch = timetable[i];
+int64_t end = max_time ? av_rescale_q(max_time, 
AV_TIME_BASE_Q,
+ch->time_base)
+: INT64_MAX;
+
+if (i + 1 < s->nb_chapters) {
+AVChapter *ch1 = timetable[i + 1];
+int64_t next_start = av_rescale_q(ch1->start, 
ch1->time_base,
+ch->time_base);
+if (next_start > ch->start && next_start < end)
+end = next_start;
+}
+ch->end = (end == INT64_MAX || end < ch->start) ? 
ch->start : end;
+}
+av_free(timetable);
+return;
+}
+}
+
 for (i = 0; i < s->nb_chapters; i++)
 if (s->chapters[i]->end == AV_NOPTS_VALUE) {
 AVChapter *ch = s->chapters[i];
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH 0/3] add vvc raw demuxer

2020-11-21 Thread Mark Thompson

On 21/11/2020 02:19, James Almer wrote:

On 11/20/2020 10:55 PM, Nuo Mi wrote:

Hi Mark, James and all,
There are two ways to implement the parser.
1. use cbs like av1 parser.
2. follow h264/h265 parser method.
Which is your preferred?

thanks


A CBS module for VVC is needed regardless of how the parser is ultimately 
implemented (There will be other uses, like bitstream filters), so might as 
well use it for it, like with AV1.


+1.

Attached is some initial investigation I did recently into CBS implementation.  
The non-CBS parts are all hacks to get a raw stream fed into trace_headers, and 
can be ignored for non-test purposes.

My thoughts emerging from that:

* The commonality with H.26[45] is sufficient that it's probably best to extend 
that into CBS H.26[456].
  * All of the styling is the same, so doing that avoids duplicating a lot of 
templating code.
  * I haven't done that here because it was easier to hack in by starting with 
a new file.
  * Separately I've been looking at merging the implementation of more common 
elements of H.26[45], and that will apply here too (SEI in particular, where 
H.274 matches in parts as well).

* There is /a lot/ of boilerplate needed to get even a minimal version working.
  * The parameter sets are even bigger and more complex than they were in H.265 
(and the VUI that you want for metadata is still right at the end of the SPS).
  * The clean specification is very appreciated - I haven't found any nasty 
interdependencies yet, though I haven't read all of it in detail.
  * Given the huge surface area for errors here, it may not be a good idea to 
include it until we have the full conformance test suite (like H.265.1) to test 
it with.

* It seemed like the right choice on naming was to use H.266 as the name 
everywhere and always refer to that:
  * It stays consistent with the most common name for H.264 (still the 
most-used codec).
  * It's a formal standard, unlike the JVET drafts.
  * Anyone can download the full specification for free 
(), unlike the ISO/IEC 23090-3 
version.

I'm not working on this right now, but I'll probably come back to it in the 
not-too-distant future.

So, any thoughts welcome - given the scope of this we should probably agree 
roughly what the intended structure will be before writing much more.

Thanks,

- Mark
>From 9cee4d68d00f42a5ba97e044f5312dbe6c59a63e Mon Sep 17 00:00:00 2001
From: Mark Thompson 
Date: Sat, 21 Nov 2020 16:41:45 +
Subject: [PATCH] WIP CBS H.266

---
 configure |   4 +-
 libavcodec/Makefile   |   2 +
 libavcodec/cbs.c  |   6 +
 libavcodec/cbs_h266.c | 652 ++
 libavcodec/cbs_h266.h | 196 
 libavcodec/cbs_h266_syntax_template.c | 365 ++
 libavcodec/cbs_internal.h |   1 +
 libavcodec/codec_desc.c   |   7 +
 libavcodec/codec_id.h |   1 +
 libavcodec/h266.h |  89 
 libavcodec/h266_parser.c  |  45 ++
 libavcodec/parsers.c  |   1 +
 libavformat/Makefile  |   1 +
 libavformat/allformats.c  |   1 +
 libavformat/h266dec.c |  29 ++
 libavformat/rawdec.c  |   2 +
 16 files changed, 1401 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/cbs_h266.c
 create mode 100644 libavcodec/cbs_h266.h
 create mode 100644 libavcodec/cbs_h266_syntax_template.c
 create mode 100644 libavcodec/h266.h
 create mode 100644 libavcodec/h266_parser.c
 create mode 100644 libavformat/h266dec.c

diff --git a/configure b/configure
index 51e43fbf66..b9356f3a82 100755
--- a/configure
+++ b/configure
@@ -2354,6 +2354,7 @@ CONFIG_EXTRA="
 cbs_av1
 cbs_h264
 cbs_h265
+cbs_h266
 cbs_jpeg
 cbs_mpeg2
 cbs_vp9
@@ -2622,6 +2623,7 @@ threads_if_any="$THREADS_LIST"
 cbs_av1_select="cbs"
 cbs_h264_select="cbs"
 cbs_h265_select="cbs"
+cbs_h266_select="cbs"
 cbs_jpeg_select="cbs"
 cbs_mpeg2_select="cbs"
 cbs_vp9_select="cbs"
@@ -3176,7 +3178,7 @@ h264_redundant_pps_bsf_select="cbs_h264"
 hevc_metadata_bsf_select="cbs_h265"
 mjpeg2jpeg_bsf_select="jpegtables"
 mpeg2_metadata_bsf_select="cbs_mpeg2"
-trace_headers_bsf_select="cbs"
+trace_headers_bsf_select="cbs cbs_h266"
 vp9_metadata_bsf_select="cbs_vp9"
 
 # external libraries
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b4777be4d4..c41b892063 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -73,6 +73,7 @@ OBJS-$(CONFIG_CBS) += cbs.o
 OBJS-$(CONFIG_CBS_AV1) += cbs_av1.o
 OBJS-$(CONFIG_CBS_H264)+= cbs_h2645.o h2645_parse.o
 OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o h2645_parse.o
+OBJS-$(CONFIG_CBS_H266)+= cbs_h266.o
 OBJS-$(CONFIG_CBS_JPEG)+= cbs_jpeg.o
 OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
 OBJS-$(

[FFmpeg-devel] [PATCH] avformat/hls: Fixes #EXT-X-PROGRAM-DATE-TIME value of existing segments from getting over written with new value when appending new segments to an existing playlist file

2020-11-21 Thread Vignesh Ravichandran
Signed-off-by: Vignesh Ravichandran 
---
 libavformat/hlsenc.c | 35 +++
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index cbfd8f7c0d..030a2d3b97 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -88,6 +88,7 @@ typedef struct HLSSegment {
 char iv_string[KEYSIZE*2 + 1];
 
 struct HLSSegment *next;
+double discont_program_date_time;
 } HLSSegment;
 
 typedef enum HLSFlags {
@@ -1124,6 +1125,7 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls,
 en->keyframe_size = vs->video_keyframe_size;
 en->next = NULL;
 en->discont  = 0;
+en->discont_program_date_time = 0;
 
 if (vs->discontinuity) {
 en->discont = 1;
@@ -1148,7 +1150,8 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls,
 
 if (hls->max_nb_segments && vs->nb_entries >= hls->max_nb_segments) {
 en = vs->segments;
-vs->initial_prog_date_time += en->duration;
+if (!en->next->discont_program_date_time && 
!en->discont_program_date_time)
+vs->initial_prog_date_time += en->duration;
 vs->segments = en->next;
 if (en && hls->flags & HLS_DELETE_SEGMENTS &&
 #if FF_API_HLS_WRAP
@@ -1182,6 +1185,8 @@ static int parse_playlist(AVFormatContext *s, const char 
*url, VariantStream *vs
 char line[MAX_URL_SIZE];
 const char *ptr;
 const char *end;
+int is_discont_detected = 0;
+double discont_program_date_time = 0;
 
 if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
&s->interrupt_callback, NULL,
@@ -1211,6 +1216,7 @@ static int parse_playlist(AVFormatContext *s, const char 
*url, VariantStream *vs
 } else if (av_strstart(line, "#EXT-X-DISCONTINUITY", &ptr)) {
 is_segment = 1;
 vs->discontinuity = 1;
+is_discont_detected = 1;
 } else if (av_strstart(line, "#EXTINF:", &ptr)) {
 is_segment = 1;
 vs->duration = atof(ptr);
@@ -1236,7 +1242,23 @@ static int parse_playlist(AVFormatContext *s, const char 
*url, VariantStream *vs
 av_strlcpy(vs->iv_string, ptr, sizeof(vs->iv_string));
 }
 }
-
+} else if (av_strstart(line, "#EXT-X-PROGRAM-DATE-TIME:", &ptr) && 
is_discont_detected) {
+struct tm program_date_time;
+int y,M,d,h,m,s;
+double ms;
+sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", &y, &M, &d, &h, &m, &s, &ms);
+
+program_date_time.tm_year = y - 1900;
+program_date_time.tm_mon = M - 1;
+program_date_time.tm_mday = d;
+program_date_time.tm_hour = h;
+program_date_time.tm_min = m;
+program_date_time.tm_sec = s;
+program_date_time.tm_isdst = -1;
+
+discont_program_date_time = mktime(&program_date_time);
+discont_program_date_time += (double)(ms / 1000);
+is_discont_detected = 0;
 } else if (av_strstart(line, "#", NULL)) {
 continue;
 } else if (line[0]) {
@@ -1250,8 +1272,9 @@ static int parse_playlist(AVFormatContext *s, const char 
*url, VariantStream *vs
 is_segment = 0;
 new_start_pos = avio_tell(vs->avf->pb);
 vs->size = new_start_pos - vs->start_pos;
-vs->initial_prog_date_time -= vs->duration; // this is a 
previously existing segment
 ret = hls_append_segment(s, hls, vs, vs->duration, 
vs->start_pos, vs->size);
+vs->last_segment->discont_program_date_time = 
discont_program_date_time;
+discont_program_date_time += vs->duration;
 if (ret < 0)
 goto fail;
 vs->start_pos = new_start_pos;
@@ -1572,7 +1595,11 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 ret = ff_hls_write_file_entry(byterange_mode ? hls->m3u8_out : 
vs->out, en->discont, byterange_mode,
   en->duration, hls->flags & 
HLS_ROUND_DURATIONS,
   en->size, en->pos, hls->baseurl,
-  en->filename, prog_date_time_p, 
en->keyframe_size, en->keyframe_pos, hls->flags & HLS_I_FRAMES_ONLY);
+  en->filename,
+  en->discont_program_date_time ? 
&en->discont_program_date_time : prog_date_time_p,
+  en->keyframe_size, en->keyframe_pos, 
hls->flags & HLS_I_FRAMES_ONLY);
+if (en->discont_program_date_time)
+en->discont_program_date_time -= en->duration;
 if (ret < 0) {
 av_log(s, AV_LOG_WARNING, "ff_hls_write_file_entry get error\n");
 }
-- 
2.24.2 (Apple Git-127)

___
ffmpeg-devel ma

Re: [FFmpeg-devel] [PATCH 2/4] avdevice/decklink: add AV_OPT_FLAG_DEPRECATED flag for list_devices

2020-11-21 Thread Engi Gang
im stupid sorry

On Sat, Nov 21, 2020 at 2:57 PM Reto Kromer  wrote:

> Engi Gang wrote:
>
> >unsubscribe
>
> Please follow the instruction given at the end of each single
> message:
>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> >To unsubscribe, visit link above, or email
> >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/4] avdevice/decklink: add AV_OPT_FLAG_DEPRECATED flag for list_devices

2020-11-21 Thread Reto Kromer
Engi Gang wrote:

>unsubscribe

Please follow the instruction given at the end of each single
message:

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

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

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

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

[FFmpeg-devel] [PATCH 3/3] avcodec/mlpdec: Avoid code duplication when initializing VLCs

2020-11-21 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mlpdec.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
index ec346868c6..ed25b71d2d 100644
--- a/libavcodec/mlpdec.c
+++ b/libavcodec/mlpdec.c
@@ -206,15 +206,14 @@ static VLC huff_vlc[3];
 
 static av_cold void init_static(void)
 {
-INIT_VLC_STATIC(&huff_vlc[0], VLC_BITS, 18,
-&ff_mlp_huffman_tables[0][0][1], 2, 1,
-&ff_mlp_huffman_tables[0][0][0], 2, 1, VLC_STATIC_SIZE);
-INIT_VLC_STATIC(&huff_vlc[1], VLC_BITS, 16,
-&ff_mlp_huffman_tables[1][0][1], 2, 1,
-&ff_mlp_huffman_tables[1][0][0], 2, 1, VLC_STATIC_SIZE);
-INIT_VLC_STATIC(&huff_vlc[2], VLC_BITS, 15,
-&ff_mlp_huffman_tables[2][0][1], 2, 1,
-&ff_mlp_huffman_tables[2][0][0], 2, 1, VLC_STATIC_SIZE);
+for (int i = 0; i < 3; i++) {
+static VLC_TYPE vlc_buf[3 * VLC_STATIC_SIZE][2];
+huff_vlc[i].table   = &vlc_buf[i * VLC_STATIC_SIZE];
+huff_vlc[i].table_allocated = VLC_STATIC_SIZE;
+init_vlc(&huff_vlc[i], VLC_BITS, 18,
+ &ff_mlp_huffman_tables[i][0][1], 2, 1,
+ &ff_mlp_huffman_tables[i][0][0], 2, 1, 
INIT_VLC_USE_NEW_STATIC);
+}
 
 ff_mlp_init_crc();
 }
-- 
2.25.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 2/3] avcodec/mlpdec: Make decoders init-threadsafe

2020-11-21 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mlpdec.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
index 1a2c0f29ac..ec346868c6 100644
--- a/libavcodec/mlpdec.c
+++ b/libavcodec/mlpdec.c
@@ -30,6 +30,7 @@
 #include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/channel_layout.h"
+#include "libavutil/thread.h"
 #include "get_bits.h"
 #include "internal.h"
 #include "libavutil/crc.h"
@@ -205,7 +206,6 @@ static VLC huff_vlc[3];
 
 static av_cold void init_static(void)
 {
-if (!huff_vlc[0].bits) {
 INIT_VLC_STATIC(&huff_vlc[0], VLC_BITS, 18,
 &ff_mlp_huffman_tables[0][0][1], 2, 1,
 &ff_mlp_huffman_tables[0][0][0], 2, 1, VLC_STATIC_SIZE);
@@ -215,7 +215,6 @@ static av_cold void init_static(void)
 INIT_VLC_STATIC(&huff_vlc[2], VLC_BITS, 15,
 &ff_mlp_huffman_tables[2][0][1], 2, 1,
 &ff_mlp_huffman_tables[2][0][0], 2, 1, VLC_STATIC_SIZE);
-}
 
 ff_mlp_init_crc();
 }
@@ -279,15 +278,17 @@ static inline int read_huff_channels(MLPDecodeContext *m, 
GetBitContext *gbp,
 
 static av_cold int mlp_decode_init(AVCodecContext *avctx)
 {
+static AVOnce init_static_once = AV_ONCE_INIT;
 MLPDecodeContext *m = avctx->priv_data;
 int substr;
 
-init_static();
 m->avctx = avctx;
 for (substr = 0; substr < MAX_SUBSTREAMS; substr++)
 m->substream[substr].lossless_check_data = 0x;
 ff_mlpdsp_init(&m->dsp);
 
+ff_thread_once(&init_static_once, init_static);
+
 return 0;
 }
 
@@ -1339,6 +1340,7 @@ AVCodec ff_mlp_decoder = {
 .init   = mlp_decode_init,
 .decode = read_access_unit,
 .capabilities   = AV_CODEC_CAP_DR1,
+.caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
 };
 #endif
 #if CONFIG_TRUEHD_DECODER
@@ -1351,5 +1353,6 @@ AVCodec ff_truehd_decoder = {
 .init   = mlp_decode_init,
 .decode = read_access_unit,
 .capabilities   = AV_CODEC_CAP_DR1,
+.caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
 };
 #endif /* CONFIG_TRUEHD_DECODER */
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 1/3] avcodec/mlp: Make initializing CRCs thread-safe

2020-11-21 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mlp.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/libavcodec/mlp.c b/libavcodec/mlp.c
index ddbab60c4e..74363c3b95 100644
--- a/libavcodec/mlp.c
+++ b/libavcodec/mlp.c
@@ -23,6 +23,7 @@
 
 #include "libavutil/crc.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil/thread.h"
 #include "mlp.h"
 
 const uint8_t ff_mlp_huffman_tables[3][18][2] = {
@@ -62,7 +63,6 @@ const uint64_t ff_mlp_channel_layouts[12] = {
 AV_CH_LAYOUT_4POINT1, AV_CH_LAYOUT_5POINT1_BACK, 0,
 };
 
-static int crc_init = 0;
 #if CONFIG_SMALL
 #define CRC_TABLE_SIZE 257
 #else
@@ -72,14 +72,17 @@ static AVCRC crc_63[CRC_TABLE_SIZE];
 static AVCRC crc_1D[CRC_TABLE_SIZE];
 static AVCRC crc_2D[CRC_TABLE_SIZE];
 
+static av_cold void mlp_init_crc(void)
+{
+av_crc_init(crc_63, 0,  8,   0x63, sizeof(crc_63));
+av_crc_init(crc_1D, 0,  8,   0x1D, sizeof(crc_1D));
+av_crc_init(crc_2D, 0, 16, 0x002D, sizeof(crc_2D));
+}
+
 av_cold void ff_mlp_init_crc(void)
 {
-if (!crc_init) {
-av_crc_init(crc_63, 0,  8,   0x63, sizeof(crc_63));
-av_crc_init(crc_1D, 0,  8,   0x1D, sizeof(crc_1D));
-av_crc_init(crc_2D, 0, 16, 0x002D, sizeof(crc_2D));
-crc_init = 1;
-}
+static AVOnce init_static_once = AV_ONCE_INIT;
+ff_thread_once(&init_static_once, mlp_init_crc);
 }
 
 uint16_t ff_mlp_checksum16(const uint8_t *buf, unsigned int buf_size)
-- 
2.25.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 4/4] avdevice/decklink_dec: fix warning for unused variable

2020-11-21 Thread Marton Balint



On Sat, 21 Nov 2020, lance.lmw...@gmail.com wrote:


From: Limin Wang 

Signed-off-by: Limin Wang 
---
libavdevice/decklink_dec.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 049e133..2e41b58 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -945,13 +945,13 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(

if (videoFrame->GetAncillaryData(&vanc) == S_OK) {
int i;
-int64_t line_mask = 1;
BMDPixelFormat vanc_format = vanc->GetPixelFormat();
txt_buf[0] = 0x10;// data_identifier - EBU_data
txt_buf++;
#if CONFIG_LIBZVBI
if (ctx->bmd_mode == bmdModePAL && ctx->teletext_lines &&
(vanc_format == bmdFormat8BitYUV || vanc_format == 
bmdFormat10BitYUV)) {
+int64_t line_mask = 1;
av_assert0(videoFrame->GetWidth() == 720);
for (i = 6; i < 336; i++, line_mask <<= 1) {
uint8_t *buf;


LGTM, thanks.

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

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

Re: [FFmpeg-devel] [PATCH 2/4] avdevice/decklink: add AV_OPT_FLAG_DEPRECATED flag for list_devices

2020-11-21 Thread Marton Balint



On Sat, 21 Nov 2020, lance.lmw...@gmail.com wrote:


From: Limin Wang 

and claim the option deprecated in the description.


No, the description should stay as is. Adding the flag is enough, the 
deprecation will be printed if the user asks for the list of options based 
on the flag.


Regards,
Marton



Signed-off-by: Limin Wang 
---
libavdevice/decklink_dec_c.c | 3 ++-
libavdevice/decklink_enc_c.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 53a4774..c6b38d2 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -30,7 +30,8 @@
#define DEC AV_OPT_FLAG_DECODING_PARAM

static const AVOption options[] = {
-{ "list_devices", "list available devices"  , OFFSET(list_devices), 
AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, DEC },
+{ "list_devices", "list available devices(deprecated, use -sources decklink 
instead)", OFFSET(list_devices),
+
AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, DEC | AV_OPT_FLAG_DEPRECATED},
{ "list_formats", "list supported formats"  , OFFSET(list_formats), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, DEC },
{ "format_code",  "set format by fourcc", OFFSET(format_code),  
AV_OPT_TYPE_STRING, { .str = NULL}, 0, 0, DEC },
{ "raw_format",   "pixel format to be returned by the card when capturing" , 
OFFSET(raw_format),  AV_OPT_TYPE_INT, { .i64 = 0}, 0, 5, DEC, "raw_format" },
diff --git a/libavdevice/decklink_enc_c.c b/libavdevice/decklink_enc_c.c
index e7b0117..ce99220 100644
--- a/libavdevice/decklink_enc_c.c
+++ b/libavdevice/decklink_enc_c.c
@@ -28,7 +28,8 @@
#define OFFSET(x) offsetof(struct decklink_cctx, x)
#define ENC AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
-{ "list_devices", "list available devices"  , OFFSET(list_devices), 
AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, ENC },
+{ "list_devices", "list available devices(deprecated, use -sinks decklink 
instead)"
+, OFFSET(list_devices), 
AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, ENC | AV_OPT_FLAG_DEPRECATED},
{ "list_formats", "list supported formats"  , OFFSET(list_formats), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, ENC },
{ "preroll" , "video preroll in seconds", OFFSET(preroll ), 
AV_OPT_TYPE_DOUBLE, { .dbl = 0.5 }, 0, 5, ENC },
{ "duplex_mode" , "duplex mode" , OFFSET(duplex_mode ), AV_OPT_TYPE_INT   
, { .i64 = 0   }, 0, 2, ENC, "duplex_mode"},
--
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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/4] avdevice/decklink: use boolean for list_devices option

2020-11-21 Thread Marton Balint



On Sat, 21 Nov 2020, lance.lmw...@gmail.com wrote:


From: Limin Wang 

For the document(indevs.texi and outdevs.texi) used it as boolean.

Signed-off-by: Limin Wang 
---
libavdevice/decklink_dec_c.c | 2 +-
libavdevice/decklink_enc_c.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 5997440..53a4774 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -30,7 +30,7 @@
#define DEC AV_OPT_FLAG_DECODING_PARAM

static const AVOption options[] = {
-{ "list_devices", "list available devices"  , OFFSET(list_devices), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, DEC },
+{ "list_devices", "list available devices"  , OFFSET(list_devices), 
AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, DEC },
{ "list_formats", "list supported formats"  , OFFSET(list_formats), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, DEC },
{ "format_code",  "set format by fourcc", OFFSET(format_code),  
AV_OPT_TYPE_STRING, { .str = NULL}, 0, 0, DEC },
{ "raw_format",   "pixel format to be returned by the card when capturing" , 
OFFSET(raw_format),  AV_OPT_TYPE_INT, { .i64 = 0}, 0, 5, DEC, "raw_format" },
diff --git a/libavdevice/decklink_enc_c.c b/libavdevice/decklink_enc_c.c
index 682c714..e7b0117 100644
--- a/libavdevice/decklink_enc_c.c
+++ b/libavdevice/decklink_enc_c.c
@@ -28,7 +28,7 @@
#define OFFSET(x) offsetof(struct decklink_cctx, x)
#define ENC AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
-{ "list_devices", "list available devices"  , OFFSET(list_devices), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, ENC },
+{ "list_devices", "list available devices"  , OFFSET(list_devices), 
AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, ENC },
{ "list_formats", "list supported formats"  , OFFSET(list_formats), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, ENC },
{ "preroll" , "video preroll in seconds", OFFSET(preroll ), 
AV_OPT_TYPE_DOUBLE, { .dbl = 0.5 }, 0, 5, ENC },
{ "duplex_mode" , "duplex mode" , OFFSET(duplex_mode ), AV_OPT_TYPE_INT   
, { .i64 = 0   }, 0, 2, ENC, "duplex_mode"},


LGTM, thanks.

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

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

Re: [FFmpeg-devel] [PATCH 2/4] avdevice/decklink: add AV_OPT_FLAG_DEPRECATED flag for list_devices

2020-11-21 Thread Engi Gang
unsubscribe

On Sat, Nov 21, 2020 at 4:08 AM  wrote:

> From: Limin Wang 
>
> and claim the option deprecated in the description.
>
> Signed-off-by: Limin Wang 
> ---
>  libavdevice/decklink_dec_c.c | 3 ++-
>  libavdevice/decklink_enc_c.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
> index 53a4774..c6b38d2 100644
> --- a/libavdevice/decklink_dec_c.c
> +++ b/libavdevice/decklink_dec_c.c
> @@ -30,7 +30,8 @@
>  #define DEC AV_OPT_FLAG_DECODING_PARAM
>
>  static const AVOption options[] = {
> -{ "list_devices", "list available devices"  , OFFSET(list_devices),
> AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, DEC },
> +{ "list_devices", "list available devices(deprecated, use -sources
> decklink instead)", OFFSET(list_devices),
> +
> AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, DEC | AV_OPT_FLAG_DEPRECATED},
>  { "list_formats", "list supported formats"  , OFFSET(list_formats),
> AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, DEC },
>  { "format_code",  "set format by fourcc", OFFSET(format_code),
> AV_OPT_TYPE_STRING, { .str = NULL}, 0, 0, DEC },
>  { "raw_format",   "pixel format to be returned by the card when
> capturing" , OFFSET(raw_format),  AV_OPT_TYPE_INT, { .i64 = 0}, 0, 5, DEC,
> "raw_format" },
> diff --git a/libavdevice/decklink_enc_c.c b/libavdevice/decklink_enc_c.c
> index e7b0117..ce99220 100644
> --- a/libavdevice/decklink_enc_c.c
> +++ b/libavdevice/decklink_enc_c.c
> @@ -28,7 +28,8 @@
>  #define OFFSET(x) offsetof(struct decklink_cctx, x)
>  #define ENC AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
> -{ "list_devices", "list available devices"  , OFFSET(list_devices),
> AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, ENC },
> +{ "list_devices", "list available devices(deprecated, use -sinks
> decklink instead)"
> +, OFFSET(list_devices),
> AV_OPT_TYPE_BOOL  , { .i64 = 0   }, 0, 1, ENC | AV_OPT_FLAG_DEPRECATED},
>  { "list_formats", "list supported formats"  , OFFSET(list_formats),
> AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, ENC },
>  { "preroll" , "video preroll in seconds", OFFSET(preroll ),
> AV_OPT_TYPE_DOUBLE, { .dbl = 0.5 }, 0, 5, ENC },
>  { "duplex_mode" , "duplex mode" , OFFSET(duplex_mode ),
> AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 2, ENC, "duplex_mode"},
> --
> 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 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".