Hi folks,
I've finally gotten around to fixing mythburn.py in 0.27 to support
cutlists on HD-PVR recordings. My prior patch
<http://www.mythtv.org/pipermail/mythtv-users/2012-October/341879.html>
did an extra (redundant) pass of transcoding to MPEG2 before proceeding,
but it seems that this isn't required anymore. But commercial cutting
still didn't work right out of the box. If you want, go right to the
patch. If you're interested about what it does and how I got there,
read on...
I had to change how the cutlist was obtained, as it didn't seem to get
it right off the bat. It now calls mythutil --getcutlist to get the
cutlist and parse it for passing to the mythtranscode commandline.
The first problem I ran into was that mythtranscode would fail if the
cutlist excluded any part of the beginning of the recording. In my
short example, if mythburn.py did:
mythtranscode --mpeg2 --infile
"/var/lib/mytharchive/temp/work/1/2251_20140302230641.mpg" --outfile
"/var/lib/mytharchive/temp/work/1/newfile3.mpg" --honorcutlist "0-254
992-1209"
mythreplex would:
STARTING DEMUX
Video: aspect ratio: 16:9
starting with video PTS:
0:00:00.8938
Can't find all required streams
Please check if audio and video have standard IDs (0xc0 or 0xe0)
Depending on how many frames were cut from the beginning (e.g. 0-10
instead), I might end up with something like:
STARTING DEMUX
Video: aspect ratio: 16:9
starting with video PTS:
0:00:00.6269
starting audio PTS:
0:00:26.4240
Wrong audio frame size: 1438
ringbuffer overflow 250<2016 629145
video ring buffer overrun error
However, if I removed the cutlist from the beginning (0-254):
mythtranscode --mpeg2 --infile
"/var/lib/mytharchive/temp/work/1/2251_20140302230641.mpg" --outfile
"/var/lib/mytharchive/temp/work/1/newfile3.mpg" --honorcutlist "992-1209"
mythreplex would succeed. This seems like a bug, but I didn't want to
dig into mythreplex. So on to projectx.
Projectx couldn't find the recording details via:
rec = DB.searchRecorded(chanid=chanid, starttime=starttime).next()
The chanid and starttime variables seemed OK and matched what's in my
recorded database. But the above line fails with a StopIteration error.
So if finding the recording via the channel and time fails, I'm falling
back to finding it via the recording filename, which was already stored
in streaminfo_orig.xml.
Now projectx fails because the "-set ExternPanel.appendPidToFileName=1"
option is not valid with "recent" projectx versions. This also means
that the filenames produced by projectx aren't what mythburn.py is
expecting. There's also some ".mv2" extensions in there, which should
be ".m2v"
The last thing I noticed was that despite the hd-pvr recording in AC3
already (and potentially in 5.1), mythburn.py was re-encoding the audio
down to stereo. I made a custom encoding profile
<http://www.mythtv.org/wiki/MythArchive#How_do_I_add_my_own_encoding_parameters_to_the_encoding_profiles.3F>
where I made a copy of "HQ" and renamed it. And in the existing HQ
profile I changed the "-acodec" option to "copy" and removed the "-b:a"
and "-ac" options. Note that if not all of your recordings are in AC3,
you may have DVD compatibility issues. My older recordings are in AAC
because of this bug: <https://code.mythtv.org/trac/ticket/2077>
mythburn.py could probably be modified to use lossless conversion only
when AC3 is detected, but I didn't feel like getting into that.
Finally, I ended up swapping out occurrences of "mythffmpeg" with
"ffmpeg". mythffmpeg hung up on an ATSC recording, but the ffmpeg that
comes with Mythbuntu 12.04 seems to work fine. I suppose changing the
mythffmpeg symlink would suffice, but I wanted to keep all modifications
to just mythburn.py.
That's about it. The patch is a bit hacky, but it works for me.
-WD
I've finally gotten around to fixing mythburn.py in 0.27 to support
cutlists on HD-PVR recordings. My prior patch
<http://www.mythtv.org/pipermail/mythtv-users/2012-October/341879.html>
did an extra (redundant) pass of transcoding to MPEG2 before proceeding,
but it seems that this isn't required anymore. But commercial cutting
still didn't work right out of the box. If you want, go right to the
patch. If you're interested about what it does and how I got there,
read on...
I had to change how the cutlist was obtained, as it didn't seem to get
it right off the bat. It now calls mythutil --getcutlist to get the
cutlist and parse it for passing to the mythtranscode commandline.
The first problem I ran into was that mythtranscode would fail if the
cutlist excluded any part of the beginning of the recording. In my
short example, if mythburn.py did:
mythtranscode --mpeg2 --infile
"/var/lib/mytharchive/temp/work/1/2251_20140302230641.mpg" --outfile
"/var/lib/mytharchive/temp/work/1/newfile3.mpg" --honorcutlist "0-254
992-1209"
mythreplex would:
STARTING DEMUX
Video: aspect ratio: 16:9
starting with video PTS:
0:00:00.8938
Can't find all required streams
Please check if audio and video have standard IDs (0xc0 or 0xe0)
Depending on how many frames were cut from the beginning (e.g. 0-10
instead), I might end up with something like:
STARTING DEMUX
Video: aspect ratio: 16:9
starting with video PTS:
0:00:00.6269
starting audio PTS:
0:00:26.4240
Wrong audio frame size: 1438
ringbuffer overflow 250<2016 629145
video ring buffer overrun error
However, if I removed the cutlist from the beginning (0-254):
mythtranscode --mpeg2 --infile
"/var/lib/mytharchive/temp/work/1/2251_20140302230641.mpg" --outfile
"/var/lib/mytharchive/temp/work/1/newfile3.mpg" --honorcutlist "992-1209"
mythreplex would succeed. This seems like a bug, but I didn't want to
dig into mythreplex. So on to projectx.
Projectx couldn't find the recording details via:
rec = DB.searchRecorded(chanid=chanid, starttime=starttime).next()
The chanid and starttime variables seemed OK and matched what's in my
recorded database. But the above line fails with a StopIteration error.
So if finding the recording via the channel and time fails, I'm falling
back to finding it via the recording filename, which was already stored
in streaminfo_orig.xml.
Now projectx fails because the "-set ExternPanel.appendPidToFileName=1"
option is not valid with "recent" projectx versions. This also means
that the filenames produced by projectx aren't what mythburn.py is
expecting. There's also some ".mv2" extensions in there, which should
be ".m2v"
The last thing I noticed was that despite the hd-pvr recording in AC3
already (and potentially in 5.1), mythburn.py was re-encoding the audio
down to stereo. I made a custom encoding profile
<http://www.mythtv.org/wiki/MythArchive#How_do_I_add_my_own_encoding_parameters_to_the_encoding_profiles.3F>
where I made a copy of "HQ" and renamed it. And in the existing HQ
profile I changed the "-acodec" option to "copy" and removed the "-b:a"
and "-ac" options. Note that if not all of your recordings are in AC3,
you may have DVD compatibility issues. My older recordings are in AAC
because of this bug: <https://code.mythtv.org/trac/ticket/2077>
mythburn.py could probably be modified to use lossless conversion only
when AC3 is detected, but I didn't feel like getting into that.
Finally, I ended up swapping out occurrences of "mythffmpeg" with
"ffmpeg". mythffmpeg hung up on an ATSC recording, but the ffmpeg that
comes with Mythbuntu 12.04 seems to work fine. I suppose changing the
mythffmpeg symlink would suffice, but I wanted to keep all modifications
to just mythburn.py.
That's about it. The patch is a bit hacky, but it works for me.
-WD
Attached Files:
-
mythburn27.patch (17.8 KB)
