[mythtv-commits] Ticket #11924: lossless mpeg2 mythtranscode does not cut at frames specified by editor

MythTV noreply at mythtv.org
Sat Oct 26 18:26:02 UTC 2013


#11924: lossless mpeg2 mythtranscode does not cut  at frames specified by editor
-------------------------------------+-------------------------------------
     Reporter:  finlay@…             |      Owner:
         Type:  Bug Report -         |     Status:  new
  General                            |  Milestone:  unknown
     Priority:  minor                |    Version:  0.27-fixes
    Component:  MythTV -             |   Keywords:  mythtranscode lossless
  Mythtranscode                      |  cut
     Severity:  medium               |
Ticket locked:  0                    |
-------------------------------------+-------------------------------------
 mythtranscode lossless cut for mpeg2 files does not cut at the frames
 specified by the mythtv editor. I find when trying to cut at keyframes as
 specified by the mythtv editor that the mythtranscode cut is off by one
 frame which causes an additional I frame to be inserted. While trying to
 figure out why the losslessly cut videos couldn't be post-processed by
 mythffmpeg I noticed a discrepancy between the mythtv editor numbers for
 keyframes and the mythtranscode counts for keyframes. I think that the
 frame counts should be consistent between the mythtv editor and the
 mythtranscode lossless cut so that frame accurate cutting is possible. The
 problem seems to be with the handling of the B frames at the start of the
 video.

 From ticket [http://code.mythtv.org/trac/ticket/11213 11213] comments:

 '''Comment 7'''
 While manually running some lossless transcodes on US OTA video files
 (480i in mpegts) I noticed that even though I was setting the cut points
 on keyframes, mythtranscode was reporting that it was converting some B
 and P frames to I frames at the cut points. In addition it would report
 the need to insert a large number of frames (e.g.1000000+). By varying the
 cut frame specification I found that generally by specifying a frame one
 greater than the keyframe (as found by myth editing) I could get
 mythtranscode runs that would not convert frames. The resulting files
 could be analyzed by avconv and report the correct duration and could also
 be post-processed by mythffmpeg without a problem. Note this does not
 occur for all files that I have tried but does occur for the majority.

 My speculation is that:

     the myth editing process produces keyframe numbers that are different
 than the keyframe numbers that mythtranscode encounters; and,
     the mythtranscode conversion of B frames (and possible P frames) to I
 frames introduces some error that causes mythffmpeg, vlc and avconv to
 fail to correctly analyze the video.

 and:


 '''Comment 10'''
 Doing a little more investigation into the mpeg2fix.cpp code I see that
 mythtranscode uses a 0-based frame count as opposed to the myth editor's
 1-based frame count. This means that if the editor reports a keyframe
 count of 1000 then the mythtranscode count would be 999 for the same
 keyframe.

 In addition, mythtranscode rearranges the frames during processing into
 presentation order. When this occurs the count of frames includes the B
 frames to be displayed before the first I frame (mythffprobe ignores or
 drops these initial B frames but maybe the myth player shows these). This
 leads to the key frame cutpoint frame being seen as a B frame that needs
 to be converted into an I frame. Because the myth editor uses a 1-based
 count only one of the B frames is converted to an I frame to be included
 in the output. This is why setting the cutpoint to be one greater than the
 editor's keyframe number avoids doing any B frame conversions.

 For example if the frame packets are:

 I B B P B B P B B P B B I B B P ...
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 -- 0-based
 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 -- 1-based

 If the start cutpoint at 1 (0 in the 0-based) and the end cutpoint is at
 the myth editor 1-based count of 13 (0-based count of 12), when
 mythtranscode processes the file it rearranges the frames into
 presentation order:

 B B I B B P B B P B B P B B I B ...
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 -- 0-based
 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 -- 1-based

 So mythtranscode sees the end of the cut at 13 (0-based) which is the B
 frame just before the I frame. It then converts the two B frames (at 12
 and 13) before the I frame (at 14) but only includes the B frame (at 13)
 just before the I frame in the output. This is why if one is added to the
 editor keyframe count (i.e. 14 instead of 13) that the count actually ends
 up on the I frame and no B frame conversions are done.

 This doesn't explain why mythffmpeg and vlc often have a problem
 processing the resulting output file though it appears that the pts on the
 converted B frames are not consistent with the B frames pts that they were
 converted from.

--
Ticket URL: <http://code.mythtv.org/trac/ticket/11924>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list