[FFmpeg-devel] [PATCH] avformat/hls: Properly expose intercepted ID3 tags to the API.

[rshaffer]

From: Richard Shaffer 

The HLS demuxer will process any ID3 tags at the beginning of a segment in
order to obtain timestamp data. However, when this data was parsed on a second
or subsequent segment, the updated metadata would be discarded. This change
preserves the data and also sets the AVSTREAM_EVENT_FLAG_METADATA_UPDATED
event flag when appropriate.
---
 libavformat/hls.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3d4f7f2647..3e2edb3484 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -982,18 +982,8 @@ static void parse_id3(AVFormatContext *s, AVIOContext *pb,
 }
 
 /* Check if the ID3 metadata contents have changed */
-static int id3_has_changed_values(struct playlist *pls, AVDictionary *metadata,
-  ID3v2ExtraMetaAPIC *apic)
+static int id3_has_changed_values(struct playlist *pls, ID3v2ExtraMetaAPIC 
*apic)
 {
-AVDictionaryEntry *entry = NULL;
-AVDictionaryEntry *oldentry;
-/* check that no keys have changed values */
-while ((entry = av_dict_get(metadata, "", entry, AV_DICT_IGNORE_SUFFIX))) {
-oldentry = av_dict_get(pls->id3_initial, entry->key, NULL, 
AV_DICT_MATCH_CASE);
-if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
-return 1;
-}
-
 /* check if apic appeared */
 if (apic && (pls->ctx->nb_streams != 2 || 
!pls->ctx->streams[1]->attached_pic.data))
 return 1;
@@ -1019,6 +1009,15 @@ static void handle_id3(AVIOContext *pb, struct playlist 
*pls)
 int64_t timestamp = AV_NOPTS_VALUE;
 
 parse_id3(pls->ctx, pb, , , , _meta);
+ff_id3v2_parse_priv_dict(, _meta);
+av_dict_copy(>ctx->metadata, metadata, 0);
+/*
+ * If we've handled any ID3 metadata here, it's not going to be seen by the
+ * sub-demuxer. In the case that we got here because of an IO call during
+ * hls_read_header, this will be cleared. Otherwise, it provides the
+ * necessary hint to hls_read_packet that there is new metadata.
+ */
+pls->ctx->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
 
 if (timestamp != AV_NOPTS_VALUE) {
 pls->id3_mpegts_timestamp = timestamp;
@@ -1037,12 +1036,10 @@ static void handle_id3(AVIOContext *pb, struct playlist 
*pls)
 /* demuxer not yet opened, defer picture attachment */
 pls->id3_deferred_extra = extra_meta;
 
-ff_id3v2_parse_priv_dict(, _meta);
-av_dict_copy(>ctx->metadata, metadata, 0);
 pls->id3_initial = metadata;
 
 } else {
-if (!pls->id3_changed && id3_has_changed_values(pls, metadata, apic)) {
+if (!pls->id3_changed && id3_has_changed_values(pls, apic)) {
 avpriv_report_missing_feature(pls->ctx, "Changing ID3 metadata in 
HLS audio elementary stream");
 pls->id3_changed = 1;
 }
@@ -1939,8 +1936,15 @@ static int hls_read_header(AVFormatContext *s)
  * Copy any metadata from playlist to main streams, but do not set
  * event flags.
  */
-if (pls->n_main_streams)
+if (pls->n_main_streams) {
 av_dict_copy(>main_streams[0]->metadata, pls->ctx->metadata, 
0);
+/*
+ * If we've intercepted metadata, we will have set this event flag.
+ * Clear it to avoid confusion, since otherwise we will flag it as
+ * new metadata on the next call to hls_read_packet.
+ */
+pls->ctx->event_flags = ~AVFMT_EVENT_FLAG_METADATA_UPDATED;
+}
 
 add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_AUDIO);
 add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_VIDEO);
-- 
2.15.1 (Apple Git-101)

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

Re: [FFmpeg-devel] [PATCH] doc/developer: update style guidelines to include for loops with declarations

[Rostislav Pehlivanov]

On 8 November 2017 at 21:26, Rostislav Pehlivanov 
wrote:

> Signed-off-by: Rostislav Pehlivanov 
> ---
>  doc/developer.texi | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index a7b4f1d737..de7d887451 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -132,6 +132,9 @@ designated struct initializers (@samp{struct s x = @{
> .i = 17 @};});
>  @item
>  compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
>
> +@item
> +for loops with variable definition (@samp{for (int i = 0; i < 8; i++)});
> +
>  @item
>  Implementation defined behavior for signed integers is assumed to match
> the
>  expected behavior for two's complement. Non representable values in
> integer
> --
> 2.15.0.403.gc27cc4dac6
>
>
Pushed, thanks
Its a bittersweet victory, took 3 years but its finally done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] configure: error out on unsupported MSVC versions

[Rostislav Pehlivanov]

On 16 May 2018 at 20:52, Rostislav Pehlivanov  wrote:

> The FATE tests for MSVC versions older than 2013 are untested in FATE
> and apparently are no longer supported.
>
> This commit makes the configure process error out in case an older version
> is used, and suggests to use a supported version of MSVC to compile.
>
> This also changes the documentation to reflect this.
>
> As discussed on IRC:
>
> 2018-05-12 19:45:16 jamrial then again, most of those were for old
> msvc, and i think we're not supporting versions older than 2013 (first one
> c99 compliant) anymore
> 2018-05-12 19:45:43 +JEEB   yea, I think 2013 update 2 is needed
>
> 22:53 <@atomnuker> nevcairiel: which commit broke/unsupported support for
> msvc 2013?
> 23:23 <@atomnuker> okay, it was JEEB
> 23:25 <+JEEB> which was for 2012 and older
> 23:25 <+JEEB> and IIRC we no longer test those in FATE so that was my
> assumption
> 23:26 <+JEEB> 2013 is when MS got trolled enough to actually update their
> C part
> 23:26 <+JEEB> aand actually advertised FFmpeg support
> 23:26 <+JEEB> (although it was semi-failing until VS2013 update 1 or 2)
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  configure |  3 +--
>  doc/platform.texi | 16 +++-
>  2 files changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/configure b/configure
> index 1f7d0140e3..e52f8f850b 100755
> --- a/configure
> +++ b/configure
> @@ -3988,8 +3988,7 @@ case "$toolchain" in
>  cc_default="cl"
>  cxx_default="cl"
>  else
> -cc_default="c99wrap cl"
> -cxx_default="c99wrap cl"
> +die "Unsupported MSVC version (2013 or newer required)"
>  fi
>  ld_default="$source_path/compat/windows/mslink"
>  nm_default="dumpbin -symbols"
> diff --git a/doc/platform.texi b/doc/platform.texi
> index bdfb6fd6a5..4090b85670 100644
> --- a/doc/platform.texi
> +++ b/doc/platform.texi
> @@ -148,16 +148,11 @@ To target 32 bits replace @code{x86_64} with
> @code{i686} in the command above.
>
>  @section Microsoft Visual C++ or Intel C++ Compiler for Windows
>
> -FFmpeg can be built with MSVC 2012 or earlier using a C99-to-C89
> conversion utility
> -and wrapper, or with MSVC 2013 and ICL natively.
> +FFmpeg can be built with MSVC 2013 or later.
>
>  You will need the following prerequisites:
>
>  @itemize
> -@item @uref{https://github.com/libav/c99-to-c89/, C99-to-C89 Converter &
> Wrapper}
> -(if using MSVC 2012 or earlier)
> -@item @uref{http://code.google.com/p/msinttypes/, msinttypes}
> -(if using MSVC 2012 or earlier)
>  @item @uref{http://msys2.github.io/, MSYS2}
>  @item @uref{http://www.nasm.us/, NASM}
>  (Also available via MSYS2's package manager.)
> @@ -166,16 +161,13 @@ You will need the following prerequisites:
>  To set up a proper environment in MSYS2, you need to run
> @code{msys_shell.bat} from
>  the Visual Studio or Intel Compiler command prompt.
>
> -Place @code{yasm.exe} somewhere in your @code{PATH}. If using MSVC 2012 or
> -earlier, place @code{c99wrap.exe} and @code{c99conv.exe} somewhere in your
> -@code{PATH} as well.
> +Place @code{yasm.exe} somewhere in your @code{PATH}.
>
>  Next, make sure any other headers and libs you want to use, such as zlib,
> are
>  located in a spot that the compiler can see. Do so by modifying the
> @code{LIB}
>  and @code{INCLUDE} environment variables to include the
> @strong{Windows-style}
>  paths to these directories. Alternatively, you can try to use the
> -@code{--extra-cflags}/@code{--extra-ldflags} configure options. If using
> MSVC
> -2012 or earlier, place @code{inttypes.h} somewhere the compiler can see
> too.
> +@code{--extra-cflags}/@code{--extra-ldflags} configure options.
>
>  Finally, run:
>
> @@ -217,8 +209,6 @@ can see.
>
>  @item FFmpeg has been tested with the following on i686 and x86_64:
>  @itemize
> -@item Visual Studio 2010 Pro and Express
> -@item Visual Studio 2012 Pro and Express
>  @item Visual Studio 2013 Pro and Express
>  @item Intel Composer XE 2013
>  @item Intel Composer XE 2013 SP1
> --
> 2.17.0
>
>
Pushed, thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libzvbi-teletextdec: formatted ass output

[Aman Gupta]

On Mon, May 7, 2018 at 4:20 PM, Aman Gupta  wrote:

>
>
> On Mon, May 7, 2018 at 4:07 PM, Marton Balint  wrote:
>
>>
>>
>> On Mon, 7 May 2018, Aman Gupta wrote:
>>
>>
>>>
>>> On Mon, May 7, 2018 at 12:50 PM, Aman Gupta  wrote:
>>>
>>>
>>>   On Sun, May 6, 2018 at 2:05 PM, Marton Balint 
>>> wrote:
>>> Inspired by the VideoLAN text decoder and its port to FFmpeg
>>> made by Aman
>>> Gupta.
>>>
>>>
>>> Thanks for incorporating my changes.
>>>
>>> I ran some tests, and colors work as expected. Positioning also works
>>> well, and is also pretty close to my version.
>>>
>>>
>>> I found that some live streams are not chopping empty lines correctly. I
>>> see extra newlines at the end:
>>>
>>>   Dialogue: 
>>> 0,0:13:21.66,9:59:59.99,Default,,0,0,0,,{\an1}Simson,\hPeter\hHartcher,\hRobyn\hParker
>>> \Nand\hBenjamin \N \N \N
>>>
>>> Here's a sample which shows extra newlines: https://s3.amazonaws
>>> .com/tmm1/teletext/capture_live1.mpg
>>>
>>
>> This is kind of intentional, in this case the new lines are kept to
>> position the subtitles a bit higher, and not to the very bottom of the
>> screen, to keep the rough position of the teletext subtitles. At first I
>> used \pos as well, but it only worked once per line for me, so I had to use
>> some kind of newline-positioning anyway, and using native vertical
>> alignment instead of \pos seemed nicer. (E.g. it allows the user to change
>> left/right alignment text margins more easily in the headers or by an
>> override).
>
>
> Okay I see. I'm rendering my subtitles with a background so the large
> half-empty bounding box looked strange to me.
>
>
>>
>>
>>
>>> It also looks like the "erase page" command is not being processed,
>>> which causes stale captions to stay on the screen in some cases.
>>> This is especially confusing when part of an old caption remains on one
>>> line, but then newer captions appear on another line.
>>>
>>> Here's a sample that shows lines not being cleared correctly:
>>> https://s3.amazonaws.com/tmm1/teletext/simple.mpg
>>>
>>>
>>> With this sample, for instance, my decoder produces:
>>>
>>> Dialogue: 
>>> 0,0:00:01.90,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and
>>> this, as you rightly say,\N
>>> Dialogue: 
>>> 0,0:00:01.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and
>>> this, as you rightly say,\N{\an8}{\pos(192,231)}{\c&}is
>>> American.\N
>>> Dialogue: 0,0:00:04.86,9:59:59.99,Default,,0,0,0,,
>>> Dialogue: 
>>> 0,0:00:04.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,231)}{\c&}It's
>>> rather nicely made.\N
>>> Dialogue: 0,0:00:06.62,9:59:59.99,Default,,0,0,0,,
>>> Dialogue: 
>>> 0,0:00:06.70,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's
>>> got this fabulous\N
>>> Dialogue: 
>>> 0,0:00:06.74,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's
>>> got this fabulous\N{\an8}{\pos(192,231)}   {\c&}cast finial
>>> here\N
>>> Dialogue: 0,0:00:10.34,9:59:59.99,Default,,0,0,0,,
>>> Dialogue: 
>>> 0,0:00:10.42,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of
>>> a very muscular figure\N
>>> Dialogue: 
>>> 0,0:00:10.46,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of
>>> a very muscular figure\N{\an8}{\pos(192,231)} {\c&}pulling this
>>> medallion.\N
>>> Dialogue: 0,0:00:15.50,9:59:59.99,Default,,0,0,0,,
>>> Dialogue: 
>>> 0,0:00:15.58,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}So
>>> it's got strength to it. It's a\N
>>> Dialogue: 0,0:00:15.62,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}
>>> {\c&}So it's got strength to it. It's 
>>> a\N{\an8}{\pos(192,231)}{\c&}really
>>> characterful piece of silver.\N
>>> Dialogue: 0,0:00:19.14,9:59:59.99,Default,,0,0,0,,
>>>
>>> And the decoder in this patch produces:
>>>
>>> Dialogue: 
>>> 0,0:00:02.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
>>> \Nis\hAmerican. \N
>>> Dialogue: 
>>> 0,0:00:05.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
>>> \NIt's\hrather\hnicely\hmade. \N
>>> Dialogue: 
>>> 0,0:00:06.82,9:59:59.99,Default,,0,0,0,,{\an2}It's\hgot\hthis\hfabulous
>>> \Ncast\hfinial\hhere \N
>>> Dialogue: 
>>> 0,0:00:10.54,9:59:59.99,Default,,0,0,0,,{\an2}of\ha\hvery\hmuscular\hfigure
>>> \Npulling\hthis\hmedallion. \N
>>> Dialogue: 
>>> 0,0:00:15.70,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
>>> \Nreally\hcharacterful\hpiece\hof\hsilver. \N
>>> Dialogue: 
>>> 0,0:00:19.30,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
>>> \NBut\hmost\himportant\hof\hall, \N
>>>
>>> At the ~5s mark, the text on the screen should say "It's rather nicely
>>> made", but this decoder still displays the line "and this as you rightly
>>> say" from the previous sentence.
>>>
>>
>> The mix of different subtitles showing up seems like a libzvbi bug :( ...
>> I will try to send a patch to sourceforge hoping it will get picked up and
>> integrated to a 

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/mpegts: keep track of AVProgram.pmt_version and set AV_PROGRAM_CHANGED on version updates

[Aman Gupta]

On Thu, May 17, 2018 at 3:49 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> This can be used to detect changes to the streams in an AVProgram
>

Forgot to add: I have seen two related patches in the wild that attempt to
solve this same problem in different ways.

The first is in MythTV's ffmpeg fork, where they added a void
(*streams_changed)(void*); to AVFormatContext and call it from their mpegts
demuxer when the PMT changes.

The second was proposed by XBMC in
https://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135036.html, where
they created a new AVMEDIA_TYPE_DATA stream with id=0 and attempted to send
packets to it whenever the PMT changed.

The approach in this patch is similar to what's used by
AVFormatContext.event_flags and AVFMT_EVENT_FLAG_METADATA_UPDATED.

I re-used AVProgram.flags for this purpose (which appears not to be used
for anything else). To be more explicit, it might be better to add
AVProgram.event_flags. Note that either way, the user would need to clear
AV_PROGRAM_CHANGED after detecting it (which should be documented).

Another possibility would be to remove AV_PROGRAM_CHANGED altogether, which
means the user would need to keep a copy of program->version and compare it
to detect changes.

Aman


>
> Signed-off-by: Aman Gupta 
> ---
>  libavformat/mpegts.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index fc9bb3940e..e83238d733 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -330,12 +330,24 @@ static void set_pmt_found(MpegTSContext *ts,
> unsigned int programid)
>  p->pmt_found = 1;
>  }
>
> -static void set_pcr_pid(AVFormatContext *s, unsigned int programid,
> unsigned int pid)
> +static void update_av_program_info(AVFormatContext *s, unsigned int
> programid,
> +   unsigned int pid, int version)
>  {
>  int i;
>  for (i = 0; i < s->nb_programs; i++) {
> -if (s->programs[i]->id == programid) {
> -s->programs[i]->pcr_pid = pid;
> +AVProgram *program = s->programs[i];
> +if (program->id == programid) {
> +int old_pcr_pid = program->pcr_pid,
> +old_version = program->pmt_version;
> +program->pcr_pid = pid;
> +program->pmt_version = version;
> +
> +if (old_version != -1 && old_version != version) {
> +program->flags |= AV_PROGRAM_CHANGED;
> +av_log(s, AV_LOG_DEBUG,
> +   "detected PMT change on program %d (version=%d/%d,
> pcr_pid=0x%x/0x%x)\n",
> +   programid, old_version, version, old_pcr_pid, pid);
> +}
>  break;
>  }
>  }
> @@ -2036,7 +2048,7 @@ static void pmt_cb(MpegTSFilter *filter, const
> uint8_t *section, int section_len
>  return;
>  pcr_pid &= 0x1fff;
>  add_pid_to_pmt(ts, h->id, pcr_pid);
> -set_pcr_pid(ts->stream, h->id, pcr_pid);
> +update_av_program_info(ts->stream, h->id, pcr_pid, h->version);
>
>  av_log(ts->stream, AV_LOG_TRACE, "pcr_pid=0x%x\n", pcr_pid);
>
> --
> 2.14.2
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add declick and declip audio filters

[James Almer]

On 5/17/2018 2:19 PM, Paul B Mahol wrote:
> +static int config_input(AVFilterLink *inlink)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +DeclickContext *s = ctx->priv;
> +int i;
> +
> +s->pts = AV_NOPTS_VALUE;
> +s->window_size = inlink->sample_rate * s->w / 1000.;
> +if (s->window_size < 100)
> +return AVERROR(EINVAL);
> +s->ar_order = FFMAX(s->window_size * s->ar / 100., 1);
> +s->nb_burst_samples = s->window_size * s->burst / 1000.;
> +s->hop_size = s->window_size * (1. - (s->overlap / 100.));
> +if (s->hop_size < 1)
> +return AVERROR(EINVAL);
> +
> +s->fifo = av_audio_fifo_alloc(inlink->format, inlink->channels, 
> s->window_size);
> +if (!s->fifo)
> +return AVERROR(ENOMEM);
> +
> +s->window_func_lut = av_realloc_f(s->window_func_lut, s->window_size,
> +  sizeof(*s->window_func_lut));

av_malloc_array()
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] avformat: keep track of PMT details in AVStream

[Aman Gupta]

From: Aman Gupta 

With these fields, the user has enough information
to make the same decisions externally that the demuxer
does internally when merge_pmt_versions=1.

An API user would monitor the AVProgram they're interested in
to see if (flags_PROGRAM_CHANGED), and would then iterate over
the program's streams to find ones where the version matched.

If new versions of any streams exist, then the user would first try
to replace existing streams where stream_identifier was the same.
If stream_identifier is unknown, then the user would compare
pmt_stream_idx instead to replace the stream that was previously
at the same position within the PMT.

Signed-off-by: Aman Gupta 
---
 doc/APIchanges |  1 +
 libavformat/avformat.h |  7 +++
 libavformat/mpegts.c   | 11 ++-
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index bca2e7485e..0bc056482e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -19,6 +19,7 @@ API changes, most recent first:
   Remove unused AV_PROGRAM_RUNNING
   Add AV_PROGRAM_CHANGED
   Add pmt_version field to AVProgram
+  Add program_num, pmt_version, pmt_stream_idx to AVStream
 
 2018-05-xx - xx - lavf 58.14.100 - avformat.h
   Add AV_DISPOSITION_STILL_IMAGE
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 91285f34f8..3f7060b98a 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1103,6 +1103,13 @@ typedef struct AVStream {
  */
 int stream_identifier;
 
+/**
+ * Details of the MPEG-TS program which created this stream.
+ */
+int program_num;
+int pmt_version;
+int pmt_stream_idx;
+
 int64_t interleaver_chunk_size;
 int64_t interleaver_chunk_duration;
 
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 287d7954a9..776c435ece 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2162,7 +2162,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 set_pmt_found(ts, h->id);
 
 
-for (;;) {
+for (i = 0; ; i++) {
 st = 0;
 pes = NULL;
 stream_type = get8(, p_end);
@@ -2193,6 +2193,9 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 if (!pes->st)
 goto out;
 pes->st->id = pes->pid;
+pes->st->program_num = h->id;
+pes->st->pmt_version = h->version;
+pes->st->pmt_stream_idx = i;
 }
 st = pes->st;
 } else if (is_pes_stream(stream_type, prog_reg_desc)) {
@@ -2211,6 +2214,9 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 if (!st)
 goto out;
 st->id = pes->pid;
+st->program_num = h->id;
+st->pmt_version = h->version;
+st->pmt_stream_idx = i;
 }
 } else {
 int idx = ff_find_stream_index(ts->stream, pid);
@@ -2225,6 +2231,9 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 if (!st)
 goto out;
 st->id = pid;
+st->program_num = h->id;
+st->pmt_version = h->version;
+st->pmt_stream_idx = i;
 st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
 if (stream_type == 0x86 && prog_reg_desc == AV_RL32("CUEI")) {
 mpegts_find_stream_type(st, stream_type, SCTE_types);
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option

[Aman Gupta]

On Thu, May 17, 2018 at 5:04 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> Some filtered mpegts streams may erroneously include PMTs for programs
> that are not advertised in the PAT. This confuses ffmpeg and most
> players because multiple audio/video streams are created and it is
> unclear which ones actually contain data.
>
> See for example https://tmm1.s3.amazonaws.com/unknown-pmts.ts
>
> Before:
>
> Input #0, mpegts, from 'unknown-pmts.ts':
>   Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s
>   Program 4
> Stream #0:2[0x41]: Video: mpeg2video (Main) ([2][0][0][0] /
> 0x0002), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9],
> Closed Captions, 11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
> Stream #0:3[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz,
> 5.1(side), fltp, 384 kb/s
> Stream #0:4[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz,
> stereo, fltp, 128 kb/s
>   No Program
> Stream #0:0[0x31]: Video: mpeg2video ([2][0][0][0] / 0x0002),
> none(tv), 90k tbr, 90k tbn, 90k tbc
> Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 0
> channels, fltp
> Stream #0:5[0x51]: Video: mpeg2video ([2][0][0][0] / 0x0002),
> none, 90k tbr, 90k tbn
> Stream #0:6[0x54](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels
>
> With skip_unknown_pmt=1:
>
> Input #0, mpegts, from 'unknown-pmts.ts':
>   Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s
>   Program 4
> Stream #0:0[0x41]: Video: mpeg2video (Main) ([2][0][0][0] /
> 0x0002), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9],
> Closed Captions, 11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
> Stream #0:1[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz,
> 5.1(side), fltp, 384 kb/s
> Stream #0:2[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz,
> stereo, fltp, 128 kb/s
>
> Signed-off-by: Aman Gupta 
> ---
>  doc/demuxers.texi| 3 +++
>  libavformat/mpegts.c | 5 +
>  2 files changed, 8 insertions(+)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index e7c2abce57..1d2ee5bf37 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -538,6 +538,9 @@ This demuxer accepts the following options:
>  Set size limit for looking up a new synchronization. Default value is
>  65536.
>
> +@item skip_unknown_pmt
> +Skip PMTs for programs not defined in the PAT. Default value is 0.
>

