[mythtv-commits] Ticket #11213: cutting and lossless mpeg2 transcoding generate strange files

[MythTV]

#11213: cutting and lossless mpeg2 transcoding generate strange files
------------------------------------+----------------------------
 Reporter:  mythtv@…                |          Owner:
     Type:  Bug Report - General    |         Status:  new
 Priority:  minor                   |      Milestone:  unknown
Component:  MythTV - Mythtranscode  |        Version:  0.26-fixes
 Severity:  medium                  |     Resolution:
 Keywords:                          |  Ticket locked:  0
------------------------------------+----------------------------

Comment (by finlay@…):

 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/11213#comment:10>
MythTV <http://www.mythtv.org>
MythTV Media Center