Hi.
I'm having problems with the image being displayed when playing mp3s from this plugin.
-the image_convert script that converts CD covers to mpgs runs -the image is cached -any image displayed with the first track displays fine -as soon as the 2nd track plays, the new image becomes pixelated (see attached)
I can display the cached mpg image fine outside of VDR (in 'Image Viewer'), but the mp3 plugin displays it as per the attached photo. It's the same for all converted images.
Any ideas?
On 03 Oct 2005 Simon Baxter linuxtv@nzbaxters.com wrote:
-as soon as the 2nd track plays, the new image becomes pixelated (see attached)
Does this depends on the firmware version you use? e.g. does it change if you go back to 261d?
The mp3 plugin doesn't do any processing to the image. It's passed unchanged to the driver.
Regards.
Sorry, I'm not sure what you mean by 261d? If you're referring to the mpg codec used, I'm just using mpeg2enc.
I've just changed from mp3-0.9.12 to mp3.0.9.13 and it's the same
It looks like the first image loaded is fine (whether cached or not) but as soon as there's a new image to display, it pixel-ates. Maybe something to do with when the plugin passes the mpeg image????
On Mon, 2005-10-03 at 10:11 +0000, Stefan Huelswitt wrote:
On 03 Oct 2005 Simon Baxter linuxtv@nzbaxters.com wrote:
-as soon as the 2nd track plays, the new image becomes pixelated (see attached)
Does this depends on the firmware version you use? e.g. does it change if you go back to 261d?
The mp3 plugin doesn't do any processing to the image. It's passed unchanged to the driver.
Regards.
On 03 Oct 2005 Simon Baxter linuxtv@nzbaxters.com wrote:
Sorry, I'm not sure what you mean by 261d? If you're referring to the mpg codec used, I'm just using mpeg2enc.
No, I'm refering to the firmware version of your DVB card.
Maybe something to do with when the plugin passes the mpeg image????
The data is passed unchanged to DeviceStillPicture().
Regards.
BTW: Is the HTML attachment really necessary?
On Montag 03 Oktober 2005 11:33, Simon Baxter wrote:
-any image displayed with the first track displays fine -as soon as the 2nd track plays, the new image becomes pixelated (see attached)
there is an
usleep(80000)
somewhere in the source. Does it help to increase that value? (this is a workaround around a driver/firmware bug)
Sorry, I'm not sure what you mean by 261d? If you're referring to the mpg codec used, I'm just using mpeg2enc.
No, I'm refering to the firmware version of your DVB card.
I'm running a Hauppauge WinTV Nova-T with vdr-xine as my soft device.
Maybe something to do with when the plugin passes the mpeg image????
The data is passed unchanged to DeviceStillPicture().
I thought the radio plugin did the same, but it's still image works fine. Can you give me any pointers on what I can do to troubleshoot?
BTW: Is the HTML attachment really necessary?
Sorry!
On Mon, 2005-10-03 at 13:09 +0200, Wolfgang Rohdewald wrote:
On Montag 03 Oktober 2005 11:33, Simon Baxter wrote:
-any image displayed with the first track displays fine -as soon as the 2nd track plays, the new image becomes pixelated (see attached)
there is an
usleep(80000)
somewhere in the source. Does it help to increase that value? (this is a workaround around a driver/firmware bug)
Yes there is, in player-mp3.c
I changed it to 100000, and it screwed up the mp3 playing and image. Changed it to 81000 and the image changing is as it was - pixelated after the first image/track change
any ideas?
On 03 Oct 2005 Simon Baxter linuxtv@nzbaxters.com wrote:
Sorry, I'm not sure what you mean by 261d? If you're referring to the mpg codec used, I'm just using mpeg2enc.
No, I'm refering to the firmware version of your DVB card.
I'm running a Hauppauge WinTV Nova-T with vdr-xine as my soft device.
Ok, so this may be a softdevice problem.
Maybe something to do with when the plugin passes the mpeg image????
The data is passed unchanged to DeviceStillPicture().
I thought the radio plugin did the same, but it's still image works fine. Can you give me any pointers on what I can do to troubleshoot?
Not really. I remember that there are two ways of displaying. StillPicture and sending as an iframe. May be this matters for softdevice.
Regards.
Hi,
Simon Baxter wrote:
On Mon, 2005-10-03 at 13:09 +0200, Wolfgang Rohdewald wrote:
On Montag 03 Oktober 2005 11:33, Simon Baxter wrote:
-any image displayed with the first track displays fine -as soon as the 2nd track plays, the new image becomes pixelated (see attached)
there is an
usleep(80000)
somewhere in the source. Does it help to increase that value? (this is a workaround around a driver/firmware bug)
Yes there is, in player-mp3.c
I changed it to 100000, and it screwed up the mp3 playing and image. Changed it to 81000 and the image changing is as it was - pixelated after the first image/track change
any ideas?
I'm running VDR-1.3.33, vdr-xine-0.7.6 and vdr-mp3-0.9.13 (the latter with no source changes) and cannot reproduce your behaviour, at least not with just two sample images for two sample mp3 files.
Which version of mjpegtools do you use?
I remember a bug in mpeg2enc before mjpegtools-1.6.3-rc1 which failed to encode a test stream. But this is most likely not the problem in your case. To get my version of mpeg2enc working with the convert script, I had to add "-S 420mpeg2" to ppmtoy4m.
Maybe it has something to do with xine: how do run xine?
Bye.
I'm running VDR-1.3.33, vdr-xine-0.7.6 and vdr-mp3-0.9.13 (the latter with no source changes) and cannot reproduce your behaviour, at least not with just two sample images for two sample mp3 files.
I'm just trying to replicate your setup now. But the 0.7.6 vdr-xine won't compile, so am trying to get a new xine CVS to patch and complile, but the xine-ui won't checkout..? I'm getting "cvs [checkout aborted]: end of file from server (consult above messages if any)" xine-lib checked out fine.
Which version of mjpegtools do you use?
1.6.3-rc2
I remember a bug in mpeg2enc before mjpegtools-1.6.3-rc1 which failed to encode a test stream. But this is most likely not the problem in your case. To get my version of mpeg2enc working with the convert script, I had to add "-S 420mpeg2" to ppmtoy4m.
Yeah, I found the same and had to change the 420mpeg2. It's not that though as the mpg creates fine, just doesn't view properly in VDR/xine
Maybe it has something to do with xine: how do run xine?
I use sessions in gnome to automatically run the attached script. Nothing clever...
Hi,
Simon Baxter wrote:
I'm running VDR-1.3.33, vdr-xine-0.7.6 and vdr-mp3-0.9.13 (the latter with no source changes) and cannot reproduce your behaviour, at least not with just two sample images for two sample mp3 files.
I'm just trying to replicate your setup now. But the 0.7.6 vdr-xine won't compile, so am trying to get a new xine CVS to patch and complile,
From the error messages I'd conclude that you didn't patch (compile and install) your xine with the patches contained in vdr-xine-0.7.6.
but the xine-ui won't checkout..? I'm getting "cvs [checkout aborted]: end of file from server (consult above messages if any)" xine-lib checked out fine.
Well, this depends on the load at sourceforge.net. Just give it a further try some time later.
As there have been many changes in xine CVS I'm not sure whether my patches can be applied without failure. I still use the (most recent) snapshot available on my homepage.
Maybe it has something to do with xine: how do run xine?
I use sessions in gnome to automatically run the attached script. Nothing clever...
Well, as your command line doesn't specify any output drivers (-V / -A) I cannot verify this on my system. You may want to send me your ~/.xine/config.
In my test from yesterday I ran xine like this:
xine --verbose=2 -V xv -A alsa -L -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 --post vdr_video --post vdr_audio vdr:/tmp/vdr-xine/stream#demux:mpeg_pes
Bye.
I'm running VDR-1.3.33, vdr-xine-0.7.6 and vdr-mp3-0.9.13 (the latter with no source changes) and cannot reproduce your behaviour, at least not with just two sample images for two sample mp3 files.
Hi.
I'm now running exactly the same versions as you and am still getting the image corruption thing. The converted images work fine, for the first (and sometimes second) sound clip but when the clip and image change, it's the same.
I have a feeling it might be something to do with the dri driver for the tv-out.
Any other ideas?
Hi,
Simon Baxter wrote:
I'm running VDR-1.3.33, vdr-xine-0.7.6 and vdr-mp3-0.9.13 (the latter with no source changes) and cannot reproduce your behaviour, at least not with just two sample images for two sample mp3 files.
I'm now running exactly the same versions as you and am still getting the image corruption thing. The converted images work fine, for the first (and sometimes second) sound clip but when the clip and image change, it's the same.
I have a feeling it might be something to do with the dri driver for the tv-out.
Any other ideas?
Please give "-V xshm" a try. If it works properly, then it is an issue of this specific output driver.
Bye.
Please give "-V xshm" a try. If it works properly, then it is an issue of this specific output driver.
Hi.
It's the same with all output drivers. The MPEGs play fine with 'xine - l <file.mpeg>
I'm starting xine with "xine -V xshm --verbose=2 -f --hide-gui -A alsa - L --post vdr_video --post vdr_audio vdr://tmp/vdr- xine/stream#demux:mpeg_pes"
Am getting nothing odd in the Xine messages. Here's what I get when the image doesn't appear corrupted.
Image cached ok : fixing sound card drift by 1250 pts +++ CLEAR(4) ao_flush (loop running: 1) --- CLEAR(4) video_out: throwing away image with pts 1250237 because it's too old (diff : 1300035). vdr: flush: n: 1, 6.6 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. fixing sound card drift by -3193 pts fixing sound card drift by -2373 pts fixing sound card drift by -1771 pts fixing sound card drift by -1321 pts
+++ CLEAR(3) ao_flush (loop running: 1) --- CLEAR(3) video_out: throwing away image with pts 3860179 because it's too old (diff : 823091). vdr: flush: n: 1, 6.9 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. audio_out: inserting 20134 0-frames to fill a gap of 41153 pts
...and these when it is.
Image trashed :
+++ CLEAR(6) ao_flush (loop running: 1) --- CLEAR(6) vdr_video: osd: (0, 0)-(704, 576) video_out: throwing away image with pts 1257437 because it's too old (diff : 5592922). vdr: flush: n: 1, 6.8 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. fixing sound card drift by -1871 pts video_out: throwing away image with pts 1261037 because it's too old (diff : 5682191). fixing sound card drift by -1380 pts vdr: flush: n: 321, 2265.3 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done.
+++ CLEAR(0) ao_flush (loop running: 1) --- CLEAR(0) vdr_video: osd: (0, 0)-(704, 576) video_out: throwing away image with pts 665873 because it's too old (diff : 939307). vdr: flush: n: 1, 7.0 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. fixing sound card drift by -1571 pts video_out: throwing away image with pts 669473 because it's too old (diff : 1027725). vdr: flush: n: 320, 2260.2 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done.
+++ CLEAR(5) ao_flush (loop running: 1) --- CLEAR(5) vdr_video: osd: (0, 0)-(704, 576) video_out: throwing away image with pts 3867379 because it's too old (diff : 3398502). vdr: flush: n: 1, 6.7 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. audio_out: inserting 9851 0-frames to fill a gap of 20135 pts video_out: throwing away image with pts 3870979 because it's too old (diff : 3488215). vdr: flush: n: 319, 2262.1 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done.
Am I missing something??
Hi,
Simon Baxter wrote:
Please give "-V xshm" a try. If it works properly, then it is an issue of this specific output driver.
It's the same with all output drivers. The MPEGs play fine with 'xine - l <file.mpeg>
Can you provide me a couple of your mpeg files?
Bye.
-
Reinhard Nissl -
s.huelswitt＠gmx.de -
Simon Baxter -
Wolfgang Rohdewald