> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> on behalf of Soft Works > <softwo...@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 <softwo...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
