[mythtv-users] MPEG4 bigger than MPEG2?

[Raymond Wagner]

On 3/10/2012 15:39, Ross Boylan wrote:
> On Sat, 2012-03-10 at 14:33 -0500, Raymond Wagner wrote:
>> On 3/10/2012 13:43, Ross Boylan wrote:
>>> On Fri, 2012-03-09 at 09:06 -0700, Tom Hayward wrote:
>>>> On Thu, Mar 8, 2012 at 20:51, Ross Boylan<RossBoylan at stanfordalumni.org>   wrote:
>>>>> Hi, everyone.  I'm a new user, and am wondering why transcoding is
>>>>> making my files bigger.  More specifically, I think I have transcoded a
>>>>> file from MPEG-2 to MPEG-4, and it got a little bigger (3.1 vs 2.9GB).
>>>> The real question is: Why do you want to transcode?
>>> To save space.
>> Most people around here are of the opinion that recordings should only
>> be transcoded for compatibility with other devices, not to save space.
> That's useful information.  I do tend to fill up my disks though...
>> Transcoding is a very CPU intensive prospect, and while CPUs are
>> continually getting more efficient, hard drives are continually getting
>> cheaper.  Until the floods last October drove up hard drive prices, an
>> average HD recording might cost $0.20 of disk space per hour,
>> or maybe
>> $0.15 after spending a couple minutes defining a cutlist, and a couple
>> more running a lossless transcode.  Transcoding to H264 while retaining
>> quality might drop that to $0.05-$0.07,
>> but is going to run at a
>> fraction of real-time, and eat up considerable electrical power doing
>> so.  When you consider the cost of the increased power consumption as
>> compared to putting that machine in standby, or even just idling, the
>> cost benefit all but vanishes.  It's easier, and only modestly more
>> expensive, to just buy more hard drives.
> Out of curiosity, where do those cost figures come from?
> One other factor: additional disks also use more power.

Additional disks use additional power, but only when in use.  When not 
in use, or when the system is in standby, they can be spun down for 
nearly no consumption.

Prior to the flood, 2TB hard drives were readily available for around 
$70.  That's $0.035/GB, or $0.0375/GB if you account for binary/decimal 
discrepancy, putting an average 6GB hour long recording at $0.21.  
Lossless transcoding typically drops that to around 4GB, or $0.14.  The 
H264 format is designed double the compression efficiency of MPEG2 at 
the same quality level, but considering x264 is one of the better 
encoders, and hardware compressors used by broadcasters tend to be less 
efficient, 1/3 the size of the original is not unreasonable.  That would 
bring you down to around 1.5GB and $0.05.

The last time I made a go at transcoding HD recordings, running iVTC to 
convert from 1080i30 to 1080p24, and doing a single pass constant 
quantizer compression with good (but not absurd) quality settings on a 
2.8GHz Core 2 Duo, an hour long (44.5min clipped) recording took some 12 
hours to drop from 13Mbps to 5.5Mbps.  That's $0.0875 saved in storage, 
but with 150W consumption, and $0.15/kWh for power and line charges, 
$0.27 spent in electricity compared to letting the machine go into <5W 
standby mode.

Now computers have improved, and a modern quad-core SB i5/i7 might only 
take 3-4 hours, and use 100W doing so under full load, but that's still 
half what you saved, and means your computer is tied up transcoding your 
recordings, and not being used for other purposes.

>>> When editing the transcode options (autodetect MPEG2) does selecting
>>> "lossless transcoding" do the TS->PS transcode?  The description, e.g.,
>>> "keep audio and video formats identical to the source", sounds as if it
>>> will not.  If it does not, how do I get the desired conversion?  The
>>> only video codes I see are MPEG-4 and RTJpeg.
>> TS and PS are two different types of MPEG2 containers.  A container is
>> just a wrapper that contains video, audio, and other sundry data
>> streams.  Think of it like a 'tar' file.  There is almost no CPU usage
>> to convert between different containers, as the streams are typically
>> just copied from one to the other.
> I have trouble reconciling that statement with Tom Hayword's that
> "Re-muxing from MPEG2-TS to MPEG2-PS can save up to 20%."  Can anyone
> clarify?

20% is a bit of a worst case value, but certain containers are just more 
efficient than others.  TS containers are intended to be used for lossy 
transmissions, and cases where you may want to start at any arbitrary 
point.  That means there's padding, and lots of redundancy in the 
metadata.  Where most containers might contain one header at the start 
of the file, a TS container might intersperse them several times per second.

>>> What controls whether commercials are deleted from the transcoded
>>> recording?
>> Go into the transcoder settings, and set the "Lossless" checkbox to
>> enabled.  Any MPEG2 (and only MPEG2) recordings transcoded using this
>> profile will be performed losslessly.  Most people use the "Autodetect
>> MPEG2" profile for this reason.  Commercials are not deleted from the
>> recordings, cuts are.  To produce a cutlist, you must go into edit mode
>> (e) during playback in mythfrontend, and define them.  Commercial
>> detection is not reliable enough to be blindly trusted, so
>> mythtranscoder will not use a commercial list.
> Just to be sure I'm understannding: commercials are never cut unless I
> intervene manually before the transcode runs, right?  And I probably
> shouldn't, since I may end up deleting real program material unless I'm
> careful (i.e., spend a lot of time verifying and tweaking the cuts).

Commercial lists and cut lists are independent, correct.  "A lot of 
time" is not that correct.  Running mythfrontend on a desktop with a 
keyboard, it might take me 90-120 seconds to create a cutlist for an 
hour long show.  You can import the skiplist to use as a guide, but I've 
not found it to make things much faster.  Using a remote instead of a 
keyboard takes me a bit longer, just because I can't hit the buttons as 
fast.  You can also create a cutlist as you are viewing, taking a few 
seconds per start/stop to flip into edit mode, mark the correct frame, 
and drop back out to playback.