2012-12-28, 00:23
Folks -
I've wittered about this before, but it's time to raise it again simply because it's buggering up my workflow when trimming adverts/leading credits/etc. I use tvheadend 3.2 (3.2.18~g40a8920~oneiric) on XBMCBuntu (Oneiric/11.10), although I've had this problem on various other variations. Recording is from multiple USB DVB-S2/T/T2 tuners to mkv containers on a local SSD.
Simply put, everything has about a 30s timecode offset. Open a file in XBMC and immediately call up the properties, and it'll tell you that it's about 30s in as soon as it starts.
Some other media players see the same - VLC before early 2.x releases did, but not later ones; mkvmerge sees the same; MPC doesn't.
So here's the irritation: I play the file in VLC (on XP or Win7) to see where the preamble stops and the programme proper starts. I make a note of that timecode, plus the equivalent at the other end of the broadcast. I feed these into mkvmerge GUI as cut points, and I promptly slice the file in the wrong place. Creating EDL files for XBMC has the same effect - you have to manually tune the values to the right place with a binary split around "approximately 30s from where you think you should be", which is an utter waste of my life.
The only ways around it I've found is:
1. To use an old release of VLC to find the cut points since that sees the offset in the same way as mkvmerge. However, VLC 1.11.x crashes more often than I care to mention, and I'd rather only have a single version installed anyway.
2. To run the file through Handbrake before cutting. This corrects a multitude of errors, included the timecode offset, so the file now tells everyone that it genuinely begins at 00:00:00. However, I'd rather re-encode as a last resort (it's not strcitly necessary on an H.264 HD broadcast anyway, as well as taking forever) - and, if I do have to do it, I'd rather do it last, since it maintains file integrity (chopping up an H.264 stream can play havoc with seek times).
Any thoughts, anyone? Does anyone else see this, does anyone have a different editing workflow that gets around it?
I've wittered about this before, but it's time to raise it again simply because it's buggering up my workflow when trimming adverts/leading credits/etc. I use tvheadend 3.2 (3.2.18~g40a8920~oneiric) on XBMCBuntu (Oneiric/11.10), although I've had this problem on various other variations. Recording is from multiple USB DVB-S2/T/T2 tuners to mkv containers on a local SSD.
Simply put, everything has about a 30s timecode offset. Open a file in XBMC and immediately call up the properties, and it'll tell you that it's about 30s in as soon as it starts.
Some other media players see the same - VLC before early 2.x releases did, but not later ones; mkvmerge sees the same; MPC doesn't.
So here's the irritation: I play the file in VLC (on XP or Win7) to see where the preamble stops and the programme proper starts. I make a note of that timecode, plus the equivalent at the other end of the broadcast. I feed these into mkvmerge GUI as cut points, and I promptly slice the file in the wrong place. Creating EDL files for XBMC has the same effect - you have to manually tune the values to the right place with a binary split around "approximately 30s from where you think you should be", which is an utter waste of my life.
The only ways around it I've found is:
1. To use an old release of VLC to find the cut points since that sees the offset in the same way as mkvmerge. However, VLC 1.11.x crashes more often than I care to mention, and I'd rather only have a single version installed anyway.
2. To run the file through Handbrake before cutting. This corrects a multitude of errors, included the timecode offset, so the file now tells everyone that it genuinely begins at 00:00:00. However, I'd rather re-encode as a last resort (it's not strcitly necessary on an H.264 HD broadcast anyway, as well as taking forever) - and, if I do have to do it, I'd rather do it last, since it maintains file integrity (chopping up an H.264 stream can play havoc with seek times).
Any thoughts, anyone? Does anyone else see this, does anyone have a different editing workflow that gets around it?
