Mailing List Archive

On Fri, 2013-12-27 at 00:24 +0100, Christian Schoebel wrote:
> Using Ubuntu 12.04 LTS
>
> kernel version:
> 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64
> x86_64 x86_64 GNU/Linu
>
>
> ivtv package from ubuntu repository:
> ivtv-utils/precise uptodate 1.4.1-2ubuntu1
>
>
> recorded MPG streams show a weird behavior when playing with VLC or
> avidemux:

You say "recorded" here, but below you imply live stream.

So first determine that playback is not a problem on the system. Get a
known good previous capture (mpeg file with an MPEG-2 PS), and try to
play it back with VLC, mplayer, or avidemux. It should play with no
problems.

Next determine if sequential capture and record with later playback
works properly. Record captured video to a file on a local, non-USB
connected, disk drive and then play it back after the capture is done:

# cat /dev/videoN > foo.mpg
(after however many minutes you need to capture, type a ctrl-C)
# mplayer foo.mpg

If this works OK, you have a system level problem or application problem
with keeping up reading the captured video data from the driver.

If this doesn't work well, it is likely the hardware or a problem with
your system (irq response latency or CPU available to the Real-Time
kthread ivtv sets up to do the irq work)



>
> The first minutes are without any seeable or hearable problems. After
> some minutes of recording there is stuttering of video and audio. It
> seems like some data is lost during recording.

If user space doesn't keep up with reading captured data, the CX23415
MPEG encoder will be starved of buffers and data will be dropped on the
floor.

>
> Increasing the debug level to 0x6ff did not show anything unusual as
> far as I can tell. The only thing that seems suspicious to me is the
> following: normally, it seems that reading from the MPG encoders
> triggers a DMA transfer:

They're mostly disconnected. unless the CX23415 is starved of buffers
because the application hasn't been reading data fast enough. But then
you should get warnings:
IVTV_DEBUG_WARN("Cannot obtain %d bytes for %s data transfer\n",

What you show below seems normal to me.


>
> "normal" process:
> [13395.120943] ivtv0: file: read 32768 from encoder MPG, got 32768
> [13395.121000] ivtv0: file: read 32768 bytes from encoder MPG

This is userspace reading 32 kB from the driver's buffers, which happens
to be exactly the size of one of the ivtv driver's internal buffers for
the MPEG stream. No problem there.

> [13395.132794] ivtv0: irq: ENC START CAP 0: 000f3ec0 0001b800

This is the CX23416 requesting a DMA to the host of 0x1b800 bytes (110
kB).

> [13395.132810] ivtv0: dma: DMA encoder MPG: 0x0001b800 bytes at
> 0x000f3ec0
> [13395.132821] ivtv0: dma: start DMA for encoder MPG

This is the ivtv driver setting up the buffers and kicking it off.

> [13395.133277] ivtv0: irq: ENC DMA COMPLETE 3 0 (0)
> [13395.133766] ivtv0: irq: ENC DMA COMPLETE 3 0 (0)
> [13395.134295] ivtv0: irq: ENC DMA COMPLETE 3 0 (0)
> [13395.134760] ivtv0: irq: ENC DMA COMPLETE 3 0 (0)
> [13395.134770] ivtv0: dma: DMA encoder MPG completed (f3ec0)

This is the DMA of 3 32 kB buffers and 1 partial 32 kB buffer (14 kB)
buffer to transfer the 110 kB from the CX23415 to the host/ivtv driver.


> But then there are sequences where three or four file: read 32768
> lines are, but only one DMA transfer occurs afterwards:
>
> [13395.134882] ivtv0: file: read 32768 from encoder MPG, got 32768
> [13395.134936] ivtv0: file: read 32768 bytes from encoder MPG
> [13395.135040] ivtv0: file: read 32768 from encoder MPG, got 32768
> [13395.135074] ivtv0: file: read 32768 bytes from encoder MPG
> [13395.135161] ivtv0: file: read 32768 from encoder MPG, got 32768
> [13395.135214] ivtv0: file: read 32768 bytes from encoder MPG
> [13395.135266] ivtv0: file: read 32768 from encoder MPG, got 32768
> [13395.135303] ivtv0: file: read 32768 bytes from encoder MPG

This looks like the read of the above 110 kB of data that was just DMAed
over. No problem here.

Note from the time the DMA was done .134770 to when the read
finished .135303 was ~0.5 milliseconds. Much shorter than an NTSC frame
time of 33.3 milliseconds.

Note that the time the enocder was ready to transfer .132794 to the time
the DMA was done .134770 was about 1.8 milliseconds. Much shorter than
an NTSC frame time of 33.3 milliseconds.

> [13395.200560] ivtv0: irq: ENC START CAP 0: 0010f6c0 0000b000

This is the enocder asking to transfer 0xb000 bytes (44 kB) over to the
host, 67.7 milliseconds after it's last request. That is about the time
of two NTSC frames (66.6 milliseconds), so a P and B frame I'd guess.
Or the PVR-350 skipped a video frame for some reason (digitizer lost
sync?).

> [13395.200578] ivtv0: dma: DMA encoder MPG: 0x0000b000 bytes at
> 0x0010f6c0
> [13395.200589] ivtv0: dma: start DMA for encoder MPG

This is the ivtv driver setting up the buffers and kicking it off.


> [13395.200985] ivtv0: irq: ENC DMA COMPLETE 3 0 (0)
> [13395.201347] ivtv0: irq: ENC DMA COMPLETE 3 0 (0)
> [13395.201354] ivtv0: dma: DMA encoder MPG completed (10f6c0)
>

This is the DMA of 1 32 kB buffer and 1 partial 32 kB buffer (12 kB)
buffer to transfer the 44 kB from the CX23416 to the host/ivtv driver.


>
> I have never experienced such a problem before, already did some
> recordings with this PVR350 without any data loss.

All PVR-350's are old. The first ones shipped in the US in Oct 2002, I
believe. Analog OTA TV cut off in the US in June 2009, so no NTSC units
should have be made after then. Any NTSC PVR-350 is at least 4.5 years
old and possibly as old as 11 years.

You could be seeing the first stage of the unit's demise. If it goes
for a while with no problem, maybe some extra cooling air will make
things better.



> I can't tell if it is a kernel update or something else which is the
> reason for this fault.

Roll back to a previous kernel and see if the problem persists.
In the past, kernel patches to the PCI subsytem regarding PCI chipset
quirks have had an adverse effect on the operation of
PVR-150/250/350's.

The ivtv driver itself has undergone very little change in it's IRQ
handling and DMA operation.

> rmmod ivtv and modprobe ivtv did not change anything, rebooting didn't
> help either; just did not try to power cycle so far. Perhaps the card
> needs 30 seconds without power? But I would have expected something in
> the logs ...
>
>
> Any suggestions for me what I should try next?
>
>
> Thanks in advance!

Regards,
Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users