Lip sync - once and for all

[gkreis]

I'd like for this thread to be an education on the issues behind lip sync problems. My old analog card never had lip sync issues, but QAM with my HVR-1600 is driving me nuts. On one station (PBS 1080i) it is dreadful, but on NBC (1080i) it is working well.

I know from reading threads in this forum that the combo of video and audio codec can make a difference with lip sync (not sure why) and I have experienced that. So I have used a combo (Cyberlink defined as default video codec) and the default audio codec. But I still have the erratic recordings that are out of sync. I am recording in dvr-ms, fwiw.

What is the best way to confirm where the problem is at? For instance,

1. How I can find out the actual codecs being used during playback. Can PVRX2 show them in an OSD during playback?

2. Does playing back on a PC using VLC or WMP help diagnose if there is a difference?

3. Is the lip sync issue at record time or is just a playback problem?

4. Does using 'watch' from TV Guide handle the sync issues differently than if you record it?

[dennit]

I'd like for this thread to be an education on the issues behind lip sync problems. My old analog card never had lip sync issues, but QAM with my HVR-1600 is driving me nuts. On one station (PBS 1080i) it is dreadful, but on NBC (1080i) it is working well.

I'm not having trouble with QAM and my HVR-1600 with dvr-ms recordings.

1. How I can find out the actual codecs being used during playback. Can PVRX2 show them in an OSD during playback?

I like GraphEdit. To use GraphEdit’s “Connect to Remote Graph …” function to connect to PVRX2 and read the graph it currently uses add the following registry setting:
HKEY_LOCAL_MACHINE\Software\Devnz\AddGraphToROT=1 (DWORD)

Just start playing in GBPVR, then open GraphEdit and attach. You can also just open a media file and render it with GraphEdit. It will show you the filters in use and they should be the same as GBPVR would use. (ffdshow can cause differences)

2. Does playing back on a PC using VLC or WMP help diagnose if there is a difference?

I'd say no. VLC uses its own internal filters. WMP used to help, but it's doing its own thing now. I sometimes use Media Player Classic - you can attach to that player, and it behaves like GBPVR

3. Is the lip sync issue at record time or is just a playback problem?

You'll have to ask sub. I'm inclined to think it's playback only, but I don't really understand muxes.

4. Does using 'watch' from TV Guide handle the sync issues differently than if you record it?

If it's live (set in config) I think the answer is yes, if it's not live, then no, it's handled the same as a recording.

Good luck. You can adjust filters in GraphEdit until you get perfect sync, then replicate that in GBPVR. I've never had sync issues, but I recall that there are some filters that will let you adjust sound delays.

[tomfilbey]

When using gbpvr to play back recorded OTA shows the lip sync is perfect. However when I use a different program like VLC or Window media player the audio is out of sync. Or if I use DVRMS toolbox to cut commercials the audio sync is off. I've been experimenting with Videoredo. It works great.

That said what I would like to do is record on one computer. Then playback using GBPVR on a different computer over my home network. However after configuring GBPVR on the second computer, it does not recognize the recorded programs. I tried using the video library mod to access the programs but GBPVR experiences and error. If anyone knows how to do this let me know.

I'm also interested in the answers to gkreis's questions

[Deusxmachina]

I haven't messed with anything out of sync in a long time. Basically ever since I started using dvr-ms. If you don't have a specific reason to not use dvr-ms, then use dvr-ms. You'd be in the minority if you have a problem with it. Some encoders can't read dvr-ms, which can be a problem, but, for me, I don't encode much TV anyway, so when I do I just use VideoRedo to cut it and convert it to .mpg. I don't know what VideoRedo does differently than other cutters and converters, but it just plain works.

Pretty sure my out of syncs were in the recording itself. And mine did have different problems from watching live vs. a recording, but as I thought about it more, I think it was just that watching live would get out of sync worse than a recording because I'd usually have live TV on longer, while a recording would be done after 30 or 60 minutes. The longer the show, the more out of sync it would get.

Not sure what the problem is, tomfilbey. That's the same thing I do: the HTPC is networked and is connected to a couple TVs, but I tend to watch most stuff on my other computer since that's often where I am. I don't play back with a second copy of GBPVR, though. I just use a regular player. I guess the obvious first question would be if your networked computer can play those files at all with a normal Windows-type player.

[pBS]

