Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#11213 closed Patch - Bug Fix (fixed)

cutting and lossless mpeg2 transcoding generate strange files

Reported by: mythtv@… Owned by: John Finlay <finlay@…>
Priority: minor Milestone: 0.26.2
Component: MythTV - Mythtranscode Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Starting with the new 0.26 cutting and loss-less transcoding results into strange files.

Within mythfrontend a cutted and transcoded file starts without sound. After a view seconds there is a little image jumping and audioplayback starts also.

Checking the file with mplayer sound and image start at begin.

Demuxing the file with projectx reports a lot of errors ( > 500) and produce no useful result:

...
!> startPTS of GOP# 2904 is earlier than the end of last GOP.. (exp. 3532072137)
!> dropping GOP# 2904 @ orig.PTS 00:23:13.622 (125426049), errorcode: 10
...

Transcoding loss-less without cutting works fine.

Attachments (4)

projectx.log (39.2 KB) - added by anonymous 11 years ago.
mythtransform.log (5.2 KB) - added by mythtv@… 11 years ago.
mpeg2fix.cpp.patch20131027 (915 bytes) - added by finlay@… 10 years ago.
patch file for workaround fix for lost pts in converted B & P frames
mpeg2fix.cpp.patch20131031 (818 bytes) - added by finlay@… 10 years ago.
Patch to MPEG2fixup::BuildFrame? to restore original pts value

Download all attachments as: .zip

Change History (25)

Changed 11 years ago by anonymous

Attachment: projectx.log added

comment:1 Changed 11 years ago by J.Pilk@…

Project-X will do this if mpeg-ts file segments have been joined before transmission using inappropriate tools such as cat. I haven't found an simple workaround, but a second PX run started after the discontinuity will often yield a usable file that can be demuxed in sequence by PX and remuxed.

In the UK I have seen the PX problem in perhaps 10 recordings out of several thousand processed.

comment:2 Changed 11 years ago by mythtv@…

Understand, but I have to move much more than one GOP behind a bad encoding until PX will jump over/ignore it. Beside PX works perfect if the recording isn't cutted with mythtransform before. But PX isn't the issue here.

At least mythtransform will produce the inappropriate joins, if cutting is used!

Changed 11 years ago by mythtv@…

Attachment: mythtransform.log added

comment:3 Changed 11 years ago by Kaacz <kaa@…>

Strange. Worked transcode is broked and nobody fix it 11 months ?? No fix ? Is better downgrade to 0.25 ??

I have same problem after upgrade to ver. 0.26 before few months. MythTV is my DVBT recorder. Many years I use lossless transcode after cut. Then download PS mpeg to my pc, check/fix it in ProjectX and transcode to mkv via Handbrake. It is scripted for automation (all on Linux). Now it is broken !!! I am not able make sync correction in PX - file is bad.

I have two (big) files. In case of need i make new short record. Original uncutted TS without these strange errors in PX. Cuted movie is between 0:18:15 and 1:11:20

