Kodi Community Forum

Full Version: TVHeadend - Wrong timecodes? Or is it something else?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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....
  • 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...Huh




Update... even taking the timestamps from MPC doesn't work, as mkvmerge is still cutting 30s out - almost as if it can't read the file properly either. But if it has the same offset as the players, wouldn't you expect it to land at the right place?
Another observation...

Seems that the file I tested with MPC played and split correctly - despite showing the 30s offset, mkvmerge agreed with the timestamps.

Everything else today:

1. Play the file, and it starts at 00:30 (ish, some are 00:28, for example)

2. Click forward in the file to find the beginning of the programme - let's say you find it at 01:00 - then split here and mkvmerge will only take the first 30 seconds off because of this offset.

3. Let the file play to the same point and the clock will show 01:30 (despite only playing 01:00 of video - I've timed it with my watch!) - tell mkvmerge to split at 01:30 and you'll get the right result, deleting the full minute.

So, I either need to let the file play, or add the offset to where things think the programme starts.

Weird. I'll try re-wrapping the file(s) into a different container and see if that helps.
Nope, a simple:

Quote:ffmpeg -i <file.mkv> -acodec copy -vcodec <file.avi>

... leaves me with a file in which the *audio* starts at 00:00, but the *video* then doesn't kick in until 00:30, leaving the whole thing waaaay out of sync. And that's on VLC - WMP only plays the audio stream, MPC behaves much as VLC, and XBMC doesn't like it at all, spending a lifetime looping through the initial frames, trying to make sense of things. Clearly a badly damaged stream, I guess.

If anyone's interested, this is the original file (actually, an mkvmerge cut of the first minute, but it exhibits the 30s offset on my systems):

http://www.datafilehost.com/download-d6932dd5.html

... and this is the avi re-wrap:

http://www.datafilehost.com/download-c35ecf53.html
Final thought: I tried to re-wrap the original file (not the cut version) and ffmpeg choked:

Code:
DTS 30640, next:30760000 st:0 invalid dropping
PTS 30640, next:30760000 invalid dropping st:0
DTS 30680, next:30800000 st:0 invalid dropping
PTS 30680, next:30800000 invalid dropping st:0
DTS 30720, next:30840000 st:0 invalid dropping
...

... finally creating a file that had a similar "audio starts but video arrives 30s late" issue.

So, the time stamp complaints would lead me to conclude that it's a tvheadend stream issue - maybe unavoidable given that it's dealing with MPEG-TS (ProjectX might fix it).

None of that answers why I've suddenly noticed this, though, and never had a problem before!
Gotcha!

Brainwave... it's not the 30s initial offset, it's what reports as you click through the file.

So, I suspect that this 30s-ish offset has always been there, I've just never noticed it.

What's changed is how VLC (particularly) reports its position in the file... prior to 2.0.2 it would start at 00:30 but subsequently report the correct position plus the offset as you jumped forward (so "programme starts at 02:00" when a minute and a half in) ... with this version, it still starts at 00:30 but now reports the correct timestamp in the file (so "programme starts at 01:30"). mkvmerge has the same behaviour as the old VLC (as, I presume, has XBMC?), so they were happy - they agreed on where to cut it, and cut it in the right place. Now, I have to add the offset manually to correct the different behaviour, otherwise mkvmerge takes the 30s into account, buts at what it thinks is 01:30, and actually chops the file at 01:00.

Because I was looking at the initial offset, previous versions of VLC apparently showed the same behaviour after I'd installed 2.0.2 - but I was looking for the wrong thing...

No explanation of why they do this, and whether it's a bug or a feature in tvheadend - but at least I know!

I hope that's useful for someone else. Thanks for listening :-)