Maybe it's worth turning this option on by default?

We could also add debug/verbose logging when these PMTs are skipped,
but since it would happen every time the PMT is received it could become
very noisy.

Aman


> +
>  @item fix_teletext_pts
>  Override teletext packet PTS and DTS values with the timestamps calculated
>  from the PCR of the first program which the teletext stream is part of
> and is
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index fc9bb3940e..18df1afd9d 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -143,6 +143,7 @@ struct MpegTSContext {
>
>  int skip_changes;
>  int skip_clear;
> +int skip_unknown_pmt;
>
>  int scan_all_pmts;
>
> @@ -172,6 +173,8 @@ static const AVOption options[] = {
>   {.i64 = 0}, 0, 0, AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_EXPORT |
> AV_OPT_FLAG_READONLY },
>  {"scan_all_pmts", "scan and combine all PMTs",
> offsetof(MpegTSContext, scan_all_pmts), AV_OPT_TYPE_BOOL,
>   {.i64 = -1}, -1, 1, AV_OPT_FLAG_DECODING_PARAM },
> +{"skip_unknown_pmt", "skip PMTs for programs not advertised in the
> PAT", offsetof(MpegTSContext, skip_unknown_pmt), AV_OPT_TYPE_BOOL,
> + {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM },
>  {"skip_changes", "skip changing / adding streams / programs",
> offsetof(MpegTSContext, skip_changes), AV_OPT_TYPE_BOOL,
>   {.i64 = 0}, 0, 1, 0 },
>  {"skip_clear", "skip clearing programs", offsetof(MpegTSContext,
> skip_clear), AV_OPT_TYPE_BOOL,
> @@ -2028,6 +2031,8 @@ static void pmt_cb(MpegTSFilter *filter, const
> uint8_t *section, int section_len
>  if (!ts->scan_all_pmts && ts->skip_changes)
>  return;
>
> +if (ts->skip_unknown_pmt && !get_program(ts, h->id))
> +return;
>  if (!ts->skip_clear)
>  clear_program(ts, h->id);
>
> --
> 2.14.2
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mpegts: add skip_unknown_pmt option

[Aman Gupta]

From: Aman Gupta 

Some filtered mpegts streams may erroneously include PMTs for programs
that are not advertised in the PAT. This confuses ffmpeg and most
players because multiple audio/video streams are created and it is
unclear which ones actually contain data.

See for example https://tmm1.s3.amazonaws.com/unknown-pmts.ts

Before:

Input #0, mpegts, from 'unknown-pmts.ts':
  Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s
  Program 4
Stream #0:2[0x41]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), 
yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 
11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
Stream #0:3[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
5.1(side), fltp, 384 kb/s
Stream #0:4[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
stereo, fltp, 128 kb/s
  No Program
Stream #0:0[0x31]: Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv), 
90k tbr, 90k tbn, 90k tbc
Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp
Stream #0:5[0x51]: Video: mpeg2video ([2][0][0][0] / 0x0002), none, 90k 
tbr, 90k tbn
Stream #0:6[0x54](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels

With skip_unknown_pmt=1:

Input #0, mpegts, from 'unknown-pmts.ts':
  Duration: 00:00:10.11, start: 80741.189700, bitrate: 9655 kb/s
  Program 4
Stream #0:0[0x41]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), 
yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 
11063 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
Stream #0:1[0x44](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
5.1(side), fltp, 384 kb/s
Stream #0:2[0x45](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 
stereo, fltp, 128 kb/s

Signed-off-by: Aman Gupta 
---
 doc/demuxers.texi| 3 +++
 libavformat/mpegts.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e7c2abce57..1d2ee5bf37 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -538,6 +538,9 @@ This demuxer accepts the following options:
 Set size limit for looking up a new synchronization. Default value is
 65536.
 
+@item skip_unknown_pmt
+Skip PMTs for programs not defined in the PAT. Default value is 0.
+
 @item fix_teletext_pts
 Override teletext packet PTS and DTS values with the timestamps calculated
 from the PCR of the first program which the teletext stream is part of and is
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index fc9bb3940e..18df1afd9d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -143,6 +143,7 @@ struct MpegTSContext {
 
 int skip_changes;
 int skip_clear;
+int skip_unknown_pmt;
 
 int scan_all_pmts;
 
@@ -172,6 +173,8 @@ static const AVOption options[] = {
  {.i64 = 0}, 0, 0, AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_EXPORT | 
AV_OPT_FLAG_READONLY },
 {"scan_all_pmts", "scan and combine all PMTs", offsetof(MpegTSContext, 
scan_all_pmts), AV_OPT_TYPE_BOOL,
  {.i64 = -1}, -1, 1, AV_OPT_FLAG_DECODING_PARAM },
+{"skip_unknown_pmt", "skip PMTs for programs not advertised in the PAT", 
offsetof(MpegTSContext, skip_unknown_pmt), AV_OPT_TYPE_BOOL,
+ {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM },
 {"skip_changes", "skip changing / adding streams / programs", 
offsetof(MpegTSContext, skip_changes), AV_OPT_TYPE_BOOL,
  {.i64 = 0}, 0, 1, 0 },
 {"skip_clear", "skip clearing programs", offsetof(MpegTSContext, 
skip_clear), AV_OPT_TYPE_BOOL,
@@ -2028,6 +2031,8 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 if (!ts->scan_all_pmts && ts->skip_changes)
 return;
 
+if (ts->skip_unknown_pmt && !get_program(ts, h->id))
+return;
 if (!ts->skip_clear)
 clear_program(ts, h->id);
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] avcodec/ac3dec: Use frame_size if superframe_size is 0

[Michael Niedermayer]

Fixes: Infinite loop
Fixes: 
7669/clusterfuzz-testcase-ffmpeg_AV_CODEC_ID_AC3_FIXED_fuzzer-4689042185650176
Fixes: 7670/clusterfuzz-testcase-ffmpeg_AV_CODEC_ID_AC3_fuzzer-4706306762997760
Fixes: 7672/clusterfuzz-testcase-ffmpeg_AV_CODEC_ID_EAC3_fuzzer-4702108499574784

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

diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index b14d2e74ac..1d3180b935 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1800,6 +1800,9 @@ dependent_frame:
 
 *got_frame_ptr = 1;
 
+if (!s->superframe_size)
+return FFMIN(full_buf_size, s->frame_size);
+
 return FFMIN(full_buf_size, s->superframe_size);
 }
 
-- 
2.17.0

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

[FFmpeg-devel] [PATCH v3 1/3] avformat: update AVProgram to keep track of version and changes

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 doc/APIchanges | 5 +
 libavformat/avformat.h | 3 ++-
 libavformat/utils.c| 1 +
 libavformat/version.h  | 2 +-
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index befa58c84a..bca2e7485e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-05-xx - xx - lavf 58.15.100 - avformat.h
+  Remove unused AV_PROGRAM_RUNNING
+  Add AV_PROGRAM_CHANGED
+  Add pmt_version field to AVProgram
+
 2018-05-xx - xx - lavf 58.14.100 - avformat.h
   Add AV_DISPOSITION_STILL_IMAGE
 
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6dce88fad5..91285f34f8 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1241,7 +1241,7 @@ struct AVCodecParserContext *av_stream_get_parser(const 
AVStream *s);
  */
 int64_tav_stream_get_end_pts(const AVStream *st);
 
-#define AV_PROGRAM_RUNNING 1
+#define AV_PROGRAM_CHANGED 1
 
 /**
  * New fields can be added to the end with minor version bumps.
@@ -1260,6 +1260,7 @@ typedef struct AVProgram {
 int program_num;
 int pmt_pid;
 int pcr_pid;
+int pmt_version;
 
 /*
  * All fields below this line are not part of the public API. They
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 636fae3779..a4aa4e10b1 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4569,6 +4569,7 @@ AVProgram *av_new_program(AVFormatContext *ac, int id)
 return NULL;
 dynarray_add(>programs, >nb_programs, program);
 program->discard = AVDISCARD_NONE;
+program->pmt_version = -1;
 }
 program->id = id;
 program->pts_wrap_reference = AV_NOPTS_VALUE;
diff --git a/libavformat/version.h b/libavformat/version.h
index e9b94cc216..c8e89cdce1 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  14
+#define LIBAVFORMAT_VERSION_MINOR  15
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v3 2/3] avformat/mpegts: keep track of AVProgram.pmt_version and set AV_PROGRAM_CHANGED on version updates

[Aman Gupta]

From: Aman Gupta 

This can be used to detect changes to the streams in an AVProgram

Signed-off-by: Aman Gupta 
---
 libavformat/mpegts.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index fc9bb3940e..e83238d733 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -330,12 +330,24 @@ static void set_pmt_found(MpegTSContext *ts, unsigned int 
programid)
 p->pmt_found = 1;
 }
 
-static void set_pcr_pid(AVFormatContext *s, unsigned int programid, unsigned 
int pid)
+static void update_av_program_info(AVFormatContext *s, unsigned int programid,
+   unsigned int pid, int version)
 {
 int i;
 for (i = 0; i < s->nb_programs; i++) {
-if (s->programs[i]->id == programid) {
-s->programs[i]->pcr_pid = pid;
+AVProgram *program = s->programs[i];
+if (program->id == programid) {
+int old_pcr_pid = program->pcr_pid,
+old_version = program->pmt_version;
+program->pcr_pid = pid;
+program->pmt_version = version;
+
+if (old_version != -1 && old_version != version) {
+program->flags |= AV_PROGRAM_CHANGED;
+av_log(s, AV_LOG_DEBUG,
+   "detected PMT change on program %d (version=%d/%d, 
pcr_pid=0x%x/0x%x)\n",
+   programid, old_version, version, old_pcr_pid, pid);
+}
 break;
 }
 }
@@ -2036,7 +2048,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 return;
 pcr_pid &= 0x1fff;
 add_pid_to_pmt(ts, h->id, pcr_pid);
-set_pcr_pid(ts->stream, h->id, pcr_pid);
+update_av_program_info(ts->stream, h->id, pcr_pid, h->version);
 
 av_log(ts->stream, AV_LOG_TRACE, "pcr_pid=0x%x\n", pcr_pid);
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v3 3/3] avformat/mpegts: add merge_pmt_versions option

[Aman Gupta]

From: Aman Gupta 

This new optional flag makes it easier to deal with mpegts
samples where the PMT is updated and elementary streams move
to different PIDs in the middle of playback.

Previously, new AVStreams were created per PID, and it was up
to the user to figure out which streams had migrated to a new PID
(by iterating over the list of AVProgram and making guesses), and
switch seamlessly to the new AVStream during playback.

Transcoding or remuxing these streams with ffmpeg on the CLI was
also quite painful, and the user would need to extract each set of
PIDs into a separate file and then stitch them back together.

With this new option, the mpegts demuxer will automatically detect
PMT changes and feed data from the new PID to the original AVStream
that was created for the orignal PID. For mpegts samples with
stream_identifier_descriptor available, the unique ID is used to merge
PIDs together. If the stream id is not available, the demuxer attempts
to map PIDs based on their order and relation to the PCR pid.

With this change, I am able to playback and transcode/remux these
two samples which previously caused issues:

https://tmm1.s3.amazonaws.com/pmt-version-change.ts
https://kuroko.fushizen.eu/videos/pid_switch_sample.ts

I also have another longer sample which contains multiple PMT
changes, some of which change the ES pids and others which do not:

https://tmm1.s3.amazonaws.com/multiple-pmt-change.ts

Demuxing this sample with the new option shows several new log
messages as the PMT changes are handled:

[mpegts @ 0x7ffe18801200] detected PMT change (version=3/4, 
pcr_pid=0xf98/0xf9b)
[mpegts @ 0x7ffe18801200] re-using existing video stream 0 (pid=0xf98) for 
new pid=0xf9b
[mpegts @ 0x7ffe18801200] re-using existing audio stream 1 (pid=0xf99) for 
new pid=0xf9c
[mpegts @ 0x7ffe18801200] re-using existing audio stream 2 (pid=0xf9a) for 
new pid=0xf9d
[mpegts @ 0x7ffe18801200] detected PMT change (version=4/5, 
pcr_pid=0xf9b/0xfa9)
[mpegts @ 0x7ffe18801200] re-using existing video stream 0 (pid=0xf98) for 
new pid=0xfa9
[mpegts @ 0x7ffe18801200] re-using existing audio stream 1 (pid=0xf99) for 
new pid=0xfaa
[mpegts @ 0x7ffe18801200] re-using existing audio stream 2 (pid=0xf9a) for 
new pid=0xfab

Signed-off-by: Aman Gupta 
---
 doc/demuxers.texi |  4 ++
 libavformat/mpegts.c  | 99 +--
 tests/fate/mpegts.mak |  5 ++
 tests/ref/fate/mpegts-probe-pmt-merge | 32 +++
 4 files changed, 137 insertions(+), 3 deletions(-)
 create mode 100644 tests/ref/fate/mpegts-probe-pmt-merge

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e7c2abce57..2f7d7e0f3a 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -552,6 +552,10 @@ Show the detected raw packet size, cannot be set by the 
user.
 Scan and combine all PMTs. The value is an integer with value from -1
 to 1 (-1 means automatic setting, 1 means enabled, 0 means
 disabled). Default value is -1.
+
+@item merge_pmt_versions
+Re-use existing streams when a PMT's version is updated and elementary
+streams move to different PIDs. Default value is 0.
 @end table
 
 @section mpjpeg
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index e83238d733..287d7954a9 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -84,6 +84,7 @@ typedef struct MpegTSSectionFilter {
 unsigned int end_of_section_reached : 1;
 SectionCallback *section_cb;
 void *opaque;
+int orig_pcr_pid; /* pmt specific */
 } MpegTSSectionFilter;
 
 struct MpegTSFilter {
@@ -147,6 +148,7 @@ struct MpegTSContext {
 int scan_all_pmts;
 
 int resync_size;
+int merge_pmt_versions;
 
 /**/
 /* private mpegts data */
@@ -172,6 +174,8 @@ static const AVOption options[] = {
  {.i64 = 0}, 0, 0, AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_EXPORT | 
AV_OPT_FLAG_READONLY },
 {"scan_all_pmts", "scan and combine all PMTs", offsetof(MpegTSContext, 
scan_all_pmts), AV_OPT_TYPE_BOOL,
  {.i64 = -1}, -1, 1, AV_OPT_FLAG_DECODING_PARAM },
+{"merge_pmt_versions", "re-use streams when PMT's version/pids change", 
offsetof(MpegTSContext, merge_pmt_versions), AV_OPT_TYPE_BOOL,
+ {.i64 = 0}, 0, 1,  AV_OPT_FLAG_DECODING_PARAM },
 {"skip_changes", "skip changing / adding streams / programs", 
offsetof(MpegTSContext, skip_changes), AV_OPT_TYPE_BOOL,
  {.i64 = 0}, 0, 1, 0 },
 {"skip_clear", "skip clearing programs", offsetof(MpegTSContext, 
skip_clear), AV_OPT_TYPE_BOOL,
@@ -1084,6 +1088,8 @@ static int mpegts_push_data(MpegTSFilter *filter,
 if (!pes->st) {
 if (ts->skip_changes)
 goto skip;
+if (ts->merge_pmt_versions)
+goto skip; /* wait for PMT to merge new stream */
 
 pes->st = 

[FFmpeg-devel] [PATCH v2] avcodec/videotoolbox: fix decoding of some hevc videos

[Aman Gupta]

From: Aman Gupta 

See https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts

This moves the hw_frames_ctx reference from the AVFrame to a new
VTHWFrame which now holds both the CVPixelBufferRef and the AVBuffer.

Previously we would set the hw_frames_context on the AVFrame directly,
but on some videos the HEVC decoder would copy and move frames around
to reorder them, and in the process could accidentally free the
hw_frames_ctx, such that it was NULL by the time videotoolbox_postproc_frame()
got called. This appears to be a bug specific to the HEVC decoder, but
after several days of debugging I was unable to figure out where
the memory management issue is occurring.

This patch works around the issue by assigning hw_frames_ctx only once
the AVFrame is about to returned to the user. Fixes playback of the
HEVC sample linked above on both macOS and iOS.

Signed-off-by: Aman Gupta 
---
 libavcodec/videotoolbox.c | 67 +--
 1 file changed, 35 insertions(+), 32 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index fe5c9004b4..ac45e23c16 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -46,10 +46,16 @@ enum { kCMVideoCodecType_HEVC = 'hvc1' };
 
 #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
 
+typedef struct VTHWFrame {
+CVPixelBufferRef pixbuf;
+AVBufferRef *hw_frames_ctx;
+} VTHWFrame;
+
 static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
 {
-CVPixelBufferRef cv_buffer = *(CVPixelBufferRef *)data;
-CVPixelBufferRelease(cv_buffer);
+VTHWFrame *ref = (VTHWFrame *)data;
+av_buffer_unref(>hw_frames_ctx);
+CVPixelBufferRelease(ref->pixbuf);
 
 av_free(data);
 }
@@ -76,22 +82,29 @@ static int videotoolbox_buffer_copy(VTContext *vtctx,
 
 static int videotoolbox_postproc_frame(void *avctx, AVFrame *frame)
 {
-CVPixelBufferRef ref = *(CVPixelBufferRef *)frame->buf[0]->data;
+VTHWFrame *ref = (VTHWFrame *)frame->buf[0]->data;
 
-if (!ref) {
+if (!ref->pixbuf) {
 av_log(avctx, AV_LOG_ERROR, "No frame decoded?\n");
 av_frame_unref(frame);
 return AVERROR_EXTERNAL;
 }
 
-frame->data[3] = (uint8_t*)ref;
+frame->data[3] = (uint8_t*)ref->pixbuf;
+
+if (ref->hw_frames_ctx) {
+av_buffer_unref(>hw_frames_ctx);
+frame->hw_frames_ctx = av_buffer_ref(ref->hw_frames_ctx);
+if (!frame->hw_frames_ctx)
+return AVERROR(ENOMEM);
+}
 
 return 0;
 }
 
 int ff_videotoolbox_alloc_frame(AVCodecContext *avctx, AVFrame *frame)
 {
-size_t  size = sizeof(CVPixelBufferRef);
+size_t  size = sizeof(VTHWFrame);
 uint8_t*data = NULL;
 AVBufferRef *buf = NULL;
 int ret = ff_attach_decode_data(frame);
@@ -318,26 +331,6 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
 return data;
 }
 
-static int videotoolbox_set_frame(AVCodecContext *avctx, AVFrame *frame)
-{
-VTContext *vtctx = avctx->internal->hwaccel_priv_data;
-if (!frame->buf[0] || frame->data[3]) {
-av_log(avctx, AV_LOG_ERROR, "videotoolbox: invalid state\n");
-av_frame_unref(frame);
-return AVERROR_EXTERNAL;
-}
-
-CVPixelBufferRef *ref = (CVPixelBufferRef *)frame->buf[0]->data;
-
-if (*ref)
-CVPixelBufferRelease(*ref);
-
-*ref = vtctx->frame;
-vtctx->frame = NULL;
-
-return 0;
-}
-
 int ff_videotoolbox_h264_start_frame(AVCodecContext *avctx,
  const uint8_t *buffer,
  uint32_t size)
@@ -446,11 +439,21 @@ static int videotoolbox_buffer_create(AVCodecContext 
*avctx, AVFrame *frame)
 int width = CVPixelBufferGetWidth(pixbuf);
 int height = CVPixelBufferGetHeight(pixbuf);
 AVHWFramesContext *cached_frames;
+VTHWFrame *ref;
 int ret;
 
-ret = videotoolbox_set_frame(avctx, frame);
-if (ret < 0)
-return ret;
+if (!frame->buf[0] || frame->data[3]) {
+av_log(avctx, AV_LOG_ERROR, "videotoolbox: invalid state\n");
+av_frame_unref(frame);
+return AVERROR_EXTERNAL;
+}
+
+ref = (VTHWFrame *)frame->buf[0]->data;
+
+if (ref->pixbuf)
+CVPixelBufferRelease(ref->pixbuf);
+ref->pixbuf = vtctx->frame;
+vtctx->frame = NULL;
 
 // Old API code path.
 if (!vtctx->cached_hw_frames_ctx)
@@ -482,9 +485,9 @@ static int videotoolbox_buffer_create(AVCodecContext 
*avctx, AVFrame *frame)
 vtctx->cached_hw_frames_ctx = hw_frames_ctx;
 }
 
-av_buffer_unref(>hw_frames_ctx);
-frame->hw_frames_ctx = av_buffer_ref(vtctx->cached_hw_frames_ctx);
-if (!frame->hw_frames_ctx)
+av_buffer_unref(>hw_frames_ctx);
+ref->hw_frames_ctx = av_buffer_ref(vtctx->cached_hw_frames_ctx);
+if (!ref->hw_frames_ctx)
 return AVERROR(ENOMEM);
 
 return 0;
-- 
2.14.2

___

Re: [FFmpeg-devel] [RFC] Proposal for improved remap filter

[Paul Holland]

I am sure there are multiple ways to achieve this.  My current idea is to
teach/enhance swscale to perform the basic logic for it.  In that sort of
design it would be able to reuse most of the existing, highly optimized
filtering functions - as well as all of its to, and from, planar format
conversion logic.  But I am also open to pursing other ideas if people
think that would be better than an swscale-based design.


On Thu, May 17, 2018 at 12:41 PM, Paul B Mahol  wrote:

> On 5/17/18, Paul Holland  wrote:
> > The general feature provided by the remap filter is important in a number
> > of use cases.  Lens distortion/correction is one that has been discussed
> > previously.  But it is also a key feature in processing video material
> > intended for Virtual Reality and 360 degree playback.  These workflows
> > employ non-linear reprojections of the frame in order to deliver video
> that
> > can be played back by VR-based (head mounted display) players.
> >
> > The current implementation of the remap filter isn't well suited for this
> > task primarily because it is missing high-quality filtering logic similar
> > to what is available in swscale.  I would like to propose that this be
> > addressed, and would like to either join or lead an effort to do so.
>
> What exactly need to be added/implemented for remap filter?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Proposal for improved remap filter

[Paul B Mahol]

On 5/17/18, Paul Holland  wrote:
> The general feature provided by the remap filter is important in a number
> of use cases.  Lens distortion/correction is one that has been discussed
> previously.  But it is also a key feature in processing video material
> intended for Virtual Reality and 360 degree playback.  These workflows
> employ non-linear reprojections of the frame in order to deliver video that
> can be played back by VR-based (head mounted display) players.
>
> The current implementation of the remap filter isn't well suited for this
> task primarily because it is missing high-quality filtering logic similar
> to what is available in swscale.  I would like to propose that this be
> addressed, and would like to either join or lead an effort to do so.

What exactly need to be added/implemented for remap filter?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [FFmpeg-devl][RFC] Proposal for improved remap filter

[Paul Holland]

The general feature provided by the remap filter is important in a number
of use cases.  Lens distortion/correction is one that has been discussed
previously.  But it is also a key feature in processing video material
intended for Virtual Reality and 360 degree playback.  These workflows
employ non-linear reprojections of the frame in order to deliver video that
can be played back by VR-based (head mounted display) players.

The current implementation of the remap filter isn't well suited for this
task primarily because it is missing high-quality filtering logic similar
to what is available in swscale.  I would like to propose that this be
addressed, and would like to either join or lead an effort to do so.

What thoughts do people have about this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC] Proposal for improved remap filter

[Paul Holland]

The general feature provided by the remap filter is important in a number
of use cases.  Lens distortion/correction is one that has been discussed
previously.  But it is also a key feature in processing video material
intended for Virtual Reality and 360 degree playback.  These workflows
employ non-linear reprojections of the frame in order to deliver video that
can be played back by VR-based (head mounted display) players.

The current implementation of the remap filter isn't well suited for this
task primarily because it is missing high-quality filtering logic similar
to what is available in swscale.  I would like to propose that this be
addressed, and would like to either join or lead an effort to do so.

What thoughts do people have about this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add declick and declip audio filters

[Moritz Barsnick]

On Thu, May 17, 2018 at 19:19:06 +0200, Paul B Mahol wrote:

Valuable filters. I had compiled your previous separate patches, but
didn't have any samples for testing.

> +Setting this to very high value increases impulsive noise removal but makes 
> whole
  ^ a very high ...   ^ 
the whole ...
> +processs much slower.
   ^ process

> +This controls the strength of impulse noise which is going to be removed.
 ^ impulsive ?

> +This controls between how much samples, which are detected as impulsive 
> noise,
> +any sample between 2 detected noise samples is considered also as noise 
> sample.

This sentence makes no sense, I think you may have dropped a line?
(BTW:
 - 2 -> two
 - is considered also -> is also considered)

> +autoregressive modeling.
  ^ nit: This is the US spelling, while you use non-US
spelling for e.g. "neighbour".

> +Any sample which absolute value is equal or higher of this value will be
... "the absolute value of which is equal or higher than this", or
... "whose absolute value is equal or higher than this"

> +detected as clipped and be replaced with interpolated value.
^ an interpolated...

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[grady player]

There are lots of developers that consume FFMPEG and have a vested interest in 
its development continuing smoothly... I count myself among them.
I dont think it would be hard to impanel a group (3-4) of reasonable and 
dispassionate people to officiate and moderate public communication.

As an observer it seems like some of the disagreements fall into a few 
categories.

1) Constructive criticism done in a way that could be interpreted as 
threatening or dismissive.

2) Legitimate disagreements about implementation (reuse side_data or add a 
field to a struct; etc).

3) Language that might be completely acceptable in another language or in 
verbal communication, but "Comes off wrong" in the context of a code review.

4) The least common is someone actually being intentionally malicious... this 
is much, much less common than it used to be.

Then there are complicating personality factors: 

Some people take criticism poorly, and take personal offense when no ill will 
is intended.
Core developers have been working together for a long time, and often times 
there is some stored up ill will.

with a spelled out code of conduct you get rules and transgressions of rules, 
and reprimands and ultimatums, etc... but the incentives don't work well with 
volunteers.
It seems like it would be more effective to have a body that can just 
communicate a community standard out of band of this list.

If a CoC needs to be in place in order to banish someone to a new email 
address... or to have process to strip committing privileges, so be it.

-- grady (uninformed spectator)



> On May 17, 2018, at 10:09 AM, Dave Rice  wrote:
> 
>> 
>> On May 17, 2018, at 10:22 AM, Clément Bœsch  wrote:
>> 
>> On Mon, May 14, 2018 at 05:50:25PM +0100, Derek Buitenhuis wrote:
>> [...]
>>>   1. Implement a formal CoC enforcement system. This has been mostly 
>>> copypasted
>>>  from VideoLAN's, and is meant as more of a blueprint. This will no 
>>> doubt
>>>  be controversial.
>> 
>> So as mentioned already in the thread, the main issue is having a
>> police/justice entity. I would say it needs to be separate from the
>> development team (to maintain a power separation). Since such profile
>> doesn't seem to be exactly common in the open source world, maybe we could
>> externalize it. Does such a service exist with reasonable prices? Could we
>> use our funds for this? I understand this may sound far-fetched, but who
>> knows.
> 
> CoC enforcement as a paid service sounds alarming. Though it might make sense 
> to consider people separate from the development team for the role. There are 
> likely many who would like to contribute to the FFmpeg project but not as a 
> developer who could consider such a role.
> 
>> If such solution is not viable, we could fallback on the voting committee
>> to elect/design a subgroup of itself (an odd number like 3 persons maybe?)
>> to hold this moderation task for a period of 3 or 6 months, maybe 1 year.
>> Then these members are automatically maintainer of the CoC for this period
>> of time, and decide what to do with it.
>> 
>> Just random thoughts, no hard opinion on it to be honest.
> 
> I like this suggestion for a small committee to be tasked and trusted with 
> such actions. I consider that it might be easier to find rough consensus in 
> scenario a than in scenario b.
> 
> a) the larger ffmpeg community finds consensus to appoint a CoC committee and 
> as needed the CoC committee finds consensus (as a small group) on how to 
> respond to concerns from the community and to implement the CoC.
> 
> b) the larger ffmpeg community finds consensus on how to implement the CoC 
> directly each time there’s a concern from the community.
> 
> Dave Rice
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add declick and declip audio filters

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  95 +++
 libavfilter/Makefile |   2 +
 libavfilter/af_declick.c | 699 +++
 libavfilter/allfilters.c |   2 +
 4 files changed, 798 insertions(+)
 create mode 100644 libavfilter/af_declick.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 7646efb918..7ba61135fd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2576,6 +2576,101 @@ Optional. It should have a value much less than 1 (e.g. 
0.05 or 0.02) and is
 used to prevent clipping.
 @end table
 
+@section declick
+Remove impulsive noise from input audio.
+
+Samples detected as impulsive noise are replaced by interpolated samples using
+autoregressive modeling.
+
+@table @option
+@item w
+Set window size, in milliseconds. Allowed range is from @code{10} to 
@code{100}.
+Default value is @code{55} milliseconds.
+This sets size of window which will be processed at once.
+
+@item o
+Set window overlap, in percentage of window size. Allowed range is from 
@code{50}
+to @code{95}. Default value is @code{75} percent.
+Setting this to very high value increases impulsive noise removal but makes 
whole
+processs much slower.
+
+@item a
+Set autoregression order, in percentage of window size. Allowed range is from
+@code{0} to @code{25}. Default value is @code{2} percent. This option also 
controls
+quality of interpolated samples using neighbour good samples.
+
+@item t
+Set threshold value. Allowed range is from @code{1} to @code{100}.
+Default value is @code{2}.
+This controls the strength of impulse noise which is going to be removed.
+
+@item b
+Set burst fusion, in percentage of window size. Allowed range is @code{0} to
+@code{40}. Default value is @code{10} percent.
+This controls between how much samples, which are detected as impulsive noise,
+any sample between 2 detected noise samples is considered also as noise sample.
+
+@item m
+Set overlap method.
+
+It accepts the following values:
+@table @option
+@item a
+Select overlap-add method. Clicks are best removed with this method.
+Even not interpolated samples are slightly changed with this method.
+
+@item s
+Select overlap-save method. Less effective method for impulsive noise 
reduction,
+but not interpolated samples remain unchanged.
+@end table
+
+Default value is @code{a}.
+@end table
+
+@section declip
+Remove clipped samples from input audio.
+
+Samples detected as clipped are replaced by interpolated samples using
+autoregressive modeling.
+
+@table @option
+@item w
+Set window size, in milliseconds. Allowed range is from @code{10} to 
@code{100}.
+Default value is @code{55} milliseconds.
+This sets size of window which will be processed at once.
+
+@item o
+Set window overlap, in percentage of window size. Allowed range is from 
@code{50}
+to @code{95}. Default value is @code{75} percent.
+
+@item a
+Set autoregression order, in percentage of window size. Allowed range is from
+@code{0} to @code{25}. Default value is @code{8} percent. This option also 
controls
+quality of interpolated samples using neighbour good samples.
+
+@item t
+Set threshold value. Allowed range is from @code{0.2} to @code{1.0}.
+Default value is @code{0.98}.
+Any sample which absolute value is equal or higher of this value will be
+detected as clipped and be replaced with interpolated value.
+
+@item m
+Set overlap method.
+
+It accepts the following values:
+@table @option
+@item a
+Select overlap-add method. Clips are best removed with this method.
+Even not interpolated samples are slightly changed with this method.
+
+@item s
+Select overlap-save method. Less effective method for clip reduction,
+but not interpolated samples remain unchanged.
+@end table
+
+Default value is @code{a}.
+@end table
+
 @section drmeter
 Measure audio dynamic range.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f83a2b30ee..4fa9164429 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -89,6 +89,8 @@ OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER)  += 
af_compensationdelay.o
 OBJS-$(CONFIG_CROSSFEED_FILTER)  += af_crossfeed.o
 OBJS-$(CONFIG_CRYSTALIZER_FILTER)+= af_crystalizer.o
 OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
+OBJS-$(CONFIG_DECLICK_FILTER)+= af_declick.o
+OBJS-$(CONFIG_DECLIP_FILTER) += af_declick.o
 OBJS-$(CONFIG_DRMETER_FILTER)+= af_drmeter.o
 OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
 OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o
diff --git a/libavfilter/af_declick.c b/libavfilter/af_declick.c
new file mode 100644
index 00..93ca42c975
--- /dev/null
+++ b/libavfilter/af_declick.c
@@ -0,0 +1,699 @@
+/*
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by 

Re: [FFmpeg-devel] [PATCH] add support for parsing pssh box

[Jacob Trimble]

On Wed, May 16, 2018 at 11:32 PM, Zewu Chen  wrote:
> Use structure AVEncryptionInitInfo to provide CENC initialization information
> for the application.
>
> Signed-off-by: Chen Zewu 
> ---
>  libavformat/isom.h |  1 +
>  libavformat/mov.c  | 64 
> ++
>  2 files changed, 65 insertions(+)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index fb36112..f0f5b2c 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -274,6 +274,7 @@ typedef struct MOVContext {
>  MOVFragmentIndex frag_index;
>  int atom_depth;
>  unsigned int aax_mode;  ///< 'aax' file has been detected
> +AVEncryptionInitInfo *cenc_init_info;
>  uint8_t file_key[20];
>  uint8_t file_iv[20];
>  void *activation_bytes;
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 1975011..f87f10b 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -6165,6 +6165,52 @@ static int mov_read_schm(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0;
>  }
>
> +static int mov_read_pssh(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +int i, err;
> +int64_t start_pos;
> +uint8_t version = 0;
> +uint32_t num_key_ids = 0;
> +uint32_t data_size = 0;
> +
> +if (c->fc->nb_streams < 1)
> +return AVERROR_INVALIDDATA;
> +
> +version = avio_r8(pb);
> +avio_skip(pb, 3); /* flags */
> +
> +start_pos = avio_tell(pb);
> +
> +avio_skip(pb, 16); /* system id */
> +
> +if (version > 0) {
> +num_key_ids = avio_rb32(pb);
> +avio_skip(pb, 16*num_key_ids); /* KIDs */
> +}
> +
> +data_size = avio_rb32(pb);
> +
> +if (c->cenc_init_info)
> +av_log(c->fc, AV_LOG_WARNING, "Duplicated PSSH atom\n");
> +av_free(c->cenc_init_info);
> +c->cenc_init_info = av_encryption_init_info_alloc(16, num_key_ids, 16, 
> data_size);
> +if (!c->cenc_init_info)
> +return AVERROR(ENOMEM);
> +
> +avio_seek(pb, start_pos, SEEK_SET);
> +avio_read(pb, c->cenc_init_info->system_id, 16);
> +
> +if (version > 0)
> +avio_skip(pb, 4); /*  kid_count */
> +for (i = 0; i < num_key_ids; i++)
> +avio_read(pb, c->cenc_init_info->key_ids[i], 16);
> +
> +avio_skip(pb, 4); /* data_size */
> +avio_read(pb, c->cenc_init_info->data, data_size);
> +
> +return err;
> +}
> +
>  static int mov_read_tenc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
>  AVStream *st;
> @@ -6507,6 +6553,7 @@ static const MOVParseTableEntry 
> mov_default_parse_table[] = {
>  { MKTAG('s','a','i','z'), mov_read_saiz },
>  { MKTAG('s','a','i','o'), mov_read_saio },
>  { MKTAG('s','c','h','m'), mov_read_schm },
> +{ MKTAG('p','s','s','h'), mov_read_pssh },
>  { MKTAG('s','c','h','i'), mov_read_default },
>  { MKTAG('t','e','n','c'), mov_read_tenc },
>  { MKTAG('d','f','L','a'), mov_read_dfla },
> @@ -6982,6 +7029,7 @@ static int mov_read_close(AVFormatContext *s)
>  }
>  av_freep(>frag_index.item);
>
> +av_freep(>cenc_init_info);
>  av_freep(>aes_decrypt);
>  av_freep(>chapter_tracks);
>
> @@ -7263,6 +7311,22 @@ static int mov_read_header(AVFormatContext *s)
>
>  ff_rfps_calculate(s);
>
> +if (mov->cenc_init_info) {
> +for (i = 0; i < s->nb_streams; i++) {
> +AVStream *st = s->streams[i];
> +uint8_t *info;
> +size_t info_size;
> +
> +info = 
> av_encryption_init_info_add_side_data(mov->cenc_init_info, _size);
> +if (!info)
> +return AVERROR(ENOMEM);
> +
> +err = av_stream_add_side_data(st, 
> AV_PKT_DATA_ENCRYPTION_INIT_INFO, info, info_size);
> +if (err < 0)
> +break;
> +}
> +}
> +
>  for (i = 0; i < s->nb_streams; i++) {
>  AVStream *st = s->streams[i];
>  MOVStreamContext *sc = st->priv_data;
> --
> 1.9.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

MP4 can have multiple PSSH boxes in it, so this would depend on
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/229665.html

I also have implemented this with multiple PSSH support as well as
exposing the AVEncryptionInfo, but I am waiting on that patch to be
merged.  I sent a first version that only supported one PSSH box in it
in January, with no movement on it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Dave Rice]

> On May 17, 2018, at 10:22 AM, Clément Bœsch  wrote:
> 
> On Mon, May 14, 2018 at 05:50:25PM +0100, Derek Buitenhuis wrote:
> [...]
>>1. Implement a formal CoC enforcement system. This has been mostly 
>> copypasted
>>   from VideoLAN's, and is meant as more of a blueprint. This will no 
>> doubt
>>   be controversial.
> 
> So as mentioned already in the thread, the main issue is having a
> police/justice entity. I would say it needs to be separate from the
> development team (to maintain a power separation). Since such profile
> doesn't seem to be exactly common in the open source world, maybe we could
> externalize it. Does such a service exist with reasonable prices? Could we
> use our funds for this? I understand this may sound far-fetched, but who
> knows.

CoC enforcement as a paid service sounds alarming. Though it might make sense 
to consider people separate from the development team for the role. There are 
likely many who would like to contribute to the FFmpeg project but not as a 
developer who could consider such a role.

> If such solution is not viable, we could fallback on the voting committee
> to elect/design a subgroup of itself (an odd number like 3 persons maybe?)
> to hold this moderation task for a period of 3 or 6 months, maybe 1 year.
> Then these members are automatically maintainer of the CoC for this period
> of time, and decide what to do with it.
> 
> Just random thoughts, no hard opinion on it to be honest.

I like this suggestion for a small committee to be tasked and trusted with such 
actions. I consider that it might be easier to find rough consensus in scenario 
a than in scenario b.

a) the larger ffmpeg community finds consensus to appoint a CoC committee and 
as needed the CoC committee finds consensus (as a small group) on how to 
respond to concerns from the community and to implement the CoC.

