Re: [transcode-devel] A/V sync problem transcoding from .nuv to .mpeg

[Steve Hosgood]

Andrew Church wrote: Actually, to be fair, Nuppelvideo is probably trying to make the best of a bad job. The capture card is a Brooktree BT848 and apart from doing PAL-decoding (or NTSC) it does almost nothing other than chuck frames at the computer over the PCI bus. I've got a 1600MHz machine, but even then it can drop the odd frame here and there. I can understand where it's coming from, but the logic is still flawed. The source frames are being generated at a constant frame rate, 25fps (40ms/frame) for PAL; regardless of the exact point in time at which MythTV picks up the frame, that original interval doesn't change. [snip] I think maybe Nuppelvideo (on my machine) may be hindered by another issue - that is the business of "frame numbers". Way back in the 0.7.x family of bt848 drivers (on linux) there was non-standard method for flagging frames with a frame-number to help capture applictions software notice such things as dropped frames. The 2.6 linux kernels come with 0.9.x drivers, and the "frame number" hack was dropped (anyone know why?) probably because it wasn't a part of the V4L or V4L2 specs. Losing that information meant that NuppelVideo (or MythTV) could only conclude that a frame was dropped by checking its timestamp w.r.t the last known frame. Looks like .nuv files just punt the business of what to do about a dropped (or late) frame just by tagging frames with their timestamps. Trying to sort it out on-the-fly was probably thought to be too much realtime work. After all, Nuppelvideo works on even rather slow machines (like 350MHz) Steve.