Hi!
I have been using ancient versions of VDR 1.4.5 and dxr3plugin 0.2.6 for years now, with no real problems. For some reason I decided to try the recent versions. :) VDR 1.7.15 and dxr3plugin 0.2.10.
VDR starts and works. It can record, and with streamdev I can watch live video on my laptop... So VDR is receiving everything correctly.
However there's no picture or sound, so dxr3 output is not working. At some point I was able to get OSD up, and it seemed to work ok, but there was no video. After I recompiled dxr3plugin with most recent ffmpeg svn version, I lost OSD too. :D
My log is filled with:
Aug 23 20:25:38 vdr vdr: [22560] cDxr3DemuxDevice::DemuxPes() ePesFrameError skipping data and resync Aug 23 20:25:41 vdr last message repeated 27 times
So basicly dxr3plugin judges all frames invalid?
The old VDR (1.4.5) with dxr3 plugin 0.2.6 still works fine, even after full recompile of both..
2010/8/23 Teemu Suikki tsuikki@zuik.org:
I have been using ancient versions of VDR 1.4.5 and dxr3plugin 0.2.6 for years now, with no real problems. For some reason I decided to try the recent versions. :) VDR 1.7.15 and dxr3plugin 0.2.10.
Did you choose the buffer-and-sync-rewrite branch [1]? It's working fine for me with vdr-1.7.15.
- jan
[1] http://projects.vdr-developer.org/projects/plg-dxr3/repository/show?rev=buff...
Hi,
thanks a bunch! This looks a lot more promising now. I have perfect picture and OSD, but there is no sound?
It might be due to the fact that this new dxr3 plugin seems to use ALSA? My older installation used OSS. I'm using the digital audio output, I have nothing in the analog outputs so I can't be sure if it's outputing something there. But I have selected "digital output" in dxr3 plugin setup.
Also subtitles seem to bug a little, there's a lot of garbage on top of the text, and sometimes the texts appear in top left corner, not in bottom like they should.
Hi,
thanks for your feedback - I have some commits waiting in my local git repository. I hope I can find some hours this week to commit patches and improve some broken stuff.
I think it would be also a good idea to start some unit testing to fix broken OSD outputs. This would improve the situation much more, as the OSD is quite a complex construct and I could close some open bugs in the tracker.
Alsa output does not support digital audio at the moment... but I will bring back OSS - which supports digital and analog output.
greets -- Christian Gmeiner, MSc
2010/8/24 Teemu Suikki tsuikki@zuik.org:
Hi,
thanks a bunch! This looks a lot more promising now. I have perfect picture and OSD, but there is no sound?
It might be due to the fact that this new dxr3 plugin seems to use ALSA? My older installation used OSS. I'm using the digital audio output, I have nothing in the analog outputs so I can't be sure if it's outputing something there. But I have selected "digital output" in dxr3 plugin setup.
Also subtitles seem to bug a little, there's a lot of garbage on top of the text, and sometimes the texts appear in top left corner, not in bottom like they should.
-- Teemu Suikki http://www.z-power.fi/
.4.5 and dxr3plugin 0.2.6
for years now, with no real problems. For some reason I decided to try the recent versions. :) VDR 1.7.15 and dxr3plugin 0.2.10.
Did you choose the buffer-and-sync-rewrite branch [1]? It's working fine for me with vdr-1.7.15.
- jan
[1] http://projects.vdr-developer.org/projects/plg-dxr3/repository/show?rev=buff...
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-- Teemu Suikki http://www.z-power.fi/
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Ah so the muted digital audio is normal then. :) I'm moving this VDR machine to different room anyway, where I will be using analog audio, so no real problem there.
OSD is working 100% except for the subtitles. To me it looks like it is the subtitle font rendering that is bugged, sometimes you can see "unfilled" letters where there's only the white outline and inside is transparent.. This might be VDR bug actually, I have no idea where the rendering takes place?
En/na Teemu Suikki ha escrit:
OSD is working 100% except for the subtitles. To me it looks like it is the subtitle font rendering that is bugged, sometimes you can see "unfilled" letters where there's only the white outline and inside is transparent.. This might be VDR bug actually, I have no idea where the rendering takes place?
You could try the cvs version from sourceforge (though I don't know if Ville committed the latest changes I made, which, IIRC, showed a message for h264 encoded channels).
Bye
On Tuesday 24 August 2010, Luca Olivetti wrote:
En/na Teemu Suikki ha escrit:
OSD is working 100% except for the subtitles. To me it looks like it is the subtitle font rendering that is bugged, sometimes you can see "unfilled" letters where there's only the white outline and inside is transparent.. This might be VDR bug actually, I have no idea where the rendering takes place?
You could try the cvs version from sourceforge
If you do, be sure to test the vdr-dxr3-0-2 branch, and see if you need to apply patches/vdr-dxr3subtitlehack.patch to your VDR. You may also want to check if that patch/hack has any effect on subtitles when used with the git version of the plugin.
A known problem currently in the vdr-dxr3-0-2 branch at least when used with VDR 1.6.0-2 (haven't tested 1.7.x versions) is that DVB subtitles appear too early. I plan to do something about that (this was discussed on the dxr3 plugin mailing list) and then release 0.2.11.
(though I don't know if Ville committed the latest changes I made, which, IIRC, showed a message for h264 encoded channels).
Yep, that's in.
I tried the patch with git plugin, now it works fine.. I'll try it with your version later. :)
2010/8/24 Ville Skyttä ville.skytta@iki.fi:
If you do, be sure to test the vdr-dxr3-0-2 branch, and see if you need to apply patches/vdr-dxr3subtitlehack.patch to your VDR. You may also want to check if that patch/hack has any effect on subtitles when used with the git version of the plugin.
Howdy!
I now tested vdr-dxr3-0.2.11.. It is perfect otherwise, but OSD is all messed up. Subtitles work fine, though!
The git version has working OSD, but subtitles bug sometimes (they often appear in wrong location on screen). Also git version doesn't have working audio, which basicly forces me to use this 0.2.11 version anyway. :) But working OSD would be nice.
I have patches/vdr-dxr3subtitlehack.patch applied, haven't tried without it with 0.2.11.
-- Teemu
2010/8/24 Ville Skyttä ville.skytta@iki.fi:
If you do, be sure to test the vdr-dxr3-0-2 branch, and see if you need to apply patches/vdr-dxr3subtitlehack.patch to your VDR. You may also want to check if that patch/hack has any effect on subtitles when used with the git version of the plugin.
A known problem currently in the vdr-dxr3-0-2 branch at least when used with VDR 1.6.0-2 (haven't tested 1.7.x versions) is that DVB subtitles appear too early. I plan to do something about that (this was discussed on the dxr3 plugin mailing list) and then release 0.2.11.
(though I don't know if Ville committed the latest changes I made, which, IIRC, showed a message for h264 encoded channels).
Yep, that's in.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Friday 01 October 2010, Teemu Suikki wrote:
Howdy!
I now tested vdr-dxr3-0.2.11.. It is perfect otherwise, but OSD is all messed up. Subtitles work fine, though!
Good to hear.
The git version has working OSD, but subtitles bug sometimes (they often appear in wrong location on screen). Also git version doesn't have working audio, which basicly forces me to use this 0.2.11 version anyway. :) But working OSD would be nice.
Which skin do you use? The TROUBLESHOOTING file included with the plugin contains tips that work for some people at least with earlier VDR versions. I'm currently using text2skin and Enigma without channel logos with 1.6.0-2 and it works fine for me.
On Saturday 02 October 2010, you wrote:
I'm currently using text2skin and Enigma without channel logos with 1.6.0-2 and it works fine for me.
Forgot to mention that I'm not 100% sure if it's OSD related, but the only situation where I frequently run into problems in this setup is when working with cut marks; especially when moving them the OSD seems to get stuck or corrupt quite often. Sometimes just waiting a few seconds fixes it, sometimes restarting the replay and editing does the trick, and sometimes VDR restarts.
I now tested vdr-dxr3-0.2.11.. It is perfect otherwise, but OSD is all messed up. Subtitles work fine, though!
Good to hear.
The git version has working OSD, but subtitles bug sometimes (they often appear in wrong location on screen). Also git version doesn't have working audio, which basicly forces me to use this 0.2.11 version anyway. :) But working OSD would be nice.
Which skin do you use? The TROUBLESHOOTING file included with the plugin contains tips that work for some people at least with earlier VDR versions. I'm currently using text2skin and Enigma without channel logos with 1.6.0-2 and it works fine for me.
Hi!
I use ST:TNG.. I tried the "classic vdr" and it was the same. I haven't tried any others. I'm using VDR 1.7.15..
Anyway, there must be some difference between git and your version, I'll try to diff them.. :)
It's annoying to have two "almost" working versions. :) git version is fine except for the audio and subtitles, and 0.2.11 is fine except for the OSD. So now we just need to combine the working features of both versions. :)
Al 02/10/10 09:51, En/na Teemu Suikki ha escrit:
It's annoying to have two "almost" working versions. :) git version is fine except for the audio and subtitles, and 0.2.11 is fine except for the OSD.
Mmh, strange, my osd is working (with the usual problems but mostly working). Note that my version is not exactly the same as the cvs one, but there should be no differences wrt the osd.
So now we just need to combine the working features of both versions. :)
They diverged too much, that's why I first tried the git version then I went back to the cvs one.
Bye.
Hi!
I managed to fix 0.2.11 OSD.. It's quite simple, in file dxr3osd_subpicture.c
*** 87,92 **** if (Areas[i].bpp != 1 && Areas[i].bpp != 2 && ! Areas[i].bpp != 4 && ! Areas[i].bpp != 8) { return oeBppNotSupported; --- 87,91 ---- if (Areas[i].bpp != 1 && Areas[i].bpp != 2 && ! Areas[i].bpp != 4) { return oeBppNotSupported;
------------------ So apparently "Areas" are not supported in 8bpp? I checked both git versions (master and buffer-and-sync-rewrite) and they also have 8bpp removed just like above.
Al 02/10/10 10:54, En/na Teemu Suikki ha escrit:
Hi!
I managed to fix 0.2.11 OSD.. It's quite simple, in file dxr3osd_subpicture.c
*** 87,92 **** if (Areas[i].bpp != 1&& Areas[i].bpp != 2&& ! Areas[i].bpp != 4&& ! Areas[i].bpp != 8) { return oeBppNotSupported; --- 87,91 ---- if (Areas[i].bpp != 1&& Areas[i].bpp != 2&& ! Areas[i].bpp != 4) { return oeBppNotSupported;
So apparently "Areas" are not supported in 8bpp? I checked both git versions (master and buffer-and-sync-rewrite) and they also have 8bpp removed just like above.
Well, the osd doesn't even support 4bpp, especially when different areas can have different palettes, but it tries to manage with a series of hacks. Anyway my osd works with the unpatched version (i.e.:
if (Areas[i].bpp != 1&& Areas[i].bpp != 2&& Areas[i].bpp != 4&& Areas[i].bpp != 8) {
Bye
-
Christian Gmeiner -
Jan Willies -
Luca Olivetti -
Teemu Suikki -
Ville Skyttä