[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