2012-07-07, 12:56
Here's an interesting one... pay attention, it might get confusing...
I record stuff with tvheadend (currently 2.99.37.1332f9f on Ubuntu 10.04). I use VLC (currently 2.0.2 on XP) to play the files and work out where the adverts are, then mkvmerge GUI (mkvtoolnix 5.6.0) to cut them out. So far, so what...
A couple of days ago I updated to VLC 2.0.2, and suddenly the workflow fell apart. I played one file in VLC 2.0.1, noted the timecodes of the adverts, chopped it up, fine... I then did a second in VLC 2.0.2 and everything failed because I was chopping the files in the wrong place.
A bit of investigation showed that the file time code immediately jumps to 00:30 as it starts - so everything is chopped 30 seconds before it should be, defeating the object completely.
Downgrade VLC to 1.x - same behaviour. Back up to 2.0.1 - same behaviour. Back to 2.0.2, still there. Check on another PC (VLC 2.0.2 on Win7), still there. That confuses the bejeesus out of me, since there's no way that VLC should be changing something that's persistent - I've tried every uninstall method that I can think of, so unless it's irrevocably changed a DLL somewhere...? libavcodec_dll installs alongside VLC, not system-wide..
However, play the files in MPC, and the time codes are correct, starting, somewhat as expected, at 00:00.
I'd swear the issue wasn't there prior to 2.0.2 since every other file has always cut correctly - and VLC was the only thing that changed. Playing old recording on 2.0.2 (going back a month, perhaps), they show the same ~30s offset, which I've never seen before. So something between tvheadend source file and VLC playing is arguing.
BUT THIS ISN'T A VLC ISSUE AS IT APPEARS.
Check the files in several Android apps, and the issue is there sometimes, but not always.
Check it in XBMC (OE 1.99.4/XBMC 11.0 Git: ec192fa Jun 27 2012) and the same offset is there - I've never looked before, I tend not to bring up the OSD immediately when playing a programme!
Sooo....
I record stuff with tvheadend (currently 2.99.37.1332f9f on Ubuntu 10.04). I use VLC (currently 2.0.2 on XP) to play the files and work out where the adverts are, then mkvmerge GUI (mkvtoolnix 5.6.0) to cut them out. So far, so what...
A couple of days ago I updated to VLC 2.0.2, and suddenly the workflow fell apart. I played one file in VLC 2.0.1, noted the timecodes of the adverts, chopped it up, fine... I then did a second in VLC 2.0.2 and everything failed because I was chopping the files in the wrong place.
A bit of investigation showed that the file time code immediately jumps to 00:30 as it starts - so everything is chopped 30 seconds before it should be, defeating the object completely.
Downgrade VLC to 1.x - same behaviour. Back up to 2.0.1 - same behaviour. Back to 2.0.2, still there. Check on another PC (VLC 2.0.2 on Win7), still there. That confuses the bejeesus out of me, since there's no way that VLC should be changing something that's persistent - I've tried every uninstall method that I can think of, so unless it's irrevocably changed a DLL somewhere...? libavcodec_dll installs alongside VLC, not system-wide..
However, play the files in MPC, and the time codes are correct, starting, somewhat as expected, at 00:00.
I'd swear the issue wasn't there prior to 2.0.2 since every other file has always cut correctly - and VLC was the only thing that changed. Playing old recording on 2.0.2 (going back a month, perhaps), they show the same ~30s offset, which I've never seen before. So something between tvheadend source file and VLC playing is arguing.
BUT THIS ISN'T A VLC ISSUE AS IT APPEARS.
Check the files in several Android apps, and the issue is there sometimes, but not always.
Check it in XBMC (OE 1.99.4/XBMC 11.0 Git: ec192fa Jun 27 2012) and the same offset is there - I've never looked before, I tend not to bring up the OSD immediately when playing a programme!
Sooo....
- Is this an ffmpeg/libav issue? I can't find a changelog for VLC 2.0.2 that suggests anything was updated.
- Or is it a tvheadend issue, in that it's writing the files badly?
- Or is it a streaming issue, in that things can't accurately sync until the first i-frame (or whatever the equivalent is in a streamed MPEG2 file)?
- Or is it an mkv demux issue?
- Or...