Patch to add support for Hauppage WinTV PVR Cards or any other MPEG2 encoder card

Description of Patch

This patch uses ffmpeg to open a specified video device as an mpeg stream from which to pull the images. It supports Hauppage WinTV PVR Cards (tested on WinTV PVR 500 MCE using ivtv drivers), so it should work with both the 150 and 250 based cards, as well. For that matter, it should support any card that provides an MPEG2 stream on /dev/video0 or on /dev/v4l/video0 or whatever.

Installation of Patch

Download the patch file. If it is packed as a gz or tar.gz unpack it first. Then copy it to the motion source directory and issue the command (assuming the patch file is called filename_of_patch_file.diff)

patch -p1 < filename_of_patch_file.diff

Then re-build Motion and test the patch.

Change History of Patch

• 1.0 Initial revision
• 1.3 New patch to support latest source (based on 2005-09-02 daily snapshot)
• 1.4 Added testing patch against motion-3.2.9 tag

Discussion and Comments

---

Nice initiative

And also something I would not mind integrating into Motion - but we have some work to do first.

• Your patch is for Motion 3.2.3. We have since made quite a lot of code changes, also in the aread that you have updated. It would be a great help if the patch was rewritten for the latest snap release MotionRelease3x2x4snap1. You can also make the patch against latest daily snap MotionDailySourceSnap.
• In the source tree you will find a file called CODE_STANDARD. Motion uses tabbed indentation and you have used a mix of tabs and 4-space indents so in my editor your code looks like it has a bad structure. We use tabs for indentation and only spaces when you break a long line and need to align the text on the next line below. If you look at the code with spaces and tabs visible in the editor you get the idea.
• It seems the patch hard codes the device names which makes it nice concept code but not something I can distribute. So we either need to autodetect the format or introduce a new option. It would be nice if we could auto detect but for future expansion to other codec and card types we may need a new option giving the input codec type: "video_input_codec".
• save_ppm?? What does it do. It seems like a test function never used (call commented out)
• There seems to be code between #ifdef WITHOUT_ffmpeg and #endif which is needed for V4L cameras. Is V4L disabled if ffmpeg is installed? Is it not possible to both have an mpeg card and a normal TV card or a USB camera? It should be naturally

But do not get it wrong. I am happy to see this patch and the most important part - the decoding with ffmpeg is a valuable piece of code. Maybe we can later also use it with netcams running mpeg2 or mpeg4.

-- KennethLavrsen - 02 Sep 2005

---

I have updated the patch to the motion-20050902-051001 build. Everything seems to work, except that when it captures video, it gives me errors like this from time to time:

[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]00 motion_type at 15 1
[mpeg2video @ 0x40370dd0]concealing 160 DC, 160 AC, 160 MV errors
[mpeg2video @ 0x40370dd0]skiped MB in I frame at 4 0
[mpeg2video @ 0x40370dd0]concealing 80 DC, 80 AC, 80 MV errors
[mpeg2video @ 0x40370dd0]concealing 65 DC, 65 AC, 65 MV errors
[mpeg2video @ 0x40370dd0]00 motion_type at 7 1
[mpeg2video @ 0x40370dd0]concealing 120 DC, 120 AC, 120 MV errors
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]MPEG motion vector out of boundary
[mpeg2video @ 0x40370dd0]concealing 124 DC, 124 AC, 124 MV errors
[mpeg2video @ 0x40370dd0]ac-tex damaged at 16 1
[mpeg2video @ 0x40370dd0]concealing 160 DC, 160 AC, 160 MV errors

I'm not sure if it is my patch that is causing these or if they are caused by some problem in the video stream encoding functions in ffmpeg.c. Anyway, attached is the new patch.

The new patch contains a new config operation called ffmpeg_device that, when set to 'on', it treats the device given in the config file as a ffmpeg compliant video stream. It also does not require v4l support anymore. It sports all-new functions called ffmpeg_start and ffmpeg_next to do the equivilant of what the v4l stuff did. It will also still call ioctl on the device when it starts to try to switch to the video channel specified in the config file.

Again, everything seems to be working on my WinTV PVR 500 MCE device. It detects motion, builds an mspeg4 stream, and mplayer plays it back just fine. In fact, this new version no longer has the major distortions around motion that the 3.2.3 version had.

Also, with the new patch, I think it should be possible to open a standard ffmpeg compliant video stream, regardless of whether it is a device, with little or no additional work. This means, it could read through a normal, already-built video and extract just the parts of the video that contain motion! So, it could be run as a post-processing step on full-length security videos to extract just the interesting parts.

-- EliotGable - 03 Sep 2005

---

Looks much better now. I have not yet tested it. I have been busy with other code changes but all in another area than you have worked so your patch will most likely patch pretty clean also on the 20050904.

I will most likely release a snap2 and your patch will not be in it. But it will be picked up in days and hopefully be in snap3.