b) the larger ffmpeg community finds consensus on how to implement the CoC 
directly each time there’s a concern from the community.

Dave Rice

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Rostislav Pehlivanov]

On 17 May 2018 at 15:22, Clément Bœsch  wrote:

> On Mon, May 14, 2018 at 05:50:25PM +0100, Derek Buitenhuis wrote:
> [...]
> > 1. Implement a formal CoC enforcement system. This has been mostly
> copypasted
> >from VideoLAN's, and is meant as more of a blueprint. This will
> no doubt
> >be controversial.
>
> So as mentioned already in the thread, the main issue is having a
> police/justice entity. I would say it needs to be separate from the
> development team (to maintain a power separation). Since such profile
> doesn't seem to be exactly common in the open source world, maybe we could
> externalize it. Does such a service exist with reasonable prices? Could we
> use our funds for this? I understand this may sound far-fetched, but who
> knows.
>

This is utterly ridiculous.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Clément Bœsch]

On Mon, May 14, 2018 at 05:50:25PM +0100, Derek Buitenhuis wrote:
[...]
> 1. Implement a formal CoC enforcement system. This has been mostly 
> copypasted
>from VideoLAN's, and is meant as more of a blueprint. This will no 
> doubt
>be controversial.

So as mentioned already in the thread, the main issue is having a
police/justice entity. I would say it needs to be separate from the
development team (to maintain a power separation). Since such profile
doesn't seem to be exactly common in the open source world, maybe we could
externalize it. Does such a service exist with reasonable prices? Could we
use our funds for this? I understand this may sound far-fetched, but who
knows.