Video: PID: 0x0201(MPEG-2)
Audio: PID: 0x0211{cze}(#2)(Mpg1)
ok> PID 0x0201 has PES-ID 0xE0 (MPEG Video) (22372 #120) 
!> PID 0x0201 -> packet 204 @ pos. 38164 out of sequence (13/0) (shifting counter..) (~00:00:00.000)
!> PID 0x0201 -> packet 229 @ pos. 42864 out of sequence (9/2) (shifting counter..) (~00:00:00.000)
!> PID 0x0201 -> packet 252 @ pos. 47188 out of sequence (6/13) (shifting counter..) (~00:00:00.000)
ok> PID 0x0211 has PES-ID 0xC0 (MPEG Audio) (103776 #553) 
!> PID 0x0211 -> packet 576 @ pos. 108100 out of sequence (1/11) (shifting counter..) (~00:00:00.000)
-> video basics: 720*576 @ 25fps @ 0.7031 (16:9) @ 15000000 bps - vbv 112
-> starting export of video data @ GOP# 0
!> dropping useless B-Frames @ GOP# 0 / new Timecode 00:00:00.000
!> PID 0x0370 (res.) (443868 #2362) -> ignored
packs: 21433622 100% 4078591380

Second file is transcoded PS with error on each GOP as is reported in this bug.

-> Filetype is MPEG-2 PS/SS (PES Container)
-> found PES-ID 0xE0 (MPEG Video) @ 14
-> video basics: 720*576 @ 25fps @ 0.7031 (16:9) @ 15000000 bps - vbv 112
-> starting export of video data @ GOP# 0
-> found PES-ID 0xC1 (MPEG Audio) @ 57358
!> startPTS of GOP# 1 is earlier than the end of last GOP.. (exp. 946007288)
!> dropping GOP# 1 @ orig.PTS 00:00:00.292 (26368), errorcode: 34
!> Pics exp/cnt 8/7, inGOP PTS diff. 0ms, new Timecode 00:00:00.040
!> startPTS of GOP# 2 is earlier than the end of last GOP.. (exp. 946007288)
!> dropping GOP# 2 @ orig.PTS 00:00:00.612 (55168), errorcode: 10
!> Pics exp/cnt 15/15, inGOP PTS diff. 0ms, new Timecode 00:00:00.040
...

Transcoded file is reported by PX with strange times about video or/and audio. I am not able make sync correction in PX - file is bad.

Recorded TS files are one-big-file .. no segments. I have this problem with ~40-50% recordings from ~100 in week. From different DVBT multiplexes.

If i make remux-only in Avidemux as copy/copy to PS mpeg file .. all is ok, without errors. But in this case I lost PX sync-fix.

Please fix this - in ver. 0.26 broked - transcoding.

comment:4 Changed 11 years ago by Kaacz <kaa@…>

My previous example is simple cut: before & after. No cut inside movie.

comment:5 Changed 11 years ago by Raymond Wagner

With the upcoming release of 0.27, 0.26 is very nearly at end-of-life. Please retest this issue against 0.27 at the soonest convenience.

comment:6 Changed 10 years ago by finlay@…

I have the same problem in fixes/0.27 with lossless cuts using mythtranscode i.e. the audio won't start unless I seek forward or backward. I have other problems as well but this problem still exists within mythtv playback. The files where I see the most problems are US OTA mpeg2 HD file 1280x720 recorded from my local PBS station.

comment:7 Changed 10 years ago by finlay@…

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:8 Changed 10 years ago by John Pilkington <J.Pilk@…>

I think this ties in with what I see using http://www.mythtv.org/wiki/MythDVBcut

As I use it, with dvb-t SD recordings in the UK, the cutlist gives the frame number of the first or last keyframe showing wanted content. The byte-offset passed to Project-X is 1 packet after the first keyframe after a frame-marker that is set a few frames before the one from the cutlist.

Project-X reports that it is dropping useless B-frames and says that it has used a cut-in byte offset which is identical to that of the next keyframe.

Perhaps the logic here could be improved now, but it works pretty well.

This doesn't shed light on what mythtranscode is doing but it does perhaps suggest that there's still something not quite right about the link between counting keyframes by the display and the editor; and of course, in these recordings, they aren't always evenly spaced.

comment:9 Changed 10 years ago by finlay@…

Using the fixes/0.27 mythffprobe to check the original file and assuming that the frame count is 0-based I see that mythffprobe sees keyframes at a number one less than the cut points. I have been trying to use mythffmpeg to slice up the video file (using -f segment) and find that I have to specify cut point frame numbers one less than the myth cut point frame numbers in order to get mythffmpeg to slice the file at the desired keyframe. This suggests that mythffprobe and mythffmpeg have a consistent count of frames that is 0-based but this count is one less than the count that the myth editor is using. Does the myth editor use a 1-based frame count? I can't see why I have to add one to the cut point frame numbers for mythtranscode to not convert B and P frames.

comment:10 Changed 10 years ago 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.

comment:11 Changed 10 years ago by John Pilkington <J.Pilk@…>

I started a thread with a little more info about keyframe/framenumber/editor/display relationships, but it closed quickly. It wasn't directly related to mythtranscode. It had a link to this ticket; here's the one back:

http://www.gossamer-threads.com/lists/mythtv/users/555679#555679

comment:12 Changed 10 years ago by finlay@…

Looking at the output file from a lossless cut run it seems that the pts of frames converted from B and P frames was set to a value much different than the adjacent frames. The MPEG2fixup::ConvertToI() method loses the original B and P frame pts values during processing so I tried a hack which restores the original pts value and that seems to make all the frames in the output file have consistent pts values and also cures the problems I encountered when post-processing the output file with mythffmpeg.

I don't know if the root problem lies elsewhere but this seems to be a workaround for me. I've attached a patch file with the hack fix in it.

Changed 10 years ago by finlay@…

Attachment: mpeg2fix.cpp.patch20131027 added

patch file for workaround fix for lost pts in converted B & P frames

comment:13 Changed 10 years ago by finlay@…

The difference between the 0.25 mythtranscode and the 0.26 and 0.27 mythtranscode that causes the changes to the packet pts is in MPEG2fixup::BuildFrame? in change http://code.mythtv.org/trac/changeset/6c3653cd378aacef10b7706d8b7f71beae41274c/mythtv where a call to avcodec_encode_video is replaced by a call to avcodec_encode_video2. I guess that avcodec_encode_video2 zeros out the pts. I created a patch that restores the original pts value and that creates a cut file that is identical to the cut file created by 0.25 mythtranscode.

Changed 10 years ago by finlay@…

Attachment: mpeg2fix.cpp.patch20131031 added

Patch to MPEG2fixup::BuildFrame? to restore original pts value

comment:14 Changed 10 years ago by sphery

Type: Bug Report - GeneralPatch - Bug Fix

comment:15 Changed 10 years ago by Kaacz <kaa@…>

God save to finlay@… for last patch20131031. :) I was patch mythtranscode and it seem to be OK.

comment:16 Changed 10 years ago by John Finlay <finlay@…>

Owner: set to John Finlay <finlay@…>
Resolution: fixed
Status: newclosed

In 2a27e176275155a04498ecb8eac67dbd0164d080/mythtv:

Fix lossless transcode.

Following 6c3653cd378aacef10b7706d8b7f71beae41274c, lossless mythtranscode got broken.

This is just a quick workaround, the whole code needs to be revisited and properly use FFmpeg API

Fixes #11213

Signed-off-by: Jean-Yves Avenard <jyavenard@…>

comment:17 Changed 10 years ago by finlay@…

How can this patch make its way into existing releases e.g. fixes/0.26 and/or fixes/0.27?

comment:18 Changed 10 years ago by John Finlay <finlay@…>

In c8fb1323526d394c0d3cb38b13efbccbd0e45400/mythtv:

Fix lossless transcode.

Following 6c3653cd378aacef10b7706d8b7f71beae41274c, lossless mythtranscode got broken.

This is just a quick workaround, the whole code needs to be revisited and properly use FFmpeg API

Fixes #11213

Signed-off-by: Jean-Yves Avenard <jyavenard@…>
(cherry picked from commit 2a27e176275155a04498ecb8eac67dbd0164d080)

comment:19 Changed 10 years ago by John Finlay <finlay@…>

In 4a7bb19b1348cc0bc7152d0168fd571e55424d36/mythtv:

Fix lossless transcode.

Following 6c3653cd378aacef10b7706d8b7f71beae41274c, lossless mythtranscode got broken.

This is just a quick workaround, the whole code needs to be revisited and properly use FFmpeg API

Fixes #11213

Signed-off-by: Jean-Yves Avenard <jyavenard@…>
(cherry picked from commit 2a27e176275155a04498ecb8eac67dbd0164d080)

comment:20 Changed 10 years ago by Karl Dietz <dekarl@…>

In 11cbec350b520b28e0a2c2ae05805fb817acf9a1/mythtv:

actually add the timecodeOffset when getting audio frames

We have to ask the AudioReencodeBuffer? for audio to write with the
original timecode before applying the cut list.

Patch by Nicolas Pöhlmann
Reviewed by Paul Gardiner

Refs #11213
Refs #11639

(cherry picked from commit ea8c2b91e91e5cada8f8309f9fcb63f831f79aee)

comment:21 Changed 10 years ago by Raymond Wagner

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