464 preview sync problem

DrP

Member
This one's a little unusual. I'm attempting to edit a .rec file from a TF5000 and am seeing audio sync problems (possibly half a second) when previewing the edits before exporting to .mpg. However, playing the .rec file in non-preview mode in the same places audio sync was noticed to be out, gave correct audio sync. I did a QSF on the .rec file which showed no errors and also ran the .rec through project-x which showed no errors either.

Now for the twist. If I take the .mpg from the QSF and use the same frame points for edits, it too previews with the audio out of sync, as does the stream files from project-x after being re-muxed using mplex.exe (-f8), but both play in non-preview mode correctly, the same as the .rec file.

In all cases, continuing on and producing an edited .mpg file produces an output file with good audio sync. Its just a bit off-putting having incorrect audio sync in preview mode.

I've saved a copy of the .rec file and the edit points as a project file, but uploading them isn't really practical for me as its around 2.5Gb all up and at 25 kilobytes/sec it'd take an age to do.
 

phd

Super Moderator
Is it only the one file or all files?

What are the specs of your machine? OS, CPU, RAM, videocard?

Do you have YUV acceleration and DirectSound enabled?

See if you notice the same anomaly with V465.
 

DrP

Member
>Is it only the one file or all files?
This is the first time I've noticed it, but I'll be keeping an eye out to see if it happens with other files.

>What are the specs of your machine? OS, CPU, RAM, videocard?
XP SP2, P4 2.6 HT, 1Gb RAM, integrated Intel video.

>Do you have YUV acceleration and DirectSound enabled?
Yes. Turning both off and restarting VR does not fix it.

>See if you notice the same anomaly with V465.
Yes I do.

One more interesting thing that I've noticed now that I've turned YUV acceleration off in 465 is that when I move the VR window around so that the video area moves over the edge of my display, the video area detaches itself from the VR window and leaps up to the top left corner of the display overwriting anything that happened to be in that area of the screen and leaving a general mess behind. Anything that causes VR to repaint its window also causes the now incorrectly located video area to be refreshed. I don't know if this happened with previous versions or not. You can see what I'm talking about with this image.

With overlays enabled, when moving VR so that the video window goes off the edge, the overlay 'crashes' into the edge and stops following the VR window. Other programs that use hardware overlays don't have this problem. I've noticed this quirk with previous versions, just haven't mentioned it.
 

Anole

Moderator
arghhhh!!!

DrP said:
One more interesting thing that I've noticed now that I've turned YUV acceleration off in 465 is that when I move the VR window around so that the video area moves over the edge of my display, the video area detaches itself from the VR window and leaps up to the top left corner of the display overwriting anything that happened to be in that area of the screen and leaving a general mess behind.
Oh, crap!
I just duplicated this bug in VRD 461 on my laptop (WinXP home, SP1) with ATI video.
Was going to suggest it was a video driver, but maybe not...

Gotta clean my screen before continuing... :(

...oh, okay, it'd affected my FireFox window and prevented me from navigating this forum.
I minimized FireFox, changed the video setting (which probably didn't matter), and upon restoring FireFox, all the artifacts were gone.
 
Last edited:

DrP

Member
I've now been able to reproduce this audio sync preview problem in beta 466 with a FTA DVB-t recording. Once again, it doesn't matter that the source has no errors. Doing a QSF and then cutting the resulting file gives the preview audio sync problem. In this particular example, I've cut out on a B frame and in on a B frame.

So far my problem list with Redo is:

1) video Overlay not being turned off when redo is minimized leading to bleed through if another program happens to contain the key colour.
2) video overlay "crashes" into the edge of the display and stops moving when moving redo so that the video area moves off the edge of the screen.
3) video detaches from redo and snaps to top left of screen, over-painting anything that happens to be in that area when redo is not using overlay mode and the redo window is moved so that the video display area in redo starts to go off the edge of the display, leading to a general mess on display.
4) preview playback plays a few samples from the last time a preview was played as if an audio buffer somewhere isn't being flushed properly (does this on mutiple computers with completely different audio hardware).
5) preview audio sync issue as in above posts
6) PTS jumps in redo output when the input transport stream is completely clean. project-x, pvastrumento and redo don't find fault with the input file. project-x and pvastrumento both find fault with the output file, but redo QSF doesn't. From other people's posts, I'm not the only person seeing this one.
 

phd

Super Moderator
For #6 could you provide details of the errors in project-x and pvastrumento?
 

DrP

Member
I've uploaded the details to the FTP when I initially reported the problem, should be a DrP folder there.
 

Danr

Administrator
Staff member
DrP,

Just wanted to let you know that we have most of items 1, 2 and 3 fixed for the next beta. The only problem still left is that as part of the video display moves off screen the video becomes squashed instead of clipped. Its not "end of the world", and is certainly better than getting "torn off", but its not yet perfect. As part of this, we've also fixed some other stuff in the multi-monitor code so that YUV displays even better on multi-display systems. Should have a fix out by the end of the week. Also, HyperReality has been bugging us for months for turning off the YUV when minimized, I know he will be glad as well.

Will look at your other items that you've uploaded.
 

HyperReality

New member
DanR said:
Also, HyperReality has been bugging us for months for turning off the YUV when minimized, I know he will be glad as well.
Bugging? Me? Never! :D

I think of it more as "constructive feedback" to help improve the product for all of our customers. :rolleyes:

Thanks for changing the behaviour. Now, about having quickly selectable Ad-Detective settings profiles.... :D
 
Top Bottom