If such solution is not viable, we could fallback on the voting committee
to elect/design a subgroup of itself (an odd number like 3 persons maybe?)
to hold this moderation task for a period of 3 or 6 months, maybe 1 year.
Then these members are automatically maintainer of the CoC for this period
of time, and decide what to do with it.

Just random thoughts, no hard opinion on it to be honest.

Regards,

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Derek Buitenhuis]

On Thu, May 17, 2018 at 1:15 AM, Michael Niedermayer
 wrote:
> I have no magic bullet sadly, which is why i didnt reply.

Even lacking a solution, a public agreement that change is needed
is a start, isn't it?

> But if there is a consensus to enforce some CoC. Then it will be enforced.
> I think there is no such consensus though. And
> i dont (just) mean we lack consensus to kick people and close accounts,
> no not at all, it starts before that.

It is hard to get a consensus on handling abuse from members of
the community to are very prone to abuse, shockingly enough...

> Compare this to a case that has consensus. Like someone posting spam
> everyone will agree thats not ok or stay silent. Theres no lack
> of solutions and noone will need to write rules on how to deal with it.

[...]

> OTOH, when someone acts hostile. Most stay silent, someone might
> voice their opposition and chances are a few people will join
> either side depending on who they are better friends with.
> Now you have a problem and its difficult to handle with penalties,
> as there are 2 parties each beliving they are the good side and the other has
> done wrong.

