Re: [ivtv-devel] Fixed bug in trunk, please test!
On Saturday 03 February 2007 04:25, Brad Barnett wrote: I'm wondering, would the x.org people take possession of this driver? At least then, it would probably be modified if other parts of X required it... When ivtv is in the kernel and has a stable well defined API, then this is indeed the intention. No point in doing this right now since the API is going to change anyway. Hans On Fri, 2 Feb 2007 19:18:59 -0500 Ricardo Lugo [EMAIL PROTECTED] wrote: On Feb 2, 2007, at 3:36 PM, John Harvey wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Armstrong Sent: 02 February 2007 17:52 To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] Fixed bug in trunk, please test! On Friday 02 February 2007 16:40, Ricardo Lugo wrote: On Feb 2, 2007, at 7:58 AM, Ian Armstrong wrote: On Friday 02 February 2007 03:21, Ricardo Lugo wrote: Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? Try the following two patches. These are done against the trunk version of the X driver. The first patch just brings it more up to date. The second is the endian patch. I may have got the byte swap wrong. If I have, the code is located in the FBshadowUpdatePacked routine in ivtvdev.c. It's easy enough to understand. The colors are right on! And it doesn't seem as though there is too much overhead when using mplayer -vo xv. BUT while playing a recording on the decoder in MythTV (or watching Live TV), the OSD colors are messed up as before. MythTV bypasses X writes direct to the osd. The fix could have gone into the ivtv driver itself but I'm reluctant to do this. If you move the byte-swap code into the ivtv driver, you would have to disable the osd dma for anything other than an 8 bit display. MythTV redraws the entire 32 bit display several times a second when playing an mpeg through the 350, so the cpu load would be horrendous. The best fix would be to do the byte-swap in MythTV itself, as it could still take advantage of the dma transfer for the osd updates. I have no idea what would be involved in getting MythTV to render in the correct byte order. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel It should be fairly easy to do in myth and I agree that is the better place to do it, otherwise we will end up with yet another copy of the data being stored in the driver before it can be DMA'd. Now that Xv is working though Myth can use that and avoid talking to the frame buffer/decoder directly. That sounds like a great idea (ie a very stable idea). Well, if whoever has access to the ivtvdriver.org website would mind copying the PPC xdriver binary off of my site and changing the link on the wiki, I would be very thankful. It is the trunk xdriver with Ian's 2 patches, compiled for Xorg 6.9.0 under Slackintosh 11.0. http://tube.dnsalias.net/~rick/ivtv/ivtvdev_drv.so.gz Many thanks, everyone! - Rick JOhn ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Friday 02 February 2007 03:21, Ricardo Lugo wrote: Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? Try the following two patches. These are done against the trunk version of the X driver. The first patch just brings it more up to date. The second is the endian patch. I may have got the byte swap wrong. If I have, the code is located in the FBshadowUpdatePacked routine in ivtvdev.c. It's easy enough to understand. Also, it depends on X_BYTE_ORDER being set to X_BIG_ENDIAN. I'm not sure if that's the correct way or not. You may see it when you 'make' the driver. On my setup I see '-DX_BYTE_ORDER=X_LITTLE_ENDIAN'. http://www.iarmst.demon.co.uk/test/xdriver-update.patch http://www.iarmst.demon.co.uk/test/xdriver-endian.patch As an aside, would it be possible to change X's color map to balance out the endian-swapped color scheme? Not once you drop to 16 bit mode. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Feb 2, 2007, at 7:58 AM, Ian Armstrong wrote: On Friday 02 February 2007 03:21, Ricardo Lugo wrote: Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? Try the following two patches. These are done against the trunk version of the X driver. The first patch just brings it more up to date. The second is the endian patch. I may have got the byte swap wrong. If I have, the code is located in the FBshadowUpdatePacked routine in ivtvdev.c. It's easy enough to understand. The colors are right on! And it doesn't seem as though there is too much overhead when using mplayer -vo xv. BUT while playing a recording on the decoder in MythTV (or watching Live TV), the OSD colors are messed up as before. Also, it depends on X_BYTE_ORDER being set to X_BIG_ENDIAN. I'm not sure if that's the correct way or not. You may see it when you 'make' the driver. On my setup I see '-DX_BYTE_ORDER=X_LITTLE_ENDIAN'. -DX_BYTE_ORDER=X_BIG_ENDIAN was there. - Rick ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Friday 02 February 2007 16:40, Ricardo Lugo wrote: On Feb 2, 2007, at 7:58 AM, Ian Armstrong wrote: On Friday 02 February 2007 03:21, Ricardo Lugo wrote: Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? Try the following two patches. These are done against the trunk version of the X driver. The first patch just brings it more up to date. The second is the endian patch. I may have got the byte swap wrong. If I have, the code is located in the FBshadowUpdatePacked routine in ivtvdev.c. It's easy enough to understand. The colors are right on! And it doesn't seem as though there is too much overhead when using mplayer -vo xv. BUT while playing a recording on the decoder in MythTV (or watching Live TV), the OSD colors are messed up as before. MythTV bypasses X writes direct to the osd. The fix could have gone into the ivtv driver itself but I'm reluctant to do this. If you move the byte-swap code into the ivtv driver, you would have to disable the osd dma for anything other than an 8 bit display. MythTV redraws the entire 32 bit display several times a second when playing an mpeg through the 350, so the cpu load would be horrendous. The best fix would be to do the byte-swap in MythTV itself, as it could still take advantage of the dma transfer for the osd updates. I have no idea what would be involved in getting MythTV to render in the correct byte order. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Armstrong Sent: 02 February 2007 17:52 To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] Fixed bug in trunk, please test! On Friday 02 February 2007 16:40, Ricardo Lugo wrote: On Feb 2, 2007, at 7:58 AM, Ian Armstrong wrote: On Friday 02 February 2007 03:21, Ricardo Lugo wrote: Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? Try the following two patches. These are done against the trunk version of the X driver. The first patch just brings it more up to date. The second is the endian patch. I may have got the byte swap wrong. If I have, the code is located in the FBshadowUpdatePacked routine in ivtvdev.c. It's easy enough to understand. The colors are right on! And it doesn't seem as though there is too much overhead when using mplayer -vo xv. BUT while playing a recording on the decoder in MythTV (or watching Live TV), the OSD colors are messed up as before. MythTV bypasses X writes direct to the osd. The fix could have gone into the ivtv driver itself but I'm reluctant to do this. If you move the byte-swap code into the ivtv driver, you would have to disable the osd dma for anything other than an 8 bit display. MythTV redraws the entire 32 bit display several times a second when playing an mpeg through the 350, so the cpu load would be horrendous. The best fix would be to do the byte-swap in MythTV itself, as it could still take advantage of the dma transfer for the osd updates. I have no idea what would be involved in getting MythTV to render in the correct byte order. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel It should be fairly easy to do in myth and I agree that is the better place to do it, otherwise we will end up with yet another copy of the data being stored in the driver before it can be DMA'd. Now that Xv is working though Myth can use that and avoid talking to the frame buffer/decoder directly. JOhn ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Feb 2, 2007, at 3:36 PM, John Harvey wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Armstrong Sent: 02 February 2007 17:52 To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] Fixed bug in trunk, please test! On Friday 02 February 2007 16:40, Ricardo Lugo wrote: On Feb 2, 2007, at 7:58 AM, Ian Armstrong wrote: On Friday 02 February 2007 03:21, Ricardo Lugo wrote: Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? Try the following two patches. These are done against the trunk version of the X driver. The first patch just brings it more up to date. The second is the endian patch. I may have got the byte swap wrong. If I have, the code is located in the FBshadowUpdatePacked routine in ivtvdev.c. It's easy enough to understand. The colors are right on! And it doesn't seem as though there is too much overhead when using mplayer -vo xv. BUT while playing a recording on the decoder in MythTV (or watching Live TV), the OSD colors are messed up as before. MythTV bypasses X writes direct to the osd. The fix could have gone into the ivtv driver itself but I'm reluctant to do this. If you move the byte-swap code into the ivtv driver, you would have to disable the osd dma for anything other than an 8 bit display. MythTV redraws the entire 32 bit display several times a second when playing an mpeg through the 350, so the cpu load would be horrendous. The best fix would be to do the byte-swap in MythTV itself, as it could still take advantage of the dma transfer for the osd updates. I have no idea what would be involved in getting MythTV to render in the correct byte order. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel It should be fairly easy to do in myth and I agree that is the better place to do it, otherwise we will end up with yet another copy of the data being stored in the driver before it can be DMA'd. Now that Xv is working though Myth can use that and avoid talking to the frame buffer/decoder directly. That sounds like a great idea (ie a very stable idea). Well, if whoever has access to the ivtvdriver.org website would mind copying the PPC xdriver binary off of my site and changing the link on the wiki, I would be very thankful. It is the trunk xdriver with Ian's 2 patches, compiled for Xorg 6.9.0 under Slackintosh 11.0. http://tube.dnsalias.net/~rick/ivtv/ivtvdev_drv.so.gz Many thanks, everyone! - Rick JOhn ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
I'm wondering, would the x.org people take possession of this driver? At least then, it would probably be modified if other parts of X required it... On Fri, 2 Feb 2007 19:18:59 -0500 Ricardo Lugo [EMAIL PROTECTED] wrote: On Feb 2, 2007, at 3:36 PM, John Harvey wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Armstrong Sent: 02 February 2007 17:52 To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] Fixed bug in trunk, please test! On Friday 02 February 2007 16:40, Ricardo Lugo wrote: On Feb 2, 2007, at 7:58 AM, Ian Armstrong wrote: On Friday 02 February 2007 03:21, Ricardo Lugo wrote: Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? Try the following two patches. These are done against the trunk version of the X driver. The first patch just brings it more up to date. The second is the endian patch. I may have got the byte swap wrong. If I have, the code is located in the FBshadowUpdatePacked routine in ivtvdev.c. It's easy enough to understand. The colors are right on! And it doesn't seem as though there is too much overhead when using mplayer -vo xv. BUT while playing a recording on the decoder in MythTV (or watching Live TV), the OSD colors are messed up as before. MythTV bypasses X writes direct to the osd. The fix could have gone into the ivtv driver itself but I'm reluctant to do this. If you move the byte-swap code into the ivtv driver, you would have to disable the osd dma for anything other than an 8 bit display. MythTV redraws the entire 32 bit display several times a second when playing an mpeg through the 350, so the cpu load would be horrendous. The best fix would be to do the byte-swap in MythTV itself, as it could still take advantage of the dma transfer for the osd updates. I have no idea what would be involved in getting MythTV to render in the correct byte order. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel It should be fairly easy to do in myth and I agree that is the better place to do it, otherwise we will end up with yet another copy of the data being stored in the driver before it can be DMA'd. Now that Xv is working though Myth can use that and avoid talking to the frame buffer/decoder directly. That sounds like a great idea (ie a very stable idea). Well, if whoever has access to the ivtvdriver.org website would mind copying the PPC xdriver binary off of my site and changing the link on the wiki, I would be very thankful. It is the trunk xdriver with Ian's 2 patches, compiled for Xorg 6.9.0 under Slackintosh 11.0. http://tube.dnsalias.net/~rick/ivtv/ivtvdev_drv.so.gz Many thanks, everyone! - Rick JOhn ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Thursday 01 February 2007 03:42, Ricardo Lugo wrote: snip Big-Endian systems are good to go ENC and DEC-wise. And it seems that the problems plaguing SMP machines are no more (at least on PPC SMP machines :-). I can see a pattern emerging with these byteswaps. I will try to figure out what is wrong with the colors on the PPC FrameBuffer (hopefully it is something simple). Any hints on variables/functions that might determine the colors? Some graphic cards can be configured to match the cpu endian. Unfortunately I've not been able to find a method of doing this on the 350. This means that software has to do the byte swapping. I've had a quick look at this, and from what I can make out, the only way to fix the problem with X is through the X driver itself. If you can compile run the ivtv X driver, you're part way there. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Thursday 01 February 2007 03:42, Ricardo Lugo wrote: snip Big-Endian systems are good to go ENC and DEC-wise. And it seems that the problems plaguing SMP machines are no more (at least on PPC SMP machines :-). I can see a pattern emerging with these byteswaps. I will try to figure out what is wrong with the colors on the PPC FrameBuffer (hopefully it is something simple). Any hints on variables/functions that might determine the colors? Some graphic cards can be configured to match the cpu endian. Unfortunately I've not been able to find a method of doing this on the 350. This means that software has to do the byte swapping. I've had a quick look at this, and from what I can make out, the only way to fix the problem with X is through the X driver itself. If you can compile run the ivtv X driver, you're part way there. I can confirm that it is not possible. While it is apparently possible in the firmware, the extra processing requirements mean that other items do not work anymore. At least, that is what I heard. Anyway, it isn't much of a problem to do an extra swap. Regards, Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Monday 29 January 2007 07:58, Hans Verkuil wrote: Hi all, I had hoped to make a release candidate this weekend, but a nasty bug was found which took me the whole Sunday to track down and fix. While testing that bug fix I may have found another bug, so I'll have to do more testing before I can make a release candidate. However, for all cards except the pvr350 it looks like it should work fine, so please test the current trunk! Also test with MythTV with VBI: it should work fine now! Fixed a bunch of subtle VBI-related bugs this week and the encoder looks really stable. I still have a race condition in the MPEG decoder somewhere but I hope to find that tomorrow or Saturday. Unfortunately it can take a long time before this bug hits so it is quite time consuming. Unless something new crops up I intend to make a candidate release this weekend, even if I can't find the decoder bug. Regards, Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
Ian, I compiled the PPC binary that's on the wiki at the moment. What changes would I have to make to the source? As an aside, would it be possible to change X's color map to balance out the endian-swapped color scheme? - Rick On Feb 1, 2007, at 3:41 AM, Ian Armstrong wrote: On Thursday 01 February 2007 03:42, Ricardo Lugo wrote: snip Big-Endian systems are good to go ENC and DEC-wise. And it seems that the problems plaguing SMP machines are no more (at least on PPC SMP machines :-). I can see a pattern emerging with these byteswaps. I will try to figure out what is wrong with the colors on the PPC FrameBuffer (hopefully it is something simple). Any hints on variables/functions that might determine the colors? Some graphic cards can be configured to match the cpu endian. Unfortunately I've not been able to find a method of doing this on the 350. This means that software has to do the byte swapping. I've had a quick look at this, and from what I can make out, the only way to fix the problem with X is through the X driver itself. If you can compile run the ivtv X driver, you're part way there. -- Ian ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans Verkuil Sent: 30 January 2007 06:45 To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] Fixed bug in trunk, please test! On Tuesday 30 January 2007 01:51, Ricardo Lugo wrote: Hans, I've got lots of Unknowns going on, and a broken stream. I've attached the entire log for a 30-minute show that has glitches every minute or so. Keep in mind I'm on PPC, but I hope it helps. - Rick What did you use for recording? I know ps-analyzer won't work with vdr since vdr translates the program stream to a transport stream. I'm not sure what MythTV does (anyone know?). I'm pretty confident Myth just writes the data straight to disk and doesn't do any translation. John ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On 1/29/07, Hans Verkuil [EMAIL PROTECTED] wrote: On 1/29/07, Hans Verkuil [EMAIL PROTECTED] wrote: First test results: 1. This module is a little pickier about the firmware, it won't accept the greatest and latest pvr-500 fw from hauppauge (based on size), too bad, I had good results with it. :/ Read the README notes: it's the same firmware, just without the garbage at the end. My sincere apologies. I didn't read the readme and thought 'newer is better'... 2. It loads ok, and works. 3. Without vbi in mythtv tested recording 2 streams at the same time, this results in occasional glitches again, and they seem to be more prevalent than the old 0.9.2 (svn) module. 4. With vbi on, there are occasional freezes, glitches and audio glitches now. Do you see any messages in the kernel log? I've been testing a little since my last message and there are no kernel messages at all while using MythTV. Dmesg is silent as well. I updated svn yesterday and I'm now at 3756. The glitches are still there with vbi on, but very infrequent. Without vbi single tuner operation seems fine, but occasional glitches can be seen when using 2 tuners at the same time. The vbi glitches visually differ from the dual tuner ones, in the way that the vbi ones are 'harder' and a little bigger (see my first post with picture), the others are mostly half a row of mpg blocks and mostly transparant by nature, so visualy 'softer'. The 'with-vbi' ps stream (with glitches) has a lot of unknown packets, the 'without vbi' streams none. Regards, Martin -- if but was of any use, it would be a logic operator ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Jan 30, 2007, at 1:45 AM, Hans Verkuil wrote: On Tuesday 30 January 2007 01:51, Ricardo Lugo wrote: Hans, I've got lots of Unknowns going on, and a broken stream. I've attached the entire log for a 30-minute show that has glitches every minute or so. Keep in mind I'm on PPC, but I hope it helps. - Rick What did you use for recording? I know ps-analyzer won't work with vdr since vdr translates the program stream to a transport stream. I'm not sure what MythTV does (anyone know?). Hans, I used MythTV, which I believe dumps the MPEG2-PS straight to disk. But more likely is that ps-analyzer is not big-endian safe. Hrm. Well, regardless of whether or not ps-analyzer was messed up, making recordings using trunk on my PPC machine leads to a very glitchy recording. Can you give me a hexdump of the start of that same recording? E.g.: head -c 256 foo.mpg | od -t x1 I've attached the result of that command. [EMAIL PROTECTED]:/mnt/store head -c 256 1010_2007012919.mpg | od -t x1 000 ba 01 00 00 44 00 04 00 04 01 01 07 af f8 00 00 020 01 bb 00 12 80 83 d7 04 e1 7f b9 e0 e8 b8 c0 20 040 bd e0 3a bf e0 02 00 00 01 e0 07 d4 80 c1 0d 31 060 00 03 19 8d 11 00 01 d3 2b 1e 60 e8 00 00 01 b3 100 2d 01 e0 24 0c 35 23 82 10 10 10 10 10 10 10 10 120 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 140 10 10 10 10 20 20 20 10 10 10 10 10 10 10 20 20 160 20 20 20 20 20 20 20 20 20 20 20 20 20 20 30 30 200 20 20 30 30 30 40 40 50 00 00 01 b5 14 82 00 01 220 00 00 00 00 01 b8 00 08 00 40 00 00 01 00 00 8f 240 ff f8 00 00 01 b5 8f ff f3 80 00 00 00 01 01 2a 260 8f f0 7a 52 91 b4 bd 46 e9 00 62 94 e0 2a db b0 300 16 15 68 25 96 04 c9 d8 81 50 01 9e 04 2f f8 e0 320 8e 00 78 08 57 b5 8e 46 6c 00 3f b5 2f ae c5 29 340 4a 77 df ab ab 98 4f cd ed 49 01 00 14 58 0a 16 360 02 b2 c0 06 36 46 99 28 15 2f 85 56 bb 6d 00 3e 400 Many thanks Hans! - Rick Thanks, Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Tuesday 30 January 2007 14:37, Ricardo Lugo wrote: On Jan 30, 2007, at 1:45 AM, Hans Verkuil wrote: On Tuesday 30 January 2007 01:51, Ricardo Lugo wrote: Hans, I've got lots of Unknowns going on, and a broken stream. I've attached the entire log for a 30-minute show that has glitches every minute or so. Keep in mind I'm on PPC, but I hope it helps. - Rick What did you use for recording? I know ps-analyzer won't work with vdr since vdr translates the program stream to a transport stream. I'm not sure what MythTV does (anyone know?). Hans, I used MythTV, which I believe dumps the MPEG2-PS straight to disk. But more likely is that ps-analyzer is not big-endian safe. Hrm. Well, regardless of whether or not ps-analyzer was messed up, making recordings using trunk on my PPC machine leads to a very glitchy recording. Can you give me a hexdump of the start of that same recording? E.g.: head -c 256 foo.mpg | od -t x1 I've attached the result of that command. Aha! That helped. There was a swap missing for big endian systems. It should now work. I've also made ps-analyzer big-endian capable (I hope). Please test again! Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On 1/29/07, Hans Verkuil [EMAIL PROTECTED] wrote: Hi all, I had hoped to make a release candidate this weekend, but a nasty bug was found which took me the whole Sunday to track down and fix. While testing that bug fix I may have found another bug, so I'll have to do more testing before I can make a release candidate. However, for all cards except the pvr350 it looks like it should work fine, so please test the current trunk! Also test with MythTV with VBI: it should work fine now! First test results: 1. This module is a little pickier about the firmware, it won't accept the greatest and latest pvr-500 fw from hauppauge (based on size), too bad, I had good results with it. :/ 2. It loads ok, and works. 3. Without vbi in mythtv tested recording 2 streams at the same time, this results in occasional glitches again, and they seem to be more prevalent than the old 0.9.2 (svn) module. 4. With vbi on, there are occasional freezes, glitches and audio glitches now. Regards, Martin ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On 1/29/07, Hans Verkuil [EMAIL PROTECTED] wrote: Hi all, I had hoped to make a release candidate this weekend, but a nasty bug was found which took me the whole Sunday to track down and fix. While testing that bug fix I may have found another bug, so I'll have to do more testing before I can make a release candidate. However, for all cards except the pvr350 it looks like it should work fine, so please test the current trunk! Also test with MythTV with VBI: it should work fine now! First test results: 1. This module is a little pickier about the firmware, it won't accept the greatest and latest pvr-500 fw from hauppauge (based on size), too bad, I had good results with it. :/ Read the README notes: it's the same firmware, just without the garbage at the end. 2. It loads ok, and works. 3. Without vbi in mythtv tested recording 2 streams at the same time, this results in occasional glitches again, and they seem to be more prevalent than the old 0.9.2 (svn) module. 4. With vbi on, there are occasional freezes, glitches and audio glitches now. Do you see any messages in the kernel log? Thanks, Hans Regards, Martin ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
Hans Verkuil wrote: A follow-up: the latest trunk version has a new tool: ps-analyzer. If you have recordings with glitches then please run this tool over the recording (ps-analyzer foo.mpg). It gives a full dump of all the pack headers in the mpeg stream. I recommend using something like: ps-analyzer foo.mpg | grep -2 Unknown The main feature is that when the file has a corrupt structure, then the analyzer reports 'Unknown packet' messages and/or stops with an 'missing pack marker' error. Note that the message 'broken stream' is not an error, it just means that the file ended in the middle of a MPEG packet. Basically if ps-analyzer doesn't report any problems in the recording, then I'd say the recording is correct and something else is going on. That is sweet, gonna help with debugging. Thans, Hans! Steve ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] Fixed bug in trunk, please test!
On Tuesday 30 January 2007 05:17, Steve Dibb wrote: Hans Verkuil wrote: A follow-up: the latest trunk version has a new tool: ps-analyzer. If you have recordings with glitches then please run this tool over the recording (ps-analyzer foo.mpg). It gives a full dump of all the pack headers in the mpeg stream. I recommend using something like: ps-analyzer foo.mpg | grep -2 Unknown The main feature is that when the file has a corrupt structure, then the analyzer reports 'Unknown packet' messages and/or stops with an 'missing pack marker' error. Note that the message 'broken stream' is not an error, it just means that the file ended in the middle of a MPEG packet. Basically if ps-analyzer doesn't report any problems in the recording, then I'd say the recording is correct and something else is going on. That is sweet, gonna help with debugging. Thans, Hans! Note that this is for MPEG-2 program streams only! It won't handle transport stream. Regards, Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
