* commit 'f638b67e':
  h264: move the parameter set definitions to a new header file

Conflicts:
libavcodec/h264_parse.h
libavcodec/h264_ps.c
libavcodec/h264dec.h
Merged-by: James Almer <jamrial@gmail.com>

Suggested-by: BBB
Fixed-by: BBB
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The header is not installed and the macro isn't used outside libavutil,
so it is obviously privat to libavutil. Make the name reflect that.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The counter is now -1 if the code detect timer was never set,
and 0 if it was set but never expired.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Silences a few warnings.

The stereowiden filter uses a buffer, s->buffer[], and a pointer
within the buffer, s->write, to implement inter-channel delays.
The loop which applies the delayed samples turns out to be faulty.

   109      for (n = 0; n < in->nb_samples; n++, src += 2, dst += 2) {
   110          const float left = src[0], right = src[1];
   111          float *read = s->write + 2;
   112
   113          if (read > s->buffer + s->length)
   114              read = s->buffer;
   115
   116          dst[0] = drymix * left - crossfeed * right - feedback * read[1];
   117          dst[1] = drymix * right - crossfeed * left - feedback * read[0];
   118
   119          s->write[0] = left;
   120          s->write[1] = right;
   121
   122          if (s->write == s->buffer + s->length)
   123              s->write = s->buffer;
   124          else
   125              s->write += 2;
   126      }

For one, the buffer gets written past its end in lines 119-120, before
the bound check is done in lines 122-123.  This can be easily confirmed
by valgrind.

==3544== Invalid read of size 4
==3544==    at 0x593B41: filter_frame (af_stereowiden.c:116)
==3544==  Address 0xb1b03c4 is 4 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid read of size 4
==3544==    at 0x593B66: filter_frame (af_stereowiden.c:117)
==3544==  Address 0xb1b03c0 is 0 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid write of size 4
==3544==    at 0x593B79: filter_frame (af_stereowiden.c:119)
==3544==  Address 0xb1b03c0 is 0 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid write of size 4
==3544==    at 0x593B7D: filter_frame (af_stereowiden.c:120)
==3544==  Address 0xb1b03c4 is 4 bytes after a block of size 7,680 alloc'd

Also, using two separate pointers, s->write and read = s->write + 2,
does not seem to be well thought out.  To apply the delay of s->buffer[],
it is enough to read the delayed samples at the current position within
the buffer, and then to store new samples at the same current position.
Thus the application of delayed samples can probably be best described
with a single pointer s->cur.

I also introduce a minor change to ensure that the size of s->buffer[]
is always a multiple of 2.  Since the delay parameter is a float, it is
otherwise possible to trick the code into allocating off-by-one buffer.

Also cleanup parens for the skip_to_timecode check.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Add an AVOption stats_version with a new header for V2 stats, which
specifies the stats log version and lists the fields that will be
present in the log (to ease parsing).

The primary motivation is to facilitate the addition of optional fields
to the log without breaking backwards compatibility, while making the
logs easier to parse.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit '4e2f6212':
  svq3: stop using H264Picture
Merged-by: Clément Bœsch <u@pkh.me>

* commit '251cbb44':
  h264: create a new header for common h264 definitions
Merged-by: Clément Bœsch <u@pkh.me>

* commit '9df889a5':
  h264: rename h264.[ch] to h264dec.[ch]
Merged-by: Clément Bœsch <u@pkh.me>

* commit 'f651c6a2':
  h264: factor out setting frame properties / side data
Merged-by: Clément Bœsch <u@pkh.me>

* commit '19446dc5':
  h264: drop unused NAL_FF_IGNORE
Merged-by: Clément Bœsch <u@pkh.me>

* commit 'bcd91f16':
  h264: move a per-field block from decode_slice_header() to field_start()
Merged-by: Clément Bœsch <u@pkh.me>

Most systems have this, so it isn't really a problem to include it
even if it's not used, but some do not have memory.h as it is
non-standard. Since it's unused just remove it anyway.

* commit '17e7c03e':
  h264: only allow ending a field/starting a new one before finish_setup()

This commit is a noop. According to Michael, after 8385e171 this commit
should not be necessary anymore.
Merged-by: Clément Bœsch <u@pkh.me>