When I integrated it I will probably discuss the form and factoring of the code in the light of PluginArchitectureDiscussion.

-- KennethLavrsen - 04 Sep 2005

---

-- TWikiGuest - 15 Dec 2005

---

The patch no longer applies to the latest snapshots so I had to hand edit it. I will attach is a patch that applies to 3.2.4 snap 5 and to todays snapshot. I have tested it with 3.2.4 snap 5 and it seems to work. You have to add the "ffmpeg_device on" option to the conf file (should be added to the template file) and you can't limit the framerate or the ivtv driver gets upset and starts dropping data and delivering corrupt mpeg2 data.

-- ErikCorry - 18 Feb 2006

---

I have attached a new patch, this time against the snapshot from last night (2006-02-18). This one includes the previous patch, but adds a new config option, discard_frames, which lets you read frames from the device at full speed, but only use one in n frames. This is necessary in order to use WinTV PVR cards at something other than the full 25 or 30 fps.

-- ErikCorry - 18 Feb 2006

---

Added a new patch with a single-character bug fix. For some reason the bug didn't trigger with the old version of ffmpeg, but it certainly did (causing a segfault) with the ffmpeg-0.4.9-12_cvs20060215.rhfc2.at version that ATrpms just rolled out.

-- ErikCorry - 20 Feb 2006

---

You will have to explain this new option discard_frames.

I do not understand it. And normal users certainly will not. It is needed? Is it possible to implement the function automatically instead of a config option?

Please consult KennethsNerdoMeter. We are probably at 5 or 6 now.

-- KennethLavrsen - 22 Feb 2006

---

discard_frames 4 means discard 4 frames for each frame you use. So a 25fps feed is reduced to 5 fps. You can't just set the normal framerate option (name forgotten) because then motion reads the frames slowly from the device which doesn't work with ivtv. Ivtv will buffer up unread frames until its buffering area is full, then start discarding data at random, resulting in a stream that is no longer valid mpeg2.

The correct solution is probably to modify the normal frame rate option so it has this sort of behaviour on ivtv (or perhaps all ffmpeg) devices. This involves autodetecting the frame rate (normally 25 or 30) so you know how much to discard.

-- ErikCorry - 22 Feb 2006

---

Doesn't seem to work for me with any versions of motion or ffmpeg. I'm running Fedora 5.

-- ZiemowitPierzycki - 25 Aug 2006

---

Fixed 3.2.3 patch for the official release (non-CVS). Supports multiple /dev/videoX devices, and supports FFMPEG 0.4.9 and newer.

Currently working on a working 3.2.7 version of the same. Still having a lot of mpeg artifact buffer problems (due to not having discard_frames working)

-- MicahMorton - 05 Apr 2007

---

Is there an equivalent patch available for motion version 3.2.8? I tried using 3.2.4 patch but as expected, it failed. I have a PVR 150 with IVTV driver which does not seem to support mmap.

-- JasjeetSingh - 08 Aug 2007

---

I've added a not tested patch against motion-3.2.9 tag :

mkdir motion
cd motion
svn co http://www.lavrsen.dk/svn/motion/tags/3.2.9 .
get the patch 
patch <  wintv-motion-3.2.9-test.diff

-- AngelCarpintero - 02 Feb 2008

---

any news on this?? bump

-- DavidSpuler - 10 Dec 2008

---

I don't have any card of that so cannot give any feedback ... a did some patches but not feedback , i cannot do anything more without feedback or a card.

-- AngelCarpintero - 11 Dec 2008

---

hello.. nice to read you! i got a pvr-150 video-card and using the latest version of motion. i do get the following error:

[3] No mmap falling back on read
[3] V4L capturing using read is deprecated!
[3] Motion now only supports mmap.
[3] Motion Exits.

when i 'cat /dev/video0 > test.mpg' a get a working video-stream. here's the ivtv-part of dmesg:

[56.932451] ivtv:  *================* START INIT IVTV *================*
[56.932458] ivtv:  version 0.10.1 (tagged release) loading
[56.932461] ivtv:  Linux version: 2.6.20-16-server SMP mod_unload 686
[56.932464] ivtv:  In case of problems please include the debug info between
[56.932468] ivtv:  the START INIT IVTV and END INIT IVTV lines, along with
[56.932471] ivtv:  any module options, when mailing the ivtv-users mailinglist.
[56.932682] ivtv0: Autodetected Hauppauge card (cx23416 based)
[56.933660] PCI: Enabling device 0000:02:09.0 (0110 -> 0112)
[56.933685] ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 21 (level, low) -> IRQ 20
[56.933711] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
[57.643932] ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
[57.909896] ivtv0: Encoder revision: 0x02050032
[57.909903] ivtv0: Recommended firmware version is 0x02060039.
[57.987993] tveeprom 0-0050: Hauppauge model 26034, rev C197, serial# 7768590
[57.988001] tveeprom 0-0050: tuner model is TCL 2002MB_3H (idx 97, type 55)
[57.988006] tveeprom 0-0050: TV standards PAL(B/G) PAL(D/D1/K) (eeprom 0x44)
[57.988011] tveeprom 0-0050: audio processor is CX25842 (idx 36)
[57.988014] tveeprom 0-0050: decoder processor is CX25842 (idx 29)
[57.988018] tveeprom 0-0050: has no radio, has IR receiver, has IR transmitter
[57.988024] ivtv0: Autodetected Hauppauge WinTV PVR-150
[57.988027] ivtv0: reopen i2c bus for IR-blaster support
[58.075936] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
[58.267093] cx25840 0-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0)
[61.965492] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
[62.047918]  sdd1
[62.048067] sd 2:0:0:0: Attached scsi disk sdd
[62.048151] sd 2:0:0:0: Attached scsi generic sg4 type 0
[62.078041] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
[62.129375] ivtv0: Registered device video0 for encoder MPEG (4 MB)
[62.129699] ivtv0: Registered device video32 for encoder YUV (2 MB)
[62.130002] ivtv0: Registered device vbi0 for encoder VBI (1 MB)
[62.130107] ivtv0: Registered device video24 for encoder PCM audio (1 MB)
[62.130505] tuner 0-0061: type set to 55 (TCL 2002MB)
[62.533691] ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
[62.533729] ivtv:  *================*  END INIT IVTV  *================*

i'd be pleased if you could help me.. if you need any further info just ask.. i'm using debian, Linux server 2.6.20-16-server #2 SMP Tue Feb 12 05:48:21 UTC 2008 i686 GNU/Linux

thanks in advance.. dave

-- DavidSpuler - 13 Dec 2008

---

I fixed your comment , when you said "i'm using last version" ... i understant is 3.2.11 ... there's no patch for that version. Patch is only working for 3.2.9 but probably

ffmpeg won't work. Sorry but this patch looks that is going to "die" if nobody takes some interest over it and do a good feeback and some contributor with a PVR card

maintain this patch.

-- AngelCarpintero - 14 Dec 2008

---

thanks for your answer.. is it a problem with the driver of the pvr-150-card or is it motion? is there a way to trick out motion with some kind of tool that emulates another mmap-supporting device? what can i do to get closer to the problem? do you need some more information? yes, i'm using 3.2.11..

-- DavidSpuler - 15 Dec 2008

---

Support for your card is only supposed to work with 3.2.9 and patch i did. For new version of motion a new patch must be done ... but this patch must be handled by someone with that card.

Won't be easy to have a stable patch using ffmpeg , there's not releases and API is changing quite frequently. So p.ex do a stable patch for 3.2.11 needs to be able to work with 5 differents API version

of ffmpeg. I'm so sorry but i cannot handle this patch anymore.

-- AngelCarpintero - 22 Dec 2008

---

Sorry to see this patch die out, I have several PVR500's and wanted to use one for security camera's on composite. and ya guessed it, the probable factor AngelCarpintero mentioned is playing up. Although I have programming skills, I sincerely doubt I could figure this one out but i'll give it a try.

-- XzaeLm - 16 Jan 2009

---

I would like to keep motion compatible with PVR but is really hard without user feedback ... i have bought a lot of capture cards / cctv cameras / webcams and netcams ...but it's almost imposible to do for all ...

so PVR donation will be good

P.D: Some people sent me cctv cams , capture cards, network cameras and webcams ... so it's easy to keep them supported them in motion.

-- AngelCarpintero - 17 Jan 2009

---

I found this: http://www.lavrsen.dk/twiki/bin/view/Motion/SupportQuestion2007x07x29x084400 and it was exactly what i was looking for.. now my door-cam over composite on pvr-150 works!!

-- DavidSpuler - 18 Feb 2009

---

Can't get this to work atall, running Ubuntu 9 kernel 2.6.31-14, used a few different versions of Motion. Using a Happauge WinTV-HVR-1600 74041 LF Rev C6B2

Seems like MPEG-2 > Motion compatibility would be a big plus, since most TV Tuner cards on the market use this now?

Got my KWorld "Crappy" $20 tuner to work, but not my $120 Happauge tuner?!?

Willing to be a guinea pig for this project!

-- MatthewRoss - 06 Jan 2010

---

Tried latest motion version with this patch and I get:

/usr/src/motion-patched/pvr/video_common.c:799: undefined reference to `img_convert'

Google tells me that img_convert was removed. One now needs to use swscale...

-- JeremyMcNamara - 10 Apr 2011

---

• wintv-motion-3.2.9-test.diff against 3.2.9 version.
• motion-3.2.11.1-pvr.diff against last stable version ( 3.2.11.1 ) .