It is not hard to enforce simple runs like VideoLAN has where, for
example, if you insult someone (call them names, etc.) you get
a 24h ban. It *does not matter who is right*. It's extremely clear
cut with such a ruleset. What is the objection to such a thing? That
we can't agree on or identify when someone is purposely insulting
someone? At the very least, in cases where it is extremely obvious
this occurs, something should happen, no? If I call someone a
jackass, is there really another way to interpret that, for example?

> I think people should try to interpret others statements in a friendly
> way. Always try to act friendly and respectful towards others and
> try to help resolve conflicts and misunderstanings when they occur.

This is an idealized world that doesn't reflect the current reality.
I would love it if this were true. It isn't.

> When 2 people fight dont join the fight on the side of ones friend
> but try to resolve / stop the issue between the people ...

[...]

> Also iam not sure you are aware of it, but you have IMO been quite
> good at defusing / helping when there where conflicts/hostilities
> between people. I think we need more people with this talent

I agree, though nobody is faultless, and a single person alone
can't be in charge of diffusing everything. If anything, it is not
fair to that person.

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

Re: [FFmpeg-devel] [PATCH] mov: Make sure PTS are both monotonically increasing, and unique

[Derek Buitenhuis]

On Tue, May 15, 2018 at 8:44 PM, Derek Buitenhuis
 wrote:
