[FFmpeg-devel] [PATCH] avformat/matroskaenc: Write duration early during mkv_write_header

Michael Niedermayer michael at niedermayer.cc
Mon Jul 18 12:49:32 EEST 2016

On Mon, Jul 18, 2016 at 12:34:50AM +0000, Soft Works wrote:
> 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 at hotmail.com>
> ---
>  libavformat/matroskaenc.c | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)

breaks fate

--- ./tests/ref/acodec/tta      2016-07-04 23:15:26.479386869 +0200
+++ tests/data/fate/acodec-tta  2016-07-18 10:14:49.127883093 +0200
@@ -1,4 +1,2 @@
-6c260836d7a32e4bd714453a3546c0d5 *tests/data/fate/acodec-tta.matroska
+16de7e9d2dd83d6513d0da698119733c *tests/data/fate/acodec-tta.matroska
 331148 tests/data/fate/acodec-tta.matroska
-95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-tta.out.wav
-stddev:    0.00 PSNR:999.99 MAXDIFF:    0 bytes:  1058400/  1058400
TEST    seek-acodec-adpcm-ima_wav
Test acodec-tta failed. Look at tests/data/fate/acodec-tta.err for details.
make: *** [fate-acodec-tta] Error 1
make: *** Waiting for unfinished jobs....


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160718/9dc797d1/attachment.sig>

More information about the ffmpeg-devel mailing list