default audio codec? do you know what is being used? easy way is to set in config.xml to <SaveGraphFiles>true</SaveGraphFiles>
and then play a file in gbpvr, then look in gbpvr dir for the *.grf files...
you can actually read enough in notepad to see what codecs are being used, just ignore the junk and look at the codec names...
[you can also try loading grf in graphedit, but it's hit and miss..]
also in the logs it shows what codecs are actually being used...

you don't want to use the 'default' for any codecs...
set a specific codec for audio, and try different audio renderers also...
[but stay away from cyberlink renderer.doesn't work right usually]
this is US? only mpeg2 then...i'd try diff video codecs also, as i've not had any sync issues since i found real hardware accelleration..when the video has a hard time keeping up, sync suffers...Cyberlink cheats a bit in their codec, so it can behave strange sometimes..
i'd try the MPCHC codecs and if you have ati card ,the ati codec,specially for mpeg2..
[or ffdshow codec]

is video perfectly smooth?

[markbb1]

I know from reading threads in this forum that the combo of video and audio codec can make a difference with lip sync

Probably because some codecs are less prone to frame loss with a given hardware configuration.

3. Is the lip sync issue at record time or is just a playback problem?

In my opinion, this is usually caused by the video mux dropping frames and the audio stream remaining intact. After 30 video frames have been dropped, the audio is a full second behind the video. If that is the cause, and you can't reduce the frame loss to zero, the next best thing is to drop a corresponding amount of audio every time a frame is dropped. Not sure if/how you can do it in GBPVR.

4. Does using 'watch' from TV Guide handle the sync issues differently than if you record it?

Maybe not. If you are using the buffer to be able to pause and resume (or fast-forward) live TV, the dropped frames might show up in what you are calling "live" TV.

[BigMoose]

I know this isn't relevant to the OP but it is to the thread title - for H.264 AC3 ts recordings (1080i in the UK - BBC HD) I've noticed that LiveTV is always fine but playing back recordings is hit and miss depending on my combo of codecs. CoreAVC with ffdshow spdif (AC3 passthrough) goes out of sync however Cyberlink and ffdshow with spdif (AC3 passthrough) is fine. I assume then from the above that CoreAVC is losing frames but the audio isn't. Would have to test again to see if the video or audio lags as I cant remember.

It's the codec combo at playback that is the issue, the recording itself records fine.

I had the exact same problem with Bluray 1080p playback that some combos went out of sync and others were fine. Cyberlink and ffdshow went out of sync but ffdshow and ffdshow were fine, as was the MPC H264 decoder and ffdshow for audio.

[gkreis]

What I don't understand is why this extremely important feature (sync of audio and video) is so fragile. In a digital era, why are we not able to see these things locked together? Is it a design decision to say let a video frame be dropped but not audio because you can heard audio drops and you can't see a video frame drop here or there?

I get the impression there aren't any 'markers' in the streams that would allow them to know if they are in sync. Is this a case of what appears to be a very simple task being way more complicated once you delve into the details?

[gkreis]

Hmmm.... is a typical lip sync issue a consistent one? In other words, could GBPVR have a feature activated by key presses that would let you slide the streams so you could correct? Is this really practical? I know it is a 'band-aid', but it would be really useful to save a recording that you would otherwise have to endure or trash and might not be able to get again.

[dennit]

What I don't understand is why this extremely important feature (sync of audio and video) is so fragile. In a digital era, why are we not able to see these things locked together? Is it a design decision to say let a video frame be dropped but not audio because you can heard audio drops and you can't see a video frame drop here or there?

I get the impression there aren't any 'markers' in the streams that would allow them to know if they are in sync. Is this a case of what appears to be a very simple task being way more complicated once you delve into the details?

It's certainly a good question. I, too, was very surprised when I realized there were no sync markers in the audio/video streams. For broadcast TS streams, I suppose it makes sense - you receive a packet you display it/send to speakers. If one is missing, you can't jump forward to the next and thereby get out of sync - it hasn't arrived yet.

For a previously recorded mpeg, I suppose it's reliable enough that sync is not a problem, provided your two streams are correct - which they will be or you don't release your product. It's only when converting from a stream of TS packets to a recorded mpeg or converting from one format to another that this issue of dropped packets and bad sync seems to arise.

Still, I don't know why blank packets aren't inserted based on some external timing to hold sync problems to a minimum. I've wondered if dvr-ms is partly designed to address this issue.