[FFmpeg-trac] #2573(avformat:reopened): Remuxed XDCAM mov does not play correctly in Quicktime player

[FFmpeg]

#2573: Remuxed XDCAM mov does not play correctly in Quicktime player
-------------------------------------+------------------------------------
             Reporter:  rmk          |                    Owner:
                 Type:  enhancement  |                   Status:  reopened
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mov          |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+------------------------------------

Comment (by rmk):

 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.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2573#comment:16>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker