[FFmpeg-devel] [PATCH] Fix start_time in MKV Demuxer

Michael Niedermayer michaelni at gmx.at
Sun Dec 22 02:58:29 CET 2013


On Sat, Dec 21, 2013 at 01:57:33PM -0800, Alex Sukhanov wrote:
> On Sat, Dec 21, 2013 at 2:51 AM, Michael Niedermayer <michaelni at gmx.at>wrote:
> 
> > On Wed, Dec 18, 2013 at 06:47:10PM -0800, Alex Sukhanov wrote:
> > > Problem:
> > > MKV demuxer explicitly set previously start_time = 0. So in case if
> > first timestamp of video file > 0, update_initial_timestamps() located
> > inlibavformat/utils.c, didn't update start time.
> > >
> > > How to reproduce:
> > > $ffprobe chunk_00180.flv
> > > $ffprobe chunk_00180.mkv
> > >
> > > It's the same video but packed into FLV and MKV containers
> > >
> > > FLV: Duration: 00:02:30.54, start: 150.000000, bitrate: 50 kb/s
> > > MKV: Duration: 00:02:30.54, start: 0.000000, bitrate: 50 kb/s
> > >
> > > Fix:
> > > drop line in MKV demuxer which sets start_time = 0
> > >
> > > TESTED:
> > > FATE passed (I had to modify expectations of some tests)
> > [...]
> > > diff --git a/tests/ref/fate/vp9-parallelmode-akiyo
> > b/tests/ref/fate/vp9-parallelmode-akiyo
> > > index 9668c54..0591e2c 100644
> > > --- a/tests/ref/fate/vp9-parallelmode-akiyo
> > > +++ b/tests/ref/fate/vp9-parallelmode-akiyo
> > > @@ -10,21 +10,21 @@
> > >  0,          4,          4,        1,   152064,
> > 6719f3a6c22f05dc53dd3906e4154bd7
> > >  0,          5,          5,        1,   152064,
> > 8cd9a12761e35f67c278949cd3aee88f
> > >  0,          6,          6,        1,   152064,
> > 8cd9a12761e35f67c278949cd3aee88f
> > > -0,          7,          7,        1,   152064,
> > 0160dec415234d39f148e91f72d264ab
> > > -0,          8,          8,        1,   152064,
> > 9f90d96d67d9e9b3716abe2a3faa854e
> > > -0,          9,          9,        1,   152064,
> > 1edb312f9d0be7835b964a3ffa014759
> > > -0,         10,         10,        1,   152064,
> > 7614fd674609afccacd355aa2f714c75
> > > -0,         11,         11,        1,   152064,
> > cb46868706dd246878bebf354aff66f4
> > > -0,         12,         12,        1,   152064,
> > da36fe96cb4956036f890bb2f6d05b98
> > > -0,         13,         13,        1,   152064,
> > af0a178c68b719b369c8fa8537d38e65
> > > -0,         14,         14,        1,   152064,
> > ff03dbc436376fc60ac240cd6c4fc518
> > > -0,         15,         15,        1,   152064,
> > b0bf25e139556bd9067616db7e4f47b5
> > > -0,         16,         16,        1,   152064,
> > e70d5480c1f82fc877bbe1a8093f807a
> > > -0,         17,         17,        1,   152064,
> > 622fb43e6ff63834f0f680a68b49f6e6
> > > -0,         18,         18,        1,   152064,
> > c331ebba15f2290f174533dbffb3c27b
> > > -0,         19,         19,        1,   152064,
> > 15cb153425c55f7065fb36606c48972e
> > > -0,         20,         20,        1,   152064,
> > b95c7699639c51b08b3615ef7fa7046c
> > > -0,         21,         21,        1,   152064,
> > b4774148c71c9c184bda5a18294e459c
> > > -0,         22,         22,        1,   152064,
> > 795b7ce4c5e0dc343bd8f80ad6c1a454
> > > -0,         23,         23,        1,   152064,
> > 19163601b7b6138e2940cf28f6df6c7f
> > > -0,         24,         24,        1,   152064,
> > b9b388e0892c52df0680a30bfa954506
> > > +0,          7,          7,        1,   152064,
> > 32841e8b6916f1daea7ef1b980da1710
> > > +0,          8,          8,        1,   152064,
> > d959ebaa0f45cdf93caac47cb22621ff
> > > +0,          9,          9,        1,   152064,
> > 66f0368b106e9c32cca7fa328cca833f
> > > +0,         10,         10,        1,   152064,
> > 092ec763ee4fd5e160fd66891baa9f0f
> > > +0,         11,         11,        1,   152064,
> > 1b1f70815e3554088da4797fd7e044f2
> > > +0,         12,         12,        1,   152064,
> > 0754cf3a6eb98b585e302be006288064
> > > +0,         13,         13,        1,   152064,
> > 5692f89e7a8f9b03311a664c0dc212a8
> > > +0,         14,         14,        1,   152064,
> > 589de0dc2fdef4914f53e4be5900d2a8
> > > +0,         15,         15,        1,   152064,
> > 992476c60d387ce7717a627ce8d40edd
> > > +0,         16,         16,        1,   152064,
> > 72e4135ac776ed19ce2f07183bba34cb
> > > +0,         17,         17,        1,   152064,
> > c93d2e298b597f0d0e91f8960c1c4588
> > > +0,         18,         18,        1,   152064,
> > ff5bfc1fc0248d9f22fac3b2c3339f02
> > > +0,         19,         19,        1,   152064,
> > 2c2e80f377b58a5ae1887297830a0c50
> > > +0,         20,         20,        1,   152064,
> > fe7579b65f02835d12b7a75c7b8d9346
> > > +0,         21,         21,        1,   152064,
> > 68e21ff75484658a0728a61ea0379672
> > > +0,         22,         22,        1,   152064,
> > adf6224c4a110ce86f5d87d661bb86dd
> > > +0,         23,         23,        1,   152064,
> > 91d5ed4e2aa61c0ac2ff7989712459be
> > > +0,         24,         24,        1,   152064,
> > 37faefac606e73aea42f30a933e036de
> >
> > what is causing this change ?
> > has this been checked to be ok ? / correct ? / benign ?
> >
> > [...]
> > --
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > It is dangerous to be right in matters on which the established authorities
> > are wrong. -- Voltaire
> >
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> 
> Hi Michael,
> 
> 
> Let me briefly explain how we process input videos.
> We split input video on chunks, transcode them in parallel and then merge
> transcoded chunks back in result video.
> 
> As long as we keep original timestamps in these chunks, start time must be
> greater than zero for all chunks except first one. That's true for FLV, but
> not for MKV currently.
> In transcoder we use "-vsync 1" filter, which adds a lot of frames at the
> beginning in case of MKV, because  start_time = 0
> 
> You can reproduce problem by running following command line:
> 
> $ ffmpeg -i chunk_00180.flv -vsync 1 -vcodec libx264 -an -y flv.flv
> $ ffmpeg -i chunk_00180.mkv -vsync 1 -vcodec libx264 -an -y mkv.flv
> 
> you will see that mkv.flv file has a lot of frames at the beginning.
> 
> 
> I probably could fix this problem on our side: disable vsync 1 filter, or
> reset timestamps in splitter, but that would require a lot verification
> testing and I think that making FFmpeg consistent across different
> containers is good idea.
> 

> > has this been checked to be ok ? / correct ? / benign ?
> 
> I ran FATE, and played manually with some videos - they look good.
> Let me know please if you would like me to run any specific/additional
> tests.

yes, the checksums change in your patch, why do they change ?
I applied your patch locally now and i do not see this change for
vp9-parallelmode-akiyo
so if i would apply the patch it would break fate for me and if i
would apply it without the vp9-parallelmode-akiyo hunk it likely
would break fate for you, id assume.
Maybe you could double check that you really get this difference in
fate?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131222/93d11641/attachment.asc>


More information about the ffmpeg-devel mailing list