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

Robert Krüger krueger at lesspain.de
Tue Oct 29 15:37:45 CET 2013


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


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xdcam.patch
Type: application/octet-stream
Size: 4317 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131029/e471b6bf/attachment.obj>

More information about the ffmpeg-devel mailing list