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 <softwo...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