> We already did this for audio, but it should be done for video too.
> If we don't, seeking back to the start of the file, for example, can
> become quite broken, since the first N packets will have repeating
> and nonmonotonic PTS, yet they need to be decoded even if they are
> to be discarded.
>
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/mov.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Ping.

Is nobody outside Sasi able to review code in this part of
mov.c? That is slightly worrying to me.

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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: Check AVPacket->duration for being positive not just non zero

[Derek Buitenhuis]

On Thu, May 17, 2018 at 1:22 AM, Michael Niedermayer
 wrote:
> Some demuxers (mov, microdvd at least) set duration negative.
>
> Signed-off-by: Michael Niedermayer 
> ---
>  fftools/ffmpeg.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

The patch itself seems reasonable, though I am curious when
the mov demuxer produces negative durations. Is it due to edit
list applications / discard packets, or is it just read in directly
from the mov's sample duration box?

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Do not output duplicated frames on insufficient input

[Michael Niedermayer]

On Thu, May 17, 2018 at 12:22:01PM +0200, Hendrik Leppkes wrote:
> On Thu, May 17, 2018 at 11:49 AM, Michael Niedermayer
>  wrote:
> > On Wed, May 16, 2018 at 12:53:46AM +0200, Carl Eugen Hoyos wrote:
> >> 2018-05-16 0:29 GMT+02:00, Hendrik Leppkes :
> >>
> >> > It makes no real difference if its less efficient or whatever -
> >> > if a codec specification asks for this behavior, then our
> >> > decoders should act accordingly.
> >>
> >> I wonder where this suddenly comes from?
> >> (I was away from my mail client when a similar argument
> >> was used a few weeks ago and I forgot later.)
> >> Luckily, many of our codecs do smarter things
> >> than the specifications asks for...
> >>
> >> Do we have a specification for qtrle?
> >
> > Iam only aware of the one "we", that is more correctly mike melanson
> > wrote: https://multimedia.cx/qtrle.txt
> >
> > I think this invalidates the argument, so if i hear no objections then
> > ill apply this patch in a few days
> >
> 
> How does that invalidate the argument that you take a compressed CRF
> stream and suddenly decide to make VFR out of it?
> Because it does not.

We have always droped cloned fields and frames even where the specification
unquestionably wants something different, when this is inefficient

For example mpeg2 has its field and frame duplication information, we
update timestamps according to this information but never duplicate
fields/frames.

If we imagine an alterantive reality where we did clone then
the decoder would be 20% slower in cases where it differs maybe, and we
would output many progressive videos as interlaced which could not be 
displayed nicely that way on the majority of display devices.
So what we do for mpeg2 makes sense. And this too changes constant field
rate mpeg2 into vfr

now qtrle, is a niche codec, why should it be handled in a way that is
1. inefficient & slower
2. easier to mount a DOS attack against
3. inconsistent with the other decoders we have

?

Maybe i just dont understand your concern
Is it that theres some need in some application for something like regular
heartbeat frames ? 
If so this is a issue for most VFR and especially subtitles, changes to qtrle
wont really help or hurt this. It would require injecting regular frames
or a flag that for every decoder clones frames if nothing occured beyond a
threshold



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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] indeo4: Decode all or nothing of a band header.

[Michael Niedermayer]

This avoids inconsistent value combinations.
Alternatively it would be possible to add more checks and careful use of
temporary variables, but my try of this quickly seemed to become
a rather large change.
The disadvantage of this, is that the struct is copied back and forth.

Fixes: index 6 out of bounds for type 'const uint16_t [5][16]'
Fixes: 
6557/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO4_fuzzer-4787296550256640

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

diff --git a/libavcodec/indeo4.c b/libavcodec/indeo4.c
index a3562f6fd8..7dff9db877 100644
--- a/libavcodec/indeo4.c
+++ b/libavcodec/indeo4.c
@@ -260,12 +260,14 @@ static int decode_pic_hdr(IVI45DecContext *ctx, 
AVCodecContext *avctx)
  *  @param[in] avctx pointer to the AVCodecContext
  *  @returnresult code: 0 = OK, negative number = error
  */
-static int decode_band_hdr(IVI45DecContext *ctx, IVIBandDesc *band,
+static int decode_band_hdr(IVI45DecContext *ctx, IVIBandDesc *arg_band,
AVCodecContext *avctx)
 {
 int plane, band_num, indx, transform_id, scan_indx;
 int i;
 int quant_mat;
+IVIBandDesc temp_band, *band = _band;
+memcpy(_band, arg_band, sizeof(temp_band));
 
 plane= get_bits(>gb, 2);
 band_num = get_bits(>gb, 4);
@@ -395,10 +397,10 @@ static int decode_band_hdr(IVI45DecContext *ctx, 
IVIBandDesc *band,
 
 /* decode block huffman codebook */
 if (!get_bits1(>gb))
-band->blk_vlc.tab = ctx->blk_vlc.tab;
+arg_band->blk_vlc.tab = ctx->blk_vlc.tab;
 else
 if (ff_ivi_dec_huff_desc(>gb, 1, IVI_BLK_HUFF,
- >blk_vlc, avctx))
+ _band->blk_vlc, avctx))
 return AVERROR_INVALIDDATA;
 
 /* select appropriate rvmap table for this band */
@@ -439,6 +441,9 @@ static int decode_band_hdr(IVI45DecContext *ctx, 
IVIBandDesc *band,
 return AVERROR_INVALIDDATA;
 }
 
+band->blk_vlc = arg_band->blk_vlc;
+memcpy(arg_band, band, sizeof(*arg_band));
+
 return 0;
 }
 
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 2/2] avcodec/mlpdec: Only change noise_type if the related fields are valid

[Michael Niedermayer]

Fixes: inconsistency
Fixes:runtime error: index 8 out of bounds for type 'int32_t [8]'
Fixes: 
6686/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEHD_fuzzer-5191383498358784

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

diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
index 63ec3e64bd..8caa266b7e 100644
--- a/libavcodec/mlpdec.c
+++ b/libavcodec/mlpdec.c
@@ -479,7 +479,7 @@ static int read_restart_header(MLPDecodeContext *m, 
GetBitContext *gbp,
 uint8_t checksum;
 uint8_t lossless_check;
 int start_count = get_bits_count(gbp);
-int min_channel, max_channel, max_matrix_channel;
+int min_channel, max_channel, max_matrix_channel, noise_type;
 const int std_max_matrix_channel = m->avctx->codec_id == AV_CODEC_ID_MLP
  ? MAX_MATRIX_CHANNEL_MLP
  : MAX_MATRIX_CHANNEL_TRUEHD;
@@ -492,9 +492,9 @@ static int read_restart_header(MLPDecodeContext *m, 
GetBitContext *gbp,
 return AVERROR_INVALIDDATA;
 }
 
-s->noise_type = get_bits1(gbp);
+noise_type = get_bits1(gbp);
 
-if (m->avctx->codec_id == AV_CODEC_ID_MLP && s->noise_type) {
+if (m->avctx->codec_id == AV_CODEC_ID_MLP && noise_type) {
 av_log(m->avctx, AV_LOG_ERROR, "MLP must have 0x31ea sync word.\n");
 return AVERROR_INVALIDDATA;
 }
@@ -520,7 +520,7 @@ static int read_restart_header(MLPDecodeContext *m, 
GetBitContext *gbp,
 
 /* This should happen for TrueHD streams with >6 channels and MLP's noise
  * type. It is not yet known if this is allowed. */
-if (max_channel > MAX_MATRIX_CHANNEL_MLP && !s->noise_type) {
+if (max_channel > MAX_MATRIX_CHANNEL_MLP && !noise_type) {
 avpriv_request_sample(m->avctx,
   "%d channels (more than the "
   "maximum supported by the decoder)",
@@ -537,6 +537,7 @@ static int read_restart_header(MLPDecodeContext *m, 
GetBitContext *gbp,
 s->min_channel= min_channel;
 s->max_channel= max_channel;
 s->max_matrix_channel = max_matrix_channel;
+s->noise_type = noise_type;
 
 if (mlp_channel_layout_subset(m->avctx->request_channel_layout, s->mask) &&
 m->max_decoded_substream > substr) {
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] cmdutils - don't search for option 'default'

[Gyan Doshi]

On 5/17/2018 2:19 PM, Michael Niedermayer wrote:

On Wed, May 16, 2018 at 09:21:49PM +0530, Gyan Doshi wrote:





  cmdutils.c |2 --
  1 file changed, 2 deletions(-)
495ccaae10f8873dc5070858d11c0c3093ce92b4  
0001-cmdutils-don-t-search-for-option-default.patch
 From 20a0544d66b5b3b9ebc3e03049a134d13706bda9 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Wed, 16 May 2018 20:18:30 +0530
Subject: [PATCH] cmdutils - don't search for option 'default'

The option 'default' was removed in
af4b1c02acf6923489d30349c4813a0d73b2f114 - Dec 20 2012.
---
  fftools/cmdutils.c | 2 --
  1 file changed, 2 deletions(-)


breaks fate (alot of fate tests)


Can you identify some of these tests?


I ran FATE with a full build; only two feature libs linked - freetype 
and LAME.


Out of the 3636 tests ran, 16 failed; none of which look related to my 
patch.


For sake of completeness, these are the tests that failed.

concat-demuxer-extended-lavf-mxf.err
concat-demuxer-extended-lavf-mxf_d10.err
concat-demuxer-simple1-lavf-mxf.err
concat-demuxer-simple1-lavf-mxf_d10.err
concat-demuxer-simple2-lavf-ts.err
filter-metadata-avf-aphase-meter-out-of-phase.err
filter-metadata-cropdetect.err
filter-metadata-ebur128.err
filter-metadata-readvitc-def.err
filter-metadata-readvitc-thr.err
filter-metadata-scenedetect.err
filter-metadata-silencedetect.err
source.err
sub-cc-realtime.err
sub-cc-scte20.err
sub-cc.err

Of these, 10 failed (and have always failed) because of 
avformat_open_file errors. Since I'm running this in MSYS2,


'/ffmpeg/fate-suite/folder/samplefile'

gets translated to

'G:/Code/ffmpeg/fate-suite/folder/samplefile'

avformat_open_file is passed arg of 'G' and fails. This happens in 8 tests.

avformat_open_file complains in 2 others of not finding files even as 
the passed arg remain Unix-style mounted path. Both files exist and can 
be opened with


ffmpeg -i same-unquoted-path-spec

The 5 concat demuxer .err files are empty. Since this component opens 
files, I suspect it's the same issue.


fate-source fails because libavcodec/nellymoser.h is identified as not 
having 'standard inclusion guards'. False positive or does the ref need 
updating?


So, none of the failures look related to the patch.

Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters

[Hendrik Leppkes]

On Thu, May 17, 2018 at 8:08 AM, Xiang, Haihao  wrote:
> On Wed, 2018-05-16 at 11:27 +0200, Hendrik Leppkes wrote:
>> On Wed, May 16, 2018 at 10:49 AM, Xiang, Haihao 
>> wrote:
>> > On Wed, 2018-05-16 at 10:17 +0200, Hendrik Leppkes wrote:
>> > > On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang 
>> > > wrote:
>> > > > Signed-off-by: Haihao Xiang 
>> > > > ---
>> > > >  libavcodec/hevcdec.c | 5 +
>> > > >  1 file changed, 5 insertions(+)
>> > > >
>> > > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> > > > index c8877626d2..13d868bb4f 100644
>> > > > --- a/libavcodec/hevcdec.c
>> > > > +++ b/libavcodec/hevcdec.c
>> > > > @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext
>> > > > *avctx,
>> > > > const HEVCParamSets *ps,
>> > > >  avctx->colorspace  = AVCOL_SPC_UNSPECIFIED;
>> > > >  }
>> > > >
>> > > > +if (sps->vui.chroma_loc_info_present_flag)
>> > > > +avctx->chroma_sample_location = sps-
>> > > > > vui.chroma_sample_loc_type_top_field + 1;
>> > > >
>> > > > +else
>> > > > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
>> > > >
>> > >
>> > > This change is incomplete, refer to the patch I proposed earlier:
>> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html
>> > >
>> >
>> > Sorry I didn't see your proposal before. Per spec, once
>> > chroma_loc_info_present_flag is set, chroma_format_idc should be 1. I think
>> > it
>> > would be better to add some checks when parsing the sequence parameters.
>> >
>>
>> It makes no real difference because you still need the check to be
>> able to set the LEFT default value for  4:2:0 only.
>
> If chroma_sample_loc_type_top_field is set correctly when parsing SPS, we may
> set chroma_sample_loc_type_top_field + 1 for 4:2:0 below no matter the present
> flag
>
> if (sps->chroma_format_idc == 1)
> avctx->chroma_sample_location = sps->vui.chroma_sample_loc_type_top_field 
> +
> 1;
> else
> avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
>

The fields in the sps struct should reflect the bitstream,
interpretation should be left out of it.

Like mentioned above, you always need the same checks anyway, all you
do is move it into another place. It is IMHO much cleaner to keep the
interpretation of all those values in the export_stream_params
function, its not like its complex or anything, but it cleanly
seperates parsing and interpretation, and ensures the sps struct only
contains values directly read from the bitstream.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Do not output duplicated frames on insufficient input

[Carl Eugen Hoyos]

2018-05-17 12:22 GMT+02:00, Hendrik Leppkes :
> On Thu, May 17, 2018 at 11:49 AM, Michael Niedermayer
>  wrote:
>> On Wed, May 16, 2018 at 12:53:46AM +0200, Carl Eugen Hoyos wrote:
>>> 2018-05-16 0:29 GMT+02:00, Hendrik Leppkes :
>>>
>>> > It makes no real difference if its less efficient or whatever -
>>> > if a codec specification asks for this behavior, then our
>>> > decoders should act accordingly.
>>>
>>> I wonder where this suddenly comes from?
>>> (I was away from my mail client when a similar argument
>>> was used a few weeks ago and I forgot later.)
>>> Luckily, many of our codecs do smarter things
>>> than the specifications asks for...
>>>
>>> Do we have a specification for qtrle?
>>
>> Iam only aware of the one "we", that is more correctly mike
>> melanson wrote: https://multimedia.cx/qtrle.txt
>>
>> I think this invalidates the argument, so if i hear no objections
>> then ill apply this patch in a few days
>
> How does that invalidate the argument that you take a compressed
> CRF stream and suddenly decide to make VFR out of it?

Apart from the fact that your argument was that there is a
specification that we have to follow (an argument that should
be used very carefully imo), the argument that we should do
something less efficient instead of improving the efficiency
does not seem very strong to me.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/v210dec: Skip Canopus C210 extradata

[Carl Eugen Hoyos]

2018-05-10 22:50 GMT+02:00, Carl Eugen Hoyos :

> Peter Bubestinger provided a C210 file where every frame starts with
> 64 bytes of extradata (24 byte "INFO", 16 byte "RDRT", rest "FIEL").
> Piotr confirmed that the Canopus decoder accepts files without the
> extradata but consumes it if present.
> Attached patch fixes the file in question visually.

Patch applied, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Do not output duplicated frames on insufficient input

[Hendrik Leppkes]

On Thu, May 17, 2018 at 11:49 AM, Michael Niedermayer
 wrote:
> On Wed, May 16, 2018 at 12:53:46AM +0200, Carl Eugen Hoyos wrote:
>> 2018-05-16 0:29 GMT+02:00, Hendrik Leppkes :
>>
>> > It makes no real difference if its less efficient or whatever -
>> > if a codec specification asks for this behavior, then our
>> > decoders should act accordingly.
>>
>> I wonder where this suddenly comes from?
>> (I was away from my mail client when a similar argument
>> was used a few weeks ago and I forgot later.)
>> Luckily, many of our codecs do smarter things
>> than the specifications asks for...
>>
>> Do we have a specification for qtrle?
>
> Iam only aware of the one "we", that is more correctly mike melanson
> wrote: https://multimedia.cx/qtrle.txt
>
> I think this invalidates the argument, so if i hear no objections then
> ill apply this patch in a few days
>

How does that invalidate the argument that you take a compressed CRF
stream and suddenly decide to make VFR out of it?
Because it does not.

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

Re: [FFmpeg-devel] [PATCH] avutil/error: document av_err2str

[Tobias Rapp]

On 17.05.2018 11:24, Zhao Zhili wrote:

---
  libavutil/error.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavutil/error.h b/libavutil/error.h
index 71df4da..b357bfa 100644
--- a/libavutil/error.h
+++ b/libavutil/error.h
@@ -115,6 +115,9 @@ static inline char *av_make_error_string(char *errbuf, 
size_t errbuf_size, int e
  /**
   * Convenience macro, the return value should be used only directly in
   * function arguments but never stand-alone.
+ *
+ * @warning The macro uses compound literal which was introduced in C99. It may
+ *  not work in C++.
   */
  #define av_err2str(errnum) \
  av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0}, 
AV_ERROR_MAX_STRING_SIZE, errnum)



If not using the macro is enough to silence affected C++ compilers, I 
prefer this patch over the other one that hides the macro with ifdefs.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: tag as AVFMT_TS_DISCONT

[Timo Rothenpieler]

> I think I'm against this. HLS streams do not typically contain
> timestamp resets (even if they could). Otherwise you might as well add
> this flag to the Matroska demuxer. Besides, it would break some of my
> code, which uses this flag as a heuristic to detect mpeg-ts style
> non-container formats.

They do, a lot. For example sites insert ads in them which change pretty
much everything about the stream while they are running.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/error: hidden macro av_err2str for C++

[Timo Rothenpieler]

On 17.05.2018 06:46, Zhao Zhili wrote:
> ---
>  libavutil/error.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavutil/error.h b/libavutil/error.h
> index 71df4da..8a35fef 100644
> --- a/libavutil/error.h
> +++ b/libavutil/error.h
> @@ -116,8 +116,10 @@ static inline char *av_make_error_string(char *errbuf, 
> size_t errbuf_size, int e
>   * Convenience macro, the return value should be used only directly in
>   * function arguments but never stand-alone.
>   */
> +#ifndef __cplusplus
>  #define av_err2str(errnum) \
>  av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0}, 
> AV_ERROR_MAX_STRING_SIZE, errnum)
> +#endif

It's a macro, as long as you don't call it, it should never hit the
compiler.
So this will only change the error as now the macro won't be known anymore.



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Do not output duplicated frames on insufficient input

[Michael Niedermayer]

On Wed, May 16, 2018 at 12:53:46AM +0200, Carl Eugen Hoyos wrote:
> 2018-05-16 0:29 GMT+02:00, Hendrik Leppkes :
> 
> > It makes no real difference if its less efficient or whatever -
> > if a codec specification asks for this behavior, then our
> > decoders should act accordingly.
> 
> I wonder where this suddenly comes from?
> (I was away from my mail client when a similar argument
> was used a few weeks ago and I forgot later.)
> Luckily, many of our codecs do smarter things
> than the specifications asks for...
> 
> Do we have a specification for qtrle?

Iam only aware of the one "we", that is more correctly mike melanson
wrote: https://multimedia.cx/qtrle.txt

I think this invalidates the argument, so if i hear no objections then
ill apply this patch in a few days

thanks

[...]
-- 
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/error: document av_err2str

[Nicolas George]

Zhao Zhili (2018-05-17):
> ---
>  libavutil/error.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavutil/error.h b/libavutil/error.h
> index 71df4da..b357bfa 100644
> --- a/libavutil/error.h
> +++ b/libavutil/error.h
> @@ -115,6 +115,9 @@ static inline char *av_make_error_string(char *errbuf, 
> size_t errbuf_size, int e
>  /**
>   * Convenience macro, the return value should be used only directly in
>   * function arguments but never stand-alone.
> + *
> + * @warning The macro uses compound literal which was introduced in C99. It 
> may
> + *  not work in C++.
>   */
>  #define av_err2str(errnum) \
>  av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0}, 
> AV_ERROR_MAX_STRING_SIZE, errnum)

No objection from me.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avutil/error: document av_err2str

[Zhao Zhili]

---
 libavutil/error.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/error.h b/libavutil/error.h
index 71df4da..b357bfa 100644
--- a/libavutil/error.h
+++ b/libavutil/error.h
@@ -115,6 +115,9 @@ static inline char *av_make_error_string(char *errbuf, 
size_t errbuf_size, int e
 /**
  * Convenience macro, the return value should be used only directly in
  * function arguments but never stand-alone.
+ *
+ * @warning The macro uses compound literal which was introduced in C99. It may
+ *  not work in C++.
  */
 #define av_err2str(errnum) \
 av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0}, 
AV_ERROR_MAX_STRING_SIZE, errnum)
-- 
2.9.5



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

Re: [FFmpeg-devel] [PATCH] cmdutils - don't search for option 'default'

[Michael Niedermayer]

On Wed, May 16, 2018 at 09:21:49PM +0530, Gyan Doshi wrote:
> 

>  cmdutils.c |2 --
>  1 file changed, 2 deletions(-)
> 495ccaae10f8873dc5070858d11c0c3093ce92b4  
> 0001-cmdutils-don-t-search-for-option-default.patch
> From 20a0544d66b5b3b9ebc3e03049a134d13706bda9 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Wed, 16 May 2018 20:18:30 +0530
> Subject: [PATCH] cmdutils - don't search for option 'default'
> 
> The option 'default' was removed in
> af4b1c02acf6923489d30349c4813a0d73b2f114 - Dec 20 2012.
> ---
>  fftools/cmdutils.c | 2 --
>  1 file changed, 2 deletions(-)

breaks fate (alot of fate tests)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/error: hidden macro av_err2str for C++

[wm4]

On Thu, 17 May 2018 05:50:55 +0100
Rostislav Pehlivanov  wrote:

> On 17 May 2018 at 05:46, Zhao Zhili  wrote:
> 
> > ---
> >  libavutil/error.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavutil/error.h b/libavutil/error.h
> > index 71df4da..8a35fef 100644
> > --- a/libavutil/error.h
> > +++ b/libavutil/error.h
> > @@ -116,8 +116,10 @@ static inline char *av_make_error_string(char
> > *errbuf, size_t errbuf_size, int e
> >   * Convenience macro, the return value should be used only directly in
> >   * function arguments but never stand-alone.
> >   */
> > +#ifndef __cplusplus
> >  #define av_err2str(errnum) \
> >  av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
> > AV_ERROR_MAX_STRING_SIZE, errnum)
> > +#endif
> >
> >  /**
> >   * @}
> > --
> > 2.9.5
> >
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> NAK
> Chopping off parts of the API because it doesn't play well when included in
> a different language is not a good idea.
> Just do #undef av_make_error_string in your own code.

+1, I don't want a __cplusplus mess in the headers. We can document
them as C99 only, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] compound literal in public header file

[wm4]

On Thu, 17 May 2018 00:41:10 +0200
Carl Eugen Hoyos  wrote:

> 2018-05-16 11:47 GMT+02:00, Steinar H. Gunderson 
> :
> > On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:  
> >> Yes, I am referring to usage of the libavutil headers in C. If the macro
> >> is
> >> only hidden for C++ and available in C, that would be OK for me. But if
> >> the
> >> static inline function variant would support both C and C++, this would
> >> look
> >> like a solution where C++ users are not forced to implement a more
> >> "integrated" replacement but of course have the option to do so.  
> >
> > While we're at it, would it be possible to have extern "C" { for the
> > headers,
> > too? :-) (Wrapped in #ifdef __cplusplus, of course.)  
> 
> No, because it would give the users of the headers the impression
> that they are tested with c++ which - as you found out - they are not.

That's a pointless argument, because we definitely support C++ API
users, and any breakages are fixed immediately, or are prevented in
patch review in the first place. The presence of C only helper macros
changes nothing about this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vsrc_testsrc: add pal75bars and pal100bars video filter sources

[Tobias Rapp]

Generates color bar test patterns based on EBU PAL recommendations.

Signed-off-by: Tobias Rapp 
---
 Changelog|   1 +
 doc/filters.texi |  10 +++-
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   2 +
 libavfilter/version.h|   2 +-
 libavfilter/vsrc_testsrc.c   | 106 ++-
 tests/fate/filter-video.mak  |   6 +++
 tests/ref/fate/filter-pal100bars |  10 
 tests/ref/fate/filter-pal75bars  |  10 
 9 files changed, 146 insertions(+), 3 deletions(-)
 create mode 100644 tests/ref/fate/filter-pal100bars
 create mode 100644 tests/ref/fate/filter-pal75bars

diff --git a/Changelog b/Changelog
index c9f1200..562fbc4 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version :
 - amplify filter
 - fftdnoiz filter
 - aderivative and aintegral audio filters
+- pal75bars and pal100bars video filter sources
 
 
 version 4.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index 7646efb..cf15186 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17825,13 +17825,15 @@ ffplay -f lavfi 
life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#C83232:life_c
 @anchor{color}
 @anchor{haldclutsrc}
 @anchor{nullsrc}
+@anchor{pal75bars}
+@anchor{pal100bars}
 @anchor{rgbtestsrc}
 @anchor{smptebars}
 @anchor{smptehdbars}
 @anchor{testsrc}
 @anchor{testsrc2}
 @anchor{yuvtestsrc}
-@section allrgb, allyuv, color, haldclutsrc, nullsrc, rgbtestsrc, smptebars, 
smptehdbars, testsrc, testsrc2, yuvtestsrc
+@section allrgb, allyuv, color, haldclutsrc, nullsrc, pal75bars, pal100bars, 
rgbtestsrc, smptebars, smptehdbars, testsrc, testsrc2, yuvtestsrc
 
 The @code{allrgb} source returns frames of size 4096x4096 of all rgb colors.
 
@@ -17846,6 +17848,12 @@ The @code{nullsrc} source returns unprocessed video 
frames. It is
 mainly useful to be employed in analysis / debugging tools, or as the
 source for filters which ignore the input data.
 
+The @code{pal75bars} source generates a color bars pattern, based on
+EBU PAL recommendations with 75% color levels.
+
+The @code{pal100bars} source generates a color bars pattern, based on
+EBU PAL recommendations with 100% color levels.
+
 The @code{rgbtestsrc} source generates an RGB test pattern useful for
 detecting RGB vs BGR issues. You should see a red, green and blue
 stripe from top to bottom.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f83a2b3..c68ef05 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -390,6 +390,8 @@ OBJS-$(CONFIG_MANDELBROT_FILTER) += 
vsrc_mandelbrot.o
 OBJS-$(CONFIG_MPTESTSRC_FILTER)  += vsrc_mptestsrc.o
 OBJS-$(CONFIG_NULLSRC_FILTER)+= vsrc_testsrc.o
 OBJS-$(CONFIG_OPENCLSRC_FILTER)  += vf_program_opencl.o opencl.o
+OBJS-$(CONFIG_PAL75BARS_FILTER)  += vsrc_testsrc.o
+OBJS-$(CONFIG_PAL100BARS_FILTER) += vsrc_testsrc.o
 OBJS-$(CONFIG_RGBTESTSRC_FILTER) += vsrc_testsrc.o
 OBJS-$(CONFIG_SMPTEBARS_FILTER)  += vsrc_testsrc.o
 OBJS-$(CONFIG_SMPTEHDBARS_FILTER)+= vsrc_testsrc.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 099c191..b44093d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -380,6 +380,8 @@ extern AVFilter ff_vsrc_mandelbrot;
 extern AVFilter ff_vsrc_mptestsrc;
 extern AVFilter ff_vsrc_nullsrc;
 extern AVFilter ff_vsrc_openclsrc;
+extern AVFilter ff_vsrc_pal75bars;
+extern AVFilter ff_vsrc_pal100bars;
 extern AVFilter ff_vsrc_rgbtestsrc;
 extern AVFilter ff_vsrc_smptebars;
 extern AVFilter ff_vsrc_smptehdbars;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index b1c73be..c32afce 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVFILTER_VERSION_MAJOR   7
-#define LIBAVFILTER_VERSION_MINOR  23
+#define LIBAVFILTER_VERSION_MINOR  24
 #define LIBAVFILTER_VERSION_MICRO 100
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index a790974..8d76ae9 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -1252,7 +1252,7 @@ AVFilter ff_vsrc_yuvtestsrc = {
 
 #endif /* CONFIG_YUVTESTSRC_FILTER */
 
-#if CONFIG_SMPTEBARS_FILTER || CONFIG_SMPTEHDBARS_FILTER
+#if CONFIG_PAL75_FILTER || CONFIG_PAL100_FILTER || CONFIG_SMPTEBARS_FILTER || 
CONFIG_SMPTEHDBARS_FILTER
 
 static const uint8_t rainbow[7][4] = {
 { 180, 128, 128, 255 }, /* 75% white */
@@ -1264,6 +1264,16 @@ static const uint8_t rainbow[7][4] = {
 {  35, 212, 114, 255 }, /* 75% blue */
 };
 
+static const uint8_t rainbow100[7][4] = {
+{ 235, 128, 128, 255 }, /* 100% white */
+{ 210,  16, 146, 255 }, /* 100% yellow */
+{ 170, 166,  16, 255 }, /* 100% cyan */
+{ 145,  54,  34, 255 }, /* 100% green */
+{ 106, 202, 222, 255 }, 

[FFmpeg-devel] [PATCH] add support for parsing pssh box

[Zewu Chen]

Use structure AVEncryptionInitInfo to provide CENC initialization information
for the application.

Signed-off-by: Chen Zewu 
---
 libavformat/isom.h |  1 +
 libavformat/mov.c  | 64 ++
 2 files changed, 65 insertions(+)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index fb36112..f0f5b2c 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -274,6 +274,7 @@ typedef struct MOVContext {
 MOVFragmentIndex frag_index;
 int atom_depth;
 unsigned int aax_mode;  ///< 'aax' file has been detected
+AVEncryptionInitInfo *cenc_init_info;
 uint8_t file_key[20];
 uint8_t file_iv[20];
 void *activation_bytes;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1975011..f87f10b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6165,6 +6165,52 @@ static int mov_read_schm(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_pssh(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+int i, err;
+int64_t start_pos;
+uint8_t version = 0;
+uint32_t num_key_ids = 0;
+uint32_t data_size = 0;
+
+if (c->fc->nb_streams < 1)
+return AVERROR_INVALIDDATA;
+
+version = avio_r8(pb);
+avio_skip(pb, 3); /* flags */
+
+start_pos = avio_tell(pb);
+
+avio_skip(pb, 16); /* system id */
+
+if (version > 0) {
+num_key_ids = avio_rb32(pb);
+avio_skip(pb, 16*num_key_ids); /* KIDs */
+}
+
+data_size = avio_rb32(pb);
+
+if (c->cenc_init_info)
+av_log(c->fc, AV_LOG_WARNING, "Duplicated PSSH atom\n");
+av_free(c->cenc_init_info);
+c->cenc_init_info = av_encryption_init_info_alloc(16, num_key_ids, 16, 
data_size);
+if (!c->cenc_init_info)
+return AVERROR(ENOMEM);
+
+avio_seek(pb, start_pos, SEEK_SET);
+avio_read(pb, c->cenc_init_info->system_id, 16);
+
+if (version > 0)
+avio_skip(pb, 4); /*  kid_count */
+for (i = 0; i < num_key_ids; i++)
+avio_read(pb, c->cenc_init_info->key_ids[i], 16);
+
+avio_skip(pb, 4); /* data_size */
+avio_read(pb, c->cenc_init_info->data, data_size);
+
+return err;
+}
+
 static int mov_read_tenc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
@@ -6507,6 +6553,7 @@ static const MOVParseTableEntry mov_default_parse_table[] 
= {
 { MKTAG('s','a','i','z'), mov_read_saiz },
 { MKTAG('s','a','i','o'), mov_read_saio },
 { MKTAG('s','c','h','m'), mov_read_schm },
+{ MKTAG('p','s','s','h'), mov_read_pssh },
 { MKTAG('s','c','h','i'), mov_read_default },
 { MKTAG('t','e','n','c'), mov_read_tenc },
 { MKTAG('d','f','L','a'), mov_read_dfla },
@@ -6982,6 +7029,7 @@ static int mov_read_close(AVFormatContext *s)
 }
 av_freep(>frag_index.item);
 
+av_freep(>cenc_init_info);
 av_freep(>aes_decrypt);
 av_freep(>chapter_tracks);
 
@@ -7263,6 +7311,22 @@ static int mov_read_header(AVFormatContext *s)
 
 ff_rfps_calculate(s);
 
+if (mov->cenc_init_info) {
+for (i = 0; i < s->nb_streams; i++) {
+AVStream *st = s->streams[i];
+uint8_t *info;
+size_t info_size;
+
+info = av_encryption_init_info_add_side_data(mov->cenc_init_info, 
_size);
+if (!info)
+return AVERROR(ENOMEM);
+
+err = av_stream_add_side_data(st, 
AV_PKT_DATA_ENCRYPTION_INIT_INFO, info, info_size);
+if (err < 0)
+break;
+}
+}
+
 for (i = 0; i < s->nb_streams; i++) {
 AVStream *st = s->streams[i];
 MOVStreamContext *sc = st->priv_data;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 1/2] hevcdec: Miss the location of chroma samples when exporting stream parameters

[Xiang, Haihao]

On Wed, 2018-05-16 at 11:27 +0200, Hendrik Leppkes wrote:
> On Wed, May 16, 2018 at 10:49 AM, Xiang, Haihao 
> wrote:
> > On Wed, 2018-05-16 at 10:17 +0200, Hendrik Leppkes wrote:
> > > On Wed, May 16, 2018 at 9:19 AM, Haihao Xiang 
> > > wrote:
> > > > Signed-off-by: Haihao Xiang 
> > > > ---
> > > >  libavcodec/hevcdec.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > > > index c8877626d2..13d868bb4f 100644
> > > > --- a/libavcodec/hevcdec.c
> > > > +++ b/libavcodec/hevcdec.c
> > > > @@ -344,6 +344,11 @@ static void export_stream_params(AVCodecContext
> > > > *avctx,
> > > > const HEVCParamSets *ps,
> > > >  avctx->colorspace  = AVCOL_SPC_UNSPECIFIED;
> > > >  }
> > > > 
> > > > +if (sps->vui.chroma_loc_info_present_flag)
> > > > +avctx->chroma_sample_location = sps-
> > > > > vui.chroma_sample_loc_type_top_field + 1;
> > > > 
> > > > +else
> > > > +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> > > > 
> > > 
> > > This change is incomplete, refer to the patch I proposed earlier:
> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228100.html
> > > 
> > 
> > Sorry I didn't see your proposal before. Per spec, once
> > chroma_loc_info_present_flag is set, chroma_format_idc should be 1. I think
> > it
> > would be better to add some checks when parsing the sequence parameters.
> > 
> 
> It makes no real difference because you still need the check to be
> able to set the LEFT default value for  4:2:0 only.

If chroma_sample_loc_type_top_field is set correctly when parsing SPS, we may
set chroma_sample_loc_type_top_field + 1 for 4:2:0 below no matter the present
flag

if (sps->chroma_format_idc == 1)
avctx->chroma_sample_location = sps->vui.chroma_sample_loc_type_top_field +
1;
else
avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;  

Thanks
Haihao

> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel