Problem getting sensible video out of Hauppauge HVR-1100 composite
I'm in the UK (PAL), & have a Hauppauge HVR-1100 on Scientific Linux6:
2.6.32-358.18.1.el6.i686
libv4l-0.6.3-2.el6.i686
v4l-utils-0.9.0.git5f24b816-2.el6.i686
ivtv-firmware-20080701-20.2.noarch
Hauppauge WinTV-HVR1120 DVB-T/Hybrid [card=156,autodetected]
input: saa7134 IR (Hauppauge WinTV-HVR as /devices/pci0000:00/0000:00:14.4/0000:05:07.0/rc/rc1/input13
rc1: saa7134 IR (Hauppauge WinTV-HVR as /devices/pci0000:00/0000:00:14.4/0000:05:07.0/rc/rc1
input: MCE IR Keyboard/Mouse (saa7134) as /devices/virtual/input/input14
(I think that's the relevant firmware)
I set everything I know of up OK, but when I access /dev/video0 I get
a garbled pink MPEG file (cat to a file, then mplayer to test). The DVB-T aspect of is works fine (tested using vlc).
The only logger error I can see that might related is:
kernel: tda18271_write_regs: [2-0060|M] ERROR: idx = 0x25, len = 1, i2c_transfer returned: -5
kernel: tda18271_channel_configuration: [2-0060|M] error -5 on line 119
kernel: tda18271_set_analog_params: [2-0060|M] error -5 on line 1050
.. but I think that may be something else (I have another DVB card
plugged in).
I have:
$ v4l2-ctl -I Video input : 1 (Composite1: ok)
.. so I think it can see something. If I unplug the [known working]
composite feed I get:
$ v4l2-ctl -I Video input : 1 (Composite1: no hsync lock., no sync lock)
Lastly:
$ v4l2-ctl --all Driver Info (not using libv4l2): Driver name : saa7134 Card type : Hauppauge WinTV-HVR1120 DVB-T/H Bus info : PCI:0000:05:07.0 Driver version: 3.0.0 Capabilities : 0x05010015 Video Capture Video Overlay VBI Capture Tuner Read/Write Streaming Format Video Capture: Width/Height : 720/576 Pixel Format : 'BGR3' Field : Interlaced Bytes per Line: 2160 Size Image : 1244160 Colorspace : Unknown (00000000) Format Video Overlay: Left/Top : 0/0 Width/Height: 0/0 Field : Any Chroma Key : 0x00000000 Global Alpha: 0x00 Clip Count : 0 Clip Bitmap : No Format VBI Capture: Sampling Rate : 27000000 Hz Offset : 256 samples (9.48148e-06 secs after leading edge) Samples per Line: 2048 Sample Format : GREY Start 1st Field : 7 Count 1st Field : 16 Start 2nd Field : 319 Count 2nd Field : 16 Framebuffer Format: Capability : Clipping List Flags : Width : 0 Height : 0 Pixel Format : '' Bytes per Line: 0 Size image : 0 Colorspace : Unknown (00000000) Crop Capability Video Capture: Bounds : Left 0, Top 46, Width 720, Height 578 Default : Left 0, Top 48, Width 720, Height 576 Pixel Aspect: 54/59 Crop: Left 0, Top 48, Width 720, Height 576 Video input : 1 (Composite1: ok) Audio input : 0 (audio) Frequency: 0 (0.000000 MHz) Video Standard = 0x000000ff PAL-B/B1/G/H/I/D/D1/K Streaming Parameters Video Capture: Frames per second: invalid (0/0) Read buffers : 0 Tuner: Name : Television Capabilities : 62.5 kHz multi-standard stereo lang1 lang2 Frequency range : 0.0 MHz - 268435455.9 MHz Signal strength/AFC : 100%/0 Current audio mode : mono Available subchannels: mono Priority: 2
I had done a 'v4l2-ctl --set-fmt-video=width=720,height=576'
previously as that's what I've done on my old Hauppauge PVR-350, but don't recall why it was necessary, I was just trying anything I could. I'd also done 'v4l2-ctl --set-standard pal'.
Signature · 4 lines
[phoenix@fnx ~]# rm -f .signature [phoenix@fnx ~]# ls -l .signature ls: .signature: No such file or directory [phoenix@fnx ~]# exit
Quoted 3 lines
I set everything I know of up OK, but when I access
/dev/video0I get a
garbled pink MPEG file (cat to a file, then mplayer to test). The DVB-T aspect of is works fine (tested using vlc).
It doesn't have a MPEG hardware compressor like the 350, you are reading raw pixel data (160Mbps) from the device node.
Use an application that renders raw video data, such as TVTime.
- Steve
Signature · 2 lines
Steven Toth - Kernel Labs http://www.kernellabs.com
Around about 19/01/14 17:54, Steven Toth scribbled ...
Quoted 3 lines
It doesn't have a MPEG hardware compressor like the 350, you are reading raw pixel data (160Mbps) from the device node. Use an application that renders raw video data, such as TVTime.
Ah, OK, thanks, I managed to miss that.
I can get a picture out of it by using vlc's open-device. So it's
working.
But, flip me, it's spewing 800 MB+ for a minute's worth of video.
That'd be ~48GB for an hour's TV (the intention is to use this for a MythTV PVR).
Am I likely to be able to do anything about that? Even with
post-transcoding that's going to be an excessive amount of filing to deal with :-(
Signature · 4 lines
[phoenix@fnx ~]# rm -f .signature [phoenix@fnx ~]# ls -l .signature ls: .signature: No such file or directory [phoenix@fnx ~]# exit
Quoted 6 lines · Neil Bird
But, flip me, it's spewing 800 MB+ for a minute's worth of video. That'd
be ~48GB for an hour's TV (the intention is to use this for a MythTV PVR).Am I likely to be able to do anything about that? Even with
post-transcoding that's going to be an excessive amount of filing to deal with :-(
The device doesn't have an MPEG encoder - you're getting raw uncompressed video. You would either have to buy a different device that has an encoder or do software encoding in real-time to MPEG2 or H.264 if your goal is to store the video.
Devin
Signature · 2 lines
Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com
Quoted 10 lines
Quoted 3 lines
It doesn't have a MPEG hardware compressor like the 350, you are reading raw pixel data (160Mbps) from the device node. Use an application that renders raw video data, such as TVTime.
Ah, OK, thanks, I managed to miss that.
I can get a picture out of it by using vlc's open-device. So it's
working.
Quoted 6 lines
But, flip me, it's spewing 800 MB+ for a minute's worth of video. That'd
be ~48GB for an hour's TV (the intention is to use this for a MythTV PVR).Am I likely to be able to do anything about that? Even with
post-transcoding that's going to be an excessive amount of filing to deal with :-(
Generally not a good idea to do what you're doing. Generally a good idea to use a card with hardware compression features for a myth DVR.
Signature · 2 lines
Steven Toth - Kernel Labs http://www.kernellabs.com
Around about 20/01/14 18:34, Steven Toth scribbled ...
Quoted 2 lines
Generally not a good idea to do what you're doing. Generally a good idea to use a card with hardware compression features for a myth DVR.
Yeah; I'd spent so long trying to find a card with an s-video input
that was likely to work without too much grief that I plain forgot that they don't all have the built-in encoder and didn't check it.
S-video requirements are a dying breed, unfortunately.
Don't suppose you know of any? I see the Hauppauge HVR-2200 does,
but it looks like the drivers for that are a bit too “fresh” for me to be able to risk another blind purchase (and may require kernel 3.2+, where I'm on SL6 with 2.6.~32).
Signature · 4 lines
[phoenix@fnx ~]# rm -f .signature [phoenix@fnx ~]# ls -l .signature ls: .signature: No such file or directory [phoenix@fnx ~]# exit
Quoted 6 lines
S-video requirements are a dying breed, unfortunately.
Don't suppose you know of any? I see the Hauppauge HVR-2200 does, but it
looks like the drivers for that are a bit too “fresh” for me to be able to risk another blind purchase (and may require kernel 3.2+, where I'm on SL6 with 2.6.~32).
I'd backport the HVR2200 driver into 2.6.32 (it may already exist with analog features in .32 btw) and go with a 2200.
Signature · 2 lines
Steven Toth - Kernel Labs http://www.kernellabs.com
Around about 20/01/14 18:46, Steven Toth scribbled ...
Quoted 2 lines
I'd backport the HVR2200 driver into 2.6.32 (it may already exist with analog features in .32 btw) and go with a 2200.
Hah, not my first choice :)
Signature · 4 lines
[phoenix@fnx ~]# rm -f .signature [phoenix@fnx ~]# ls -l .signature ls: .signature: No such file or directory [phoenix@fnx ~]# exit