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.
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>
avformat/hls: Fix missing streams in some cases with MPEG TS
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.
avformat/hls: Fix regression with ranged media segments
Commit 81306fd4bdf ("hls: eliminate ffurl_* usage", merged in d0fc5de3a6)
changed the hls demuxer to use AVIOContext instead of URLContext for its
HTTP requests.
HLS demuxer uses the "offset" option of the http demuxer, requesting
the initial file offset for the I/O (http URLProtocol uses the "Range:"
HTTP header to try to accommodate that).
However, the code in libavformat/aviobuf.c seems to be doing its own
accounting for the current file offset (AVIOContext.pos), with the
assumption that the initial offset is always zero.
HLS demuxer does an explicit seek after open_url to account for cases
where the "offset" was not effective (due to the URL being a local file
or the HTTP server not obeying it), which should be a no-op in case the
file offset is already at that position.
However, since aviobuf.c code thinks the starting offset is 0, this
doesn't work properly.
This breaks retrieval of ranged media segments.
To fix the regression, just drop the seek call from the HLS demuxer when
the HTTP(S) protocol is used.
avformat/utils: Fix find_stream_info not considering the extradata it found
Commit 9200514ad8717c6 ("lavf: replace AVStream.codec with
AVStream.codecpar") merged in commit 6f69f7a8bf6a0d01 changed
avformat_find_stream_info() to put the extradata it got from
st->parser->parser->split() to st->internal->avctx instead of st->codec
(extradata in st->internal->avctx will be later copied to st->codecpar).
However, in the same function, the "is stream ready?" check was changed
to check for extradata in st->codecpar instead of st->codec, even
though st->codecpar is not yet updated at that point.
Extradata retrieved from split() is therefore not considered anymore,
and avformat_find_stream_info() will therefore needlessly continue
probing in some cases.
Fix that by checking for the extradata at st->internal->avctx where it
is actually put.
* commit '54dd9b1cdd9e54f1ee39ae25af0324f8aba2831b':
h264: set mb_aff_frame in frame_start()
h264: move the block starting a new field out of slice_header_parse()
Both commits are merged at the same time in order to prevent a
regression with Ticket #4440 (see 38660128).
lavc/ffjni: replace ff_jni_{attach,detach} with ff_jni_get_env
If a JNI environment is not already attached to the thread where the
MediaCodec calls are made the current implementation will attach /
detach an environment for each MediaCodec call wasting some CPU time.
ff_jni_get_env replaces ff_jni_{attach,detach} by permanently attaching
an environment (if it is not already the case) to the current thread.
The environment will be automatically detached at the thread destruction
using a pthread_key callback.
Saves around 5% of CPU time (out of 20%) while decoding a stream with
MediaCodec.
Ronald S. Bultje [Wed, 13 Jul 2016 16:37:21 +0000 (12:37 -0400)]
vp9: add 32x32 idct AVX2 implementation.
About 1.8x speedup compared to AVX version for full IDCT. Other
sub-IDCT scenarios also see speedups. Full --bench output for
idct_32x32_add_{bpp}_${subidct}_${opt} (50k cycles):
lavfi/curves: do not automatically insert points at x=0 and x=1
There is actually a need for the origin and end point not to be defined.
We can not automatically insert them with the y value of the first and
last point as it will influence the curves in a wrong way.
Mark Reid [Thu, 21 Jul 2016 01:15:38 +0000 (18:15 -0700)]
tests/fate/dnxhd: add dnxhr prefix tests
The data offset value in the prefix increases as the heights increases.
This test adds a tests for some common dnxhr heights.
can somebody add the following test footage to fate/dnxhd?
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x1536.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x1716.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x2048.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x2160.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x3212.dnxhr
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Chris Cunningham [Thu, 21 Jul 2016 19:01:45 +0000 (12:01 -0700)]
libavformat/matroskadec: fix unsigned overflow to improve seeking
When seeking a file where codec delay is greater than 0, the timecode
can become negative after offsetting by the codec delay. Failing to cast
to a signed int64 will cause the check against skip_to_timecode to evaluate
true for these negative values. This breaks the "skip_to" seek mechanism.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
mpeg4_unpack_bframes_bsf bitstream filters constructs
resulting packet using av_packet_from_data() function.
This function however modifies only buffer (data) and leaves
other fields untouched, so the content of other fields
of the output packet is undefined.
It is working with old BSF API, since old API filters
just data and the packet fields are copied in
av_apply_bitstream_filters from input packet.
This change fixes the behaviour for the new BSF API.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Steven Liu [Mon, 18 Jul 2016 12:05:35 +0000 (20:05 +0800)]
doc/muxers: add hls_flags option description
Signed-off-by: Steven Liu <liuqi@gosun.com> Reviewed-by: Moritz Barsnick <barsnick@gmx.net> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
projects / ffmpeg / log