Set the stream_id to 0xbd (private_stream_id_1). Tools seem to assume
that value, and this is consistent with MPEG TS specification (ITU-T
H.222.0 section 2.12.3).

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The original code assumes av_realloc() will free ptr if size is zero.
The assumes is incorrect now.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The Peak Extend feature could be enabled permanently or only
when needed. This is now reported.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Rev #2: Fixes doubled header writing, checked FATE running without errors
Rev #3: Fixed coding style

This commit addresses the following scenario:

we are using ffmpeg to transcode or remux mkv (or something else) to mkv. The result is being streamed on-the-fly to an HTML5 client (streaming starts while ffmpeg is still running). The problem here is that the client is unable to detect the duration because the duration is only written to the mkv at the end of the transcoding/remoxing process. In matroskaenc.c, the duration is only written during mkv_write_trailer but not during mkv_write_header.

The approach:

FFMPEG is currently putting quite some effort to estimate the durations of source streams, but in many cases the source stream durations are still left at 0 and these durations are nowhere mapped to or used for output streams. As much as I would have liked to deduct or estimate output durations based on input stream durations - I realized that this is a hard task (as Nicolas already mentioned in a previous conversation). It would involve changes to the duration calculation/estimation/deduction for input streams and propagating these durations to output streams or the output context in a correct way.
So I looked for a simple and small solution with better chances to get accepted. In webmdashenc.c I found that a duration is written during write_header and this duration is taken from the streams' metadata, so I decided for a similar approach.

And here's what it does:

At first it is checking the duration of the AVFormatContext. In typical cases this value is not set, but: It is set in cases where the user has specified a recording_time or an end_time via the -t or -to parameters.
Then it is looking for a DURATION metadata field in the metadata of the output context (AVFormatContext::metadata). This would only exist in case the user has explicitly specified a metadata DURATION value from the command line.
Then it is iterating all streams looking for a "DURATION" metadata (this works unless the option "-map_metadata -1" has been specified) and determines the maximum value.
The precendence is as follows: 1. Use duration of AVFormatContext - 2. Use explicitly specified metadata duration value - 3. Use maximum (mapped) metadata duration over all streams.

To test this:

1. With explicit recording time:
ffmpeg -i file:"src.mkv" -loglevel debug -t 01:38:36.000 -y "dest.mkv"

2. Take duration from metadata specified via command line parameters:
ffmpeg -i file:"src.mkv" -loglevel debug -map_metadata -1 -metadata Duration="01:14:33.00" -y "dest.mkv"

3. Take duration from mapped input metadata:
ffmpeg -i file:"src.mkv" -loglevel debug -y "dest.mkv"

Regression risk:

Very low IMO because it only affects the header while ffmpeg is still running. When ffmpeg completes the process, the duration is rewritten to the header with the usual value (same like without this commit).
Signed-off-by: SoftWorkz <softworkz@hotmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

HLS demuxer calls the subdemuxer avformat_find_stream_info() while
overriding the subdemuxer AVFMTCTX_NOHEADER flag by clearing it.
However, this prevents some streams in some MPEG TS streams from being
detected properly.

Simply removing the clearing of the flag would cause the inner
avformat_find_stream_info() call to take longer in some cases, without
a way to control it.

To fix the issue, do not clear the flag but propagate it to HLS demuxer.
To avoid the above-mentioned mandatory delay, the call to
avformat_find_stream_info() is dropped except in the HLS ID3 timestamped
case. The HLS demuxer user should be calling avformat_find_stream_info()
on the HLS demuxer if it wants to find the stream info.

The main streams are now created dynamically after read_header time if
the subdemuxer uses AVFMTCTX_NOHEADER (mpegts).

Subdemuxer avformat_find_stream_info() is still called for the HLS ID3
timestamped case as the HLS demuxer needs to know the packet durations
to properly interleave ID3 timestamped streams with MPEG TS streams on
sub-segment level.

Fixes ticket #4930.

Creation of main demuxer streams from subdemuxer streams is moved to
update_streams_from_subdemuxer() which can be called repeatedly.

There should be no functional changes.

This will be useful when the amount of streams per subdemuxer is not
known at hls_read_header time in a following commit.

This will avoid a large time difference between variants in the most
common case.