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

[Robert Krüger]

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.