On Fri, 21 Nov 2003, Ronald Bultje wrote: > Hi Steve, > > On Fri, 2003-11-21 at 04:42, Steve Tell wrote: > > ++: Corrupt JPEG data: 201 extraneous bytes before marker 0xd9 > > ++: Corrupt JPEG data: 87 extraneous bytes before marker 0xd9 > > It means you recorded at a too high quality, the card couldn't handle > the data throughput, it only delivered partial frames, which are > invalid. Don't forget that the "new" driver has twice the quality of the > "old" driver at the same quality level given to lavrec. So -q50 in the > new driver is similar to -q100 of the old driver. Experimenting is the > only way to find the optimal levels, I haven't found a good way of > autodetecting this. Does "couldn't handle the throughput" relate mainly to overrunning the pci-bus DMA bandwidth to memory that the card can get in a particular system, Or does the zoran's jpeg encoder hardware itself get confused when a picture is too complex? Anyway, thanks for the pointer. I had tried a few different -q settings, and while I seemed to get slightly fewer of these errors at -q50 than at -q80, it didn't seem dramatic. I'll experiment further. Adjusting the zoran cards PCI latency timer didn't seem to have much affect. Another error I see sometimes is "timeout syncing on a buffer" which causes lavrec to die. This happened a lot with -d2 320x240ish capture from VHS tape until I turned on my VCR's timebase corrector. I never saw it with -d1 full-screen-interlaced camera input, so this error seems related most strongly to bad input video is that true? Is hacking on (lib)lavrec to make it restart when a "timeout" occurs likely to be fruitful? I'm interested in doing live-performance recording from a camera, where dropping out for even a half second a few times an hour would be bad, but much more tolerable than aborting entirely and requiring manual intervention. thanks for your help, Ronald. Steve
