[mythtv-users] Transcoding profiles

[Christopher Meredith]

On Thu, May 19, 2011 at 11:12 AM, Raymond Wagner <raymond at wagnerrp.com> wrote:
> On 5/19/2011 12:01, Christopher Meredith wrote:
>> On Thu, May 19, 2011 at 10:22 AM, Raymond Wagner<raymond at wagnerrp.com>  wrote:
>>> On 5/19/2011 11:04, Christopher Meredith wrote:
>>>> On Thu, May 19, 2011 at 9:47 AM, Raymond Wagner<raymond at wagnerrp.com>    wrote:
>>>>> On 5/19/2011 10:33, Bob wrote:
>>>>>> I have been reading the many threads about transcoding with 6 channel
>>>>>> audio.  I would like to transcode some h264 content with 5.1 from my
>>>>>> HD-PVR.  In the profiles I only see "MP3" and "Uncompressed" as audio
>>>>>> options.  Do most people choose "Uncompressed" when wanting to preserve
>>>>>> the 6 channel audio?
>>>>> Your content is already in h264.  It already is in the most efficient
>>>>> common codec available.  While hardware decoders are not going to be as
>>>>> efficient as something like x264, and you could arguably shave off
>>>>> 20-30% with minimal quality loss, it will be at a huge cost in CPU power
>>>>> (and electricity).  You shouldn't bother transcoding that content unless
>>>>> you are either clipping commercials, or need it in a specific format for
>>>>> some device.  In either case, you really want to use an external
>>>>> utility, rather than MythTV's internal transcoder.
>>>> AFAIK, mythtranscode is still incapable of working with HD-PVR
>>>> recordings anyway.
>>> Mythtranscode can work with HDPVR recordings just fine, however the
>>> special lossless cutting mechanism only works with MPEG2.  It works by
>>> performing a GOP cut, followed by filling the frames between the extent
>>> of the GOP structure and the real cutpoint itself with I-frames.  Any
>>> HDPVR content will instead be transcoded to MPEG4 in a NuppelVideo
>>> container.
>>>
>>>> If you're looking to cut commercials, I've found
>>>> that recording at max quality, then transcoding to MPEG2, then cutting
>>>> commercials with mythtranscode, then converting back to h264 using
>>>> HandBrake at 3250 kbps produces better-looking results than an
>>>> unconverted HD-PVR recording done at 3250 kbps.
>>> That seems to be an extremely long winded way of doing things.  Surely
>>> handbrake can be fed a cutlist and do the cutting directly on the first
>>> pass.  At least choose something lossless and fast as your intermediary
>>> format, like huffman, rather than MPEG2.  While the 13.5mbps max quality
>>> recordings out of the HDPVR are overkill by any measure, 3250kbps seems
>>> awfully low for even 720p60.  I would expect more like 4-6 depending on
>>> the grain and motion in the content.  At any rate, you shouldn't be
>>> setting the bitrate anyway.  Save yourself the second pass, set a
>>> constant quantizer to 20 or so, and let the compressor decide what's best.
>> HandBrake does not appear to support EDL or cutlists. For my use case,
>> I require the ability to use mythcommflag and mythtranscode and to
>> achieve frame-accurate cuts. Can mythcommflag and mythtranscode work
>> with huffman encoding?
>
> Not directly, no.  However you can get mythtranscode to act as a raw
> frame server to another application that can.  See nuvexport for an
> example on how to do this.
>
>> Also, I choose 3250 kbps because that's the current convention for archived, HD, commercial-less recordings (1-hour show = 1.1 GB).
>
> By who?  People who have been known in years past to use stupid encoding
> options that play hell with hardware decoders?  People who fervently
> insist that in this day and age, content still exist in a filesize such
> that it perfectly fits on some optical medium? If you're going to follow
> standard practices dictated by 'the scene', don't forget to pack up all
> your content in RARs, split at 15MB chunks.

I've found that for my needs, 3250 kbps strikes the optimal balance
between storage space and picture quality. And my original point was
that even after two levels of lossy converting, I think the picture
looks better at a given bitrate than if you set the HD-PVR to record
at the target bitrate. I used 3250 kbps as an example because that's
my personal preference, and apparently a common one. Why do you care
what settings I use?