Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#11924 closed Bug Report - General (fixed)

lossless mpeg2 mythtranscode does not cut at frames specified by editor

Reported by: finlay@… Owned by: Karl Dietz <dekarl@…>
Priority: minor Milestone: 0.28
Component: MythTV - Mythtranscode Version: 0.27-fixes
Severity: medium Keywords: mythtranscode lossless cut
Cc: Karl Egly Ticket locked: no


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 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.


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.

Change History (4)

comment:1 Changed 6 years ago by Karl Egly

Cc: Karl Egly added

comment:2 Changed 6 years ago by John Pilkington <J.Pilk@…>

I think this is relevant here, although it refers to files that have been cut and reformatted to MPEG2-PS by my mythDVBcut script, which uses Project-X, mplex and mythcommflag --rebuild.

I believe that in these files, scene changes occur at keyframes. That isn't what the editor displays. In v0.27-56-g29eab51 of 23 Oct, viewing a processed recording (UK, DVB-T, SD, originally MPEG2-TS)

Last old-scene frame number n First new-scene frame number n+1 Project-X vframe cut-in number n+2 Keyframe number identified by editor n+3

I see this consistently.

If stepping backwards by single frames in the editor, frames n+1 and n+2 sometimes appear interchanged. Not a problem; just a feature.

comment:3 Changed 5 years ago by Karl Dietz <dekarl@…>

Owner: set to Karl Dietz <dekarl@…>
Resolution: fixed
Status: newclosed

In b0f4371620c6a144ba91d0db57a1baa6d488476b/mythtv:

Convert cutlist from MythTV style to mpeg2fix style for lossless cut.

Mark the first/last frame to *keep* in the editor.

Reasoning being that you can jump to a keyframe in the cutlist editor
and place the mark there, resulting in no frames being reencoded
from P/B to I.

Fixes #11924

comment:4 Changed 5 years ago by Karl Egly

Milestone: unknown0.28
Note: See TracTickets for help on using tickets.