[FFmpeg-devel] [PATCH] Fix muxing of XDCAM files

Michael Niedermayer michaelni at gmx.at
Tue Nov 5 17:33:11 CET 2013


On Mon, Nov 04, 2013 at 05:18:35PM +0100, Robert Krüger wrote:
> Ping
> 
> On Tue, Oct 29, 2013 at 3:37 PM, Robert Krüger <krueger at lesspain.de> wrote:
> > Hi,
> >
> > attached is a patch by a colleague of mine (Michael Luckey) to fix ticket #2573.
> >
> > Explanation of the patch:
> >
> > Changes in mov_write_edts
> >
> > The current implementation assumes, that a track is delayed by the cts
> > of the first decoded frame.
> > (frame.dts + frame.cts = frame.pts) and inserts an empty edit into the
> > edts atom if frame.cts > 0.
> >
> > In case of xdcam, the stream starts with two B-frames, the stream is
> > reordered and the first decoded frame, but not the track, will be
> > delayed by these 2 frames.
> >
> > So this assumption is certainly wrong in case of xdcam.
> >
> > For example, lets assume the track starts with IBBPBB in decoding
> > order, which results in BBIBBP in presentation order, we might have
> >
> > I dts = 0, cts = 2 -> pts = 2
> > P dts = 1, cts = -1 -> pts = 0
> > P dts = 2, cts = -1 -> pts = 1
> > P dts = 3, cts = 2 -> pts = 5
> > P dts = 4, cts = -1 -> pts = 3
> > P dts = 5, cts = -1 -> pts = 4
> >
> > the current implementation will insert an empty edit entry of the form
> >
> > 80, -1, 1
> >
> > which will result in an edit-list-aware player starting playback at
> > the frame with pts = 2. The track will be delayed by these 2 frames in
> > respect to the container start. (This likely will also result in
> > avsync issues?)
> >
> > Contrary to that, the patch searches for the smallest pts available in
> > the track. Only if this is > 0, an empty edit will be inserted and the
> > track delayed.
> >
> > With this patch applied, the problem in
> > http://ffmpeg.org/trac/ffmpeg/ticket/2573 seems to be fixed.
> >
> > Changes in mov_write_ctts
> >
> > But looking at the ctts atom, there seems to be a second problem, as
> > the computation does not take into account the decoding-presentation
> > delay introduced by the reordering (in this example 1 frame). Thus the
> > current implementation would issue a ctts atom of
> >
> > e.g.
> >
> > 1, 3 (pts = 3)
> > 2, 0 (pts = 1, pts = 2)
> > 1, 3 (pts = 6)
> >
> > instead of
> >
> > 1,2 (pts = 2)
> > 2,-1 (pts = 0, pts = 1)
> > 1,2 (pts = 5)
> >
> > resulting in pts of the first shown frame being 1 instead of 0. The
> > second part of the patch affecting mov_write_ctts tries to take this
> > into account.
> >
> > Given the limited experience with the mov muxer code, It is likely
> > that there are some oversights here. It does fix #2573 for our test
> > cases but it would be great if one of the mov maintainers could take a
> > look at this.

simple test with matrixbench
using encoding like: -i matrixbench_mpeg2.mpg  -use_editlist 0 -t 1 ref.mov
and decoding like: -i ref.mov  -f framecrc -

before patch:
Press [q] to stop, [?] for help
0,          2,          2,        1,   622080, 0x100c25a7
1,       3840,       3840,     1024,     4096, 0x93cfa605
1,       4864,       4864,     1024,     4096, 0x9644721c
0,          3,          3,        1,   622080, 0xd9512729
1,       5888,       5888,     1024,     4096, 0xa1400c33
1,       6912,       6912,     1024,     4096, 0x00000000
0,          4,          4,        1,   622080, 0xa7e318ea


after patch:
Press [q] to stop, [?] for help
0,          0,          0,        1,   622080, 0x100c25a7
0,          1,          1,        1,   622080, 0xd9512729
0,          2,          2,        1,   622080, 0xa7e318ea
1,       3840,       3840,     1024,     4096, 0x93cfa605
1,       4864,       4864,     1024,     4096, 0x9644721c
0,          3,          3,        1,   622080, 0xac28f743


without -editlist 0 both produce:
1,       1024,       1024,     1024,     4096, 0x93cfa605
0,          1,          1,        1,   622080, 0x100c25a7
1,       2048,       2048,     1024,     4096, 0x9644721c
1,       3072,       3072,     1024,     4096, 0xa1400c33
0,          2,          2,        1,   622080, 0xd9512729
1,       4096,       4096,     1024,     4096, 0x00000000

also cc-ing movenc maintainer, he might have more / better comments
on the patch


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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20131105/03a82943/attachment.asc>


More information about the ffmpeg-devel mailing list