On Wed, 2008-11-26 at 02:25 -0500, igloocentral hotmail wrote: > I couldn't write to that debug file, no matter what. I hope these > commands are equivalent: > > sudo service mythtv-backend stop > sudo modprobe -r cx18 > sudo modprobe cx18 debug=15 > v4l2-ctl -i 1 > mplayer /dev/video0 -cache 16384 > mplayer /dev/video0 > > > How rapidly does the A-V difference grow with unbuffered playback? > With buffered playback, how rapidly does the cache fill sink to 0%? > > Unbuffered: A-V reaches 10 in as fast as 30 seconds: > > Too many video packets in the buffer: (4096 in 7965612 bytes). > Maybe you are playing a non-interleaved stream/file or the codec > failed? > For AVI files, try to force non-interleaved mode with the -ni option. > Cannot sync MAD frame > A: 45.2 V: 35.0 A-V: 10.198 ct: 1.519 1026/1026 3% 0% 91.9% 266 > 0 > > Buffered: cache reaches 0 in 2 min 30 sec: > > Too many video packets in the buffer: (4096 in 7959616 bytes). > Maybe you are playing a non-interleaved stream/file or the codec > failed? > For AVI files, try to force non-interleaved mode with the -ni option. > Cannot sync MAD frame > A: 292.7 V: 282.5 A-V: 10.188 ct: 12.419 8460/8460 3% 0% 24.8% 176 0 > 0% > > > With those debug settings I mentioned above, how often in the log to > you get the "Possibly falling behind" messages and messages about > putting buffers back into rotation? > > I see only two "Possibly falling behind" messages and none about > putting buffers back into rotation. I have attached the dmesg log. > > > I would think that sharing an interrupt with the nvidia > hardware/driver is not what you want to do. Maybe changing to a slot > that doesn't use that PCI IRQ line would help. Note slots 4 and slot > 5 in a chassis may not rotate the interrupt line traces on the > motherboard, so changing between those slots won't help. > > I moved the card to 18, but don't see any effect on the video. > > [EMAIL PROTECTED]:~$ grep cx18 /proc/interrupts > 18: 4608 4582 IO-APIC-fasteoi uhci_hcd:usb3, > ehci_hcd:usb4, uhci_hcd:usb7, cx18-0 > > What I find strange is how things work fine from the tuner card but > not s-video. I mean, its basically the same video stream. Different > code I guess? If the quality wasn't so poor on the tuner card, that > would be my solution! Thanks again.
OK. My hypothesis is the encoder is simply holding on to buffers longer because they're not full enough. This makes sense in your situation because fuzzy, snowy video doesn't compress as well as a very clean video signal, so the buffers that have compressed video from the tuner may get sent over more frequently because they fill up faster as opposed to buffers with compressed video from the s-video input. The only things at present I can advise are: 1. Try using v4l2-ctl to set the stream_type for MPEG TS instead of MPEG PS. Maybe it will help. 2. You'll have to wait until I have a fix that either allows users to set the transfer buffers sizes smaller via a module parameter or somehow coaxes the CX23418 firmware to send a buffer once per frame. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
