[FFmpeg-devel] [PATCH] avformat/matroskaenc: Write duration early during mkv_write_header (Rev #3)

[Soft Works]

> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> on behalf of Soft Works <softworkz at hotmail.com>
> Sent: Tuesday, July 19, 2016 3:33 AM
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH] avformat/matroskaenc: Write duration early during mkv_write_header (Rev #3)
> 
> From 7d6d6a7775fef707ea1e8e705acc3362f20b6b89 Mon Sep 17 00:00:00 2001
>  From: softworkz <softworkz at hotmail.com>
>  Date: Sun, 17 Jul 2016 04:19:41 +0200
>  Subject: [PATCH] avformat/matroskaenc: Write duration early during mkv_write_header (Rev #3)
> 
>  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 clie> nt (> 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 durati> ons > 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 o> r > 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 ca> lculation/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 writte> n > during write_header and this duration is taken from the streams' me> tadata, 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 th> is 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 c> ontext (AV> FormatContext::metadata). This would only exi> st > in case the user has explicitly specified a metadata DURATION value from the com> mand line.> 
>  Then it is iterating all streams > looking for a "DURATION" metadata (this works u> nless the > option "-map_metadata -1" has been specified) > and determines the maximum value.> 
>  The precendence is as follows: 1.>  Use durat> ion of AVFormatContext - 2. Use explicitly specified metadata duration value - 3. Use maximum (> mapped) metadata duration over al> l streams.> 
> 

Hi, 

I wanted to kindly ask if there are any objections regarding this patch and if I could/should do anything else to get this merged?

Thank you very much,

softworkz