[mythtv-users] Ad removal and lossless transcode for mpeg2 recordings

[John Pilkington]

I've started a new branch from a current thread.

> On 10/16/2013 4:17 PM, Daryl McDonald wrote:
>> So is transcoding really necessary?

Raymond Wagner replied:
>
> Sort of.  Any video compression with a decent ratio is going to have inter-frame coding.  Intra-frame coding (I-frames) is compression that depends only on that one single image.  Inter-frame coding (P-frames and B-frames) are frames where at least part of their information is derived from some other frame.  Since video is largely static from one frame to the next, this significantly increases compression efficiency.
>
> The issue is that if you want to do something like remove ads, you must do it in a manner that does not leave any of these P and B frames hanging with missing references.  There are three options here.  You can transcode the whole thing from scratch.  You can cut only at GOP boundaries, ensuring you've left no orphaned frames, but this does not allow for accurate cuts.  You can do a mix, transcoding only those orphaned frames between the cut point and the GOP boundary.
>
> This last option is what "lossless" mode in mythtranscode does.  For MPEG2 only, it cuts at the outside boundary, and then backfills with I-frames.  While not efficient compression, you're only talking a couple dozen frames per cut, or a couple hundred over the course of a several hundred thousand frame movie.  In North America, anything digital is going to be MPEG2.  In Europe or Australia, you can end up with MPEG4, which cannot be losslessly cut using mythtranscode.

This all sounds true, but I think it may be time for a rethink.

Originally most Mythtv experience with mpeg2 was probably from 
locally-encoded analog recordings.  Now we record digital streams 
assembled at source, and most edit points, particularly those at 
programme start, end, and ad-breaks, occur at keyframes.  If you can 
make your cuts there you don't need the frame-reconstruction stuff and 
things are a lot simpler.

At present the frame numbers used by the editor seem to be slightly out 
of step with those used elsewhere, but by sidestepping this problem I 
find that I get results that are entirely acceptable.

For example, I find that if I run the editor on recordings (0.27-fixes, 
UK, DVB-T, SD, MPEG2-TS) that have been cut and reformatted to MPEG2-PS 
by my mythDVBcut script:

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

and, if stepping backwards by single frames in the editor, frames n+1 
and n+2 sometimes appear interchanged.

During the original editing the frame numbers of the oldscene/newscene 
transition are usually, but not always, a few frames before the frame 
number shown for the keyframe.  Project-X, or the alternative python 
cutter, works with byte-offsets read from the keyframe list in the database.

There's a bit more on this topic here:

http://code.mythtv.org/trac/ticket/11213

John P