Menu
▾
▴
dxr3plugin-users
|
From: Andreas M. <an...@vd...> - 2010-04-03 06:25:56
|
Hello Lucu, thanks for the patch. I tried it and it worked fine. I only had one issue when I tried it first: Moving cutting marks didn't work. I see lots of that messages in my syslog: Apr 1 15:29:12 [vdr] [972] dxr3: device: tricspeed: 1 Apr 1 15:29:13 [vdr] [1031] dxr3: demux: I-frame Apr 1 15:29:13 [vdr] [1031] dxr3: unable to set single-step mode: Operation not permitted Apr 1 15:29:13 [vdr] [1031] dxr3: demux: unknown frame Another problem I have is that audio doesn't work very well. After doing some tests I'd say that enabling Dolby Digital makes it worse. If DD is disabled audio is sometimes lost and if DD is enabled audio and video is lost on channel switching. Best regards, Andreas > Hello, > > attached is a patch against the latest cvs version (i.e. 0.2.10) to make > it work with vdr-1.7.14. > Before using the latest cvs (actually my copy), I tried with the git > version but it had too many problems (some of them with the osd, > problems already fixed in cvs a long time ago), so, since my dxr3 > doesn't see too much use nowadays, I reverted to my old, working, version. > There are still some issues that I don't see how to fix: > > - after a while audio and video are slightly out of sync (maybe related > to the fact that I had to raise the tolerance between pts and SCR from > 5000 to 30000, otherwise old recordings stuttered badly). > - if I tune to an hd (h264) channel, afterwards the audio doesn't work. > Resetting the dxr3 through the menu restores the audio. > > Bye > -- > Luca -- http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & VDRSymbols VDR user #303 |
|
From: Luca O. <lu...@ve...> - 2010-04-03 16:40:40
|
En/na Andreas Mair ha escrit: > Hello Lucu, > > thanks for the patch. I tried it and it worked fine. I only had one > issue when I tried it first: > Moving cutting marks didn't work. Mmmh, that's something I didn't test :-( > I see lots of that messages in my syslog: > Apr 1 15:29:12 [vdr] [972] dxr3: device: tricspeed: 1 > Apr 1 15:29:13 [vdr] [1031] dxr3: demux: I-frame > Apr 1 15:29:13 [vdr] [1031] dxr3: unable to set single-step mode: > Operation not permitted > Apr 1 15:29:13 [vdr] [1031] dxr3: demux: unknown frame > > Another problem I have is that audio doesn't work very well. After > doing some tests I'd say that enabling Dolby Digital makes it worse. > If DD is disabled audio is sometimes lost and if DD is enabled audio > and video is lost on channel switching. I have dolby digital enabled, but the only channel I regularly watch with dolby digital is bbchd, and that's obviously not a channel I watch using the dxr3 ;-) I think I tested on some german channel with dolby digital, and I saw no issues there also, but that's not the kind of channel I watch regularly. Resetting the card from the main menu should restore the audio. Nowadays I don't use the dxr3 that much, but a couple of nights ago I watched pirates of the caribbean on the bbc with no issues and no desynchronization between audio and video. Bye -- Luca |
|
From: Luca O. <lu...@ve...> - 2010-04-03 16:30:11
|
En/na Luca Olivetti ha escrit: > En/na Andreas Mair ha escrit: >> Hello Lucu, >> >> thanks for the patch. I tried it and it worked fine. I only had one >> issue when I tried it first: >> Moving cutting marks didn't work. > > Mmmh, that's something I didn't test :-( I just did a quick test. On old pes recordings moving cutting marks seems to work ok. On a new, ts, recording, moving the marks work but you don't see the updated picture when you jump, only when you unpause, and that's not really useful. I don't know if I'll have time to look into that :-( Bye -- Luca |
|
From: Luca O. <lu...@ve...> - 2010-04-03 17:06:24
|
En/na Luca Olivetti ha escrit:
> En/na Luca Olivetti ha escrit:
>> En/na Andreas Mair ha escrit:
>>> Hello Lucu,
>>>
>>> thanks for the patch. I tried it and it worked fine. I only had one
>>> issue when I tried it first:
>>> Moving cutting marks didn't work.
>> Mmmh, that's something I didn't test :-(
>
> I just did a quick test.
> On old pes recordings moving cutting marks seems to work ok.
> On a new, ts, recording, moving the marks work but you don't see the
> updated picture when you jump, only when you unpause, and that's not
> really useful.
> I don't know if I'll have time to look into that :-(
Oh, well, that was easy :-)
Here's a revised patch (against cvs, 2.0.10) that fixes this issue.
If you don't want to fetch a clean version and reapply the diff, just
change in dxr3device.c the implementation of StillPicture like this:
void cDxr3Device::StillPicture(const uchar *Data, int Length)
{
if (Data[0] == 0x47)
//TS data, let cDevice convert it to PES
cDevice::StillPicture(Data, Length);
else
m_DemuxDevice.StillPicture(Data, Length);
}
Oh, and also remove the two extra calls to DemuxPes in
cDxr3DemuxDevice::StillPicture in dxr3demuxdevice.c (one call is enough).
Bye
--
Luca
|
|
From: Luca O. <lu...@ve...> - 2010-04-03 17:11:34
Attachments:
dxr3-vdr-1.7.14-fixes.2nd.patch.gz
|
En/na Luca Olivetti ha escrit: > Here's a revised patch (against cvs, 2.0.10) that fixes this issue. Oops, I forgot to attach it. Here it is. |
|
From: Ville S. <vil...@ik...> - 2010-04-05 10:41:49
|
On Saturday 03 April 2010, Luca Olivetti wrote:
> En/na Luca Olivetti ha escrit:
> > Here's a revised patch (against cvs, 2.0.10) that fixes this issue.
>
> Oops, I forgot to attach it. Here it is.
I finally found time to test this with VDR 1.6.0. I found three issues:
1) It didn't compile with VDR 1.6. Fixed by copying PesLongEnough(),
PesHasPts() and PesGetPts() from VDR 1.7.14.
2) There's no audio when moving cutting marks.
3) When replaying a recording and VDR switches a recording file, there's a
noticeable pause/stutter effect and audio appears to get stuck for a little
while and I see this in a syslog (after the log entry from VDR that it
switched the recording file):
dxr3: audiodecoder: sample rate=48000
dxr3: audiodecoder: channels=2
...so I suppose some kind of reinitialization gets done. This doesn't happen
with plugin 0.2.10, switching recording files is all smooth and unnoticeable
with it. This is annoying because I use the hard link cutter patch which
means I have many smallish recording files and this problem thus occurs
frequently.
It'd be great if someone could figure out a fix for 2) and 3). For now Luca's
work plus fix for 1) above is in vdr-dxr3-0-2-vdr17 branch in CVS.
|
|
From: Luca O. <lu...@ve...> - 2010-04-05 11:09:54
|
En/na Ville Skyttä ha escrit: > 2) There's no audio when moving cutting marks. I'm not sure it's a bug: with the xine plug in there's no audio either. > > 3) When replaying a recording and VDR switches a recording file, there's a > noticeable pause/stutter effect and audio appears to get stuck for a little > while and I see this in a syslog (after the log entry from VDR that it > switched the recording file): > dxr3: audiodecoder: sample rate=48000 > dxr3: audiodecoder: channels=2 > ...so I suppose some kind of reinitialization gets done. This doesn't happen > with plugin 0.2.10, switching recording files is all smooth and unnoticeable > with it. This is annoying because I use the hard link cutter patch which > means I have many smallish recording files and this problem thus occurs > frequently. Just tried and it happens also with vdr-1.7.14, I'll see if I find where the problem lies, but I don't promise anything. Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-04-05 13:17:53
|
On Monday 05 April 2010, Luca Olivetti wrote: > En/na Ville Skyttä ha escrit: > > 2) There's no audio when moving cutting marks. > > I'm not sure it's a bug: with the xine plug in there's no audio either. I think it is a bug -- I remember reading a discussion about this on the VDR (or some other related) mailing list. The argument was that having audio there makes it easier to fine tune cut marks. Audio is there with 0.2.10. |
|
From: Luca O. <lu...@ve...> - 2010-04-05 11:21:14
|
En/na Luca Olivetti ha escrit: > En/na Ville Skyttä ha escrit: > >> 2) There's no audio when moving cutting marks. > > I'm not sure it's a bug: with the xine plug in there's no audio either. > >> 3) When replaying a recording and VDR switches a recording file, there's a >> noticeable pause/stutter effect and audio appears to get stuck for a little >> while and I see this in a syslog (after the log entry from VDR that it >> switched the recording file): >> dxr3: audiodecoder: sample rate=48000 >> dxr3: audiodecoder: channels=2 >> ...so I suppose some kind of reinitialization gets done. This doesn't happen >> with plugin 0.2.10, switching recording files is all smooth and unnoticeable >> with it. This is annoying because I use the hard link cutter patch which >> means I have many smallish recording files and this problem thus occurs >> frequently. > > Just tried and it happens also with vdr-1.7.14, I'll see if I find where > the problem lies, but I don't promise anything. The problem is, I don't see those messages, i.e. the audio is not reinitializing, so I don't know where to start looking. Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-04-05 14:05:51
|
On Monday 05 April 2010, Luca Olivetti wrote: > En/na Luca Olivetti ha escrit: > > En/na Luca Olivetti ha escrit: > >> En/na Ville Skyttä ha escrit: > >> > >>> 3) When replaying a recording and VDR switches a recording file, > >>> there's a noticeable pause/stutter effect and audio appears to get > >>> stuck for a little while and I see this in a syslog (after the log > >>> entry from VDR that it > >>> > >>> switched the recording file): > >>> dxr3: audiodecoder: sample rate=48000 > >>> dxr3: audiodecoder: channels=2 > >>> > >>> ...so I suppose some kind of reinitialization gets done. This doesn't > >>> happen with plugin 0.2.10, switching recording files is all smooth and > >>> unnoticeable with it. This is annoying because I use the hard link > >>> cutter patch which means I have many smallish recording files and this > >>> problem thus occurs frequently. > >> > >> Just tried and it happens also with vdr-1.7.14, I'll see if I find where > >> the problem lies, but I don't promise anything. > > > > The problem is, I don't see those messages, i.e. the audio is not > > reinitializing, so I don't know where to start looking. > > Try changing the buffer sizes in dxr3demuxdevice.h > > With > > > const int AUDIO_MAX_BUFFER_SIZE = 80; > const int VIDEO_MAX_BUFFER_SIZE = 100; > > the problem went away here in my test recording. That didn't help for me, but when I reverted these to back to what they were before your patch (200 for audio, 500 for video), the problem went away. In my test case it seems that the audio one doesn't matter much, but video needs to be considerably higher than 50 or 100 - I still saw the problem with 450 but no longer with 500. |
|
From: Luca O. <lu...@ve...> - 2010-04-05 14:20:30
|
En/na Ville Skyttä ha escrit: >> >> const int AUDIO_MAX_BUFFER_SIZE = 80; >> const int VIDEO_MAX_BUFFER_SIZE = 100; >> >> the problem went away here in my test recording. > > That didn't help for me, but when I reverted these to back to what they were > before your patch (200 for audio, 500 for video), the problem went away. > > In my test case it seems that the audio one doesn't matter much, but video > needs to be considerably higher than 50 or 100 - I still saw the problem with > 450 but no longer with 500. I suppose it depends on the speed of the computer and/or the characteristics of the recording. I reduced the buffer size to compensate for the increase of the frame size, maybe that wasn't such a good idea if you have the memory to spare. Bye -- Luca |
|
From: Luca O. <lu...@ve...> - 2010-04-05 11:51:38
|
En/na Luca Olivetti ha escrit: > En/na Luca Olivetti ha escrit: >> En/na Ville Skyttä ha escrit: >> >>> 2) There's no audio when moving cutting marks. >> I'm not sure it's a bug: with the xine plug in there's no audio either. >> >>> 3) When replaying a recording and VDR switches a recording file, there's a >>> noticeable pause/stutter effect and audio appears to get stuck for a little >>> while and I see this in a syslog (after the log entry from VDR that it >>> switched the recording file): >>> dxr3: audiodecoder: sample rate=48000 >>> dxr3: audiodecoder: channels=2 >>> ...so I suppose some kind of reinitialization gets done. This doesn't happen >>> with plugin 0.2.10, switching recording files is all smooth and unnoticeable >>> with it. This is annoying because I use the hard link cutter patch which >>> means I have many smallish recording files and this problem thus occurs >>> frequently. >> Just tried and it happens also with vdr-1.7.14, I'll see if I find where >> the problem lies, but I don't promise anything. > > The problem is, I don't see those messages, i.e. the audio is not > reinitializing, so I don't know where to start looking. Try changing the buffer sizes in dxr3demuxdevice.h With const int AUDIO_MAX_BUFFER_SIZE = 80; const int VIDEO_MAX_BUFFER_SIZE = 100; the problem went away here in my test recording. Bye -- Luca |
|
From: Luca O. <lu...@ve...> - 2010-04-10 15:23:11
Attachments:
dxr3-digaudio.patch
|
En/na Andreas Mair ha escrit: > Another problem I have is that audio doesn't work very well. After > doing some tests I'd say that enabling Dolby Digital makes it worse. > If DD is disabled audio is sometimes lost and if DD is enabled audio > and video is lost on channel switching. There's definitely a problem with Dolby Digital: the plugin unconditionally switches the output on digital ac3 when there's an ac3 channel and never switches iy back. It should switch it back for a non ac3 channel and don't do anything at all if you're using the analogue output. The attached patch (against the vdr-dxr3-0-2-vdr17 cvs branch) should fix both issues (though I cannot test the digital output). Of course there's no analogue audio on ac3 channels if you have dolby digital enabled but at least audio is not lost when you switch to another channel. Bye -- Luca |
|
From: Andreas M. <ama...@go...> - 2010-04-15 18:25:53
|
Hello Luca, sorry for the delayed answer but in the meantime I removed my DXR3 card. Today I gave it another try: 2010/4/10 Luca Olivetti <lu...@ve...>: > En/na Andreas Mair ha escrit: > >> Another problem I have is that audio doesn't work very well. After >> doing some tests I'd say that enabling Dolby Digital makes it worse. >> If DD is disabled audio is sometimes lost and if DD is enabled audio >> and video is lost on channel switching. > > There's definitely a problem with Dolby Digital: the plugin unconditionally > switches the output on digital ac3 when there's an ac3 channel and never > switches iy back. > It should switch it back for a non ac3 channel and don't do anything at all > if you're using the analogue output. > > The attached patch (against the vdr-dxr3-0-2-vdr17 cvs branch) should fix > both issues (though I cannot test the digital output). Of course there's no > analogue audio on ac3 channels if you have dolby digital enabled but at > least audio is not lost when you switch to another channel. I don't know where to get the branch you've written. So I used v0.2.10 with your first patch to apply that patch. I could test a lot because after about 20 channel switches the card crashed. What was different from my tests without that patch was, that every second channel switch didn't start audio and video (black screen). Best regards, Andreas -- http://andreas.vdr-developer.org --- VDRAdmin-AM & EnigmaNG & VDRSymbols VDR user #303 |
|
From: Luca O. <lu...@ve...> - 2010-04-15 19:27:02
|
En/na Andreas Mair ha escrit: > I don't know where to get the branch you've written. So I used v0.2.10 > with your first patch to apply that patch. I could test a lot because > after about 20 channel switches the card crashed. What was different > from my tests without that patch was, that every second channel switch > didn't start audio and video (black screen). Well, that's strange, it works here :-( Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-04-16 15:48:08
|
On Saturday 10 April 2010, Luca Olivetti wrote: > En/na Andreas Mair ha escrit: > > Another problem I have is that audio doesn't work very well. After > > doing some tests I'd say that enabling Dolby Digital makes it worse. > > If DD is disabled audio is sometimes lost and if DD is enabled audio > > and video is lost on channel switching. > > There's definitely a problem with Dolby Digital: the plugin > unconditionally switches the output on digital ac3 when there's an ac3 > channel and never switches iy back. > It should switch it back for a non ac3 channel and don't do anything at > all if you're using the analogue output. This patch and the rest of your work is now merged back to the vdr-dxr3-0-2 branch. I've been using it for a while with VDR 1.6.0-2, and in addition to the issues already discussed/noted (no audio when moving cut marks, A/V tends to go off sync somewhat more than before) I noticed yesterday that DVB subtitles aren't as well synced as they were (they seem to appear too early). It could be that this is an issue just with the one recording I was watching yesterday, I need to try it out with 0.2.10 to be sure. |
|
From: Ville S. <vil...@ik...> - 2010-04-24 19:23:40
|
On Friday 16 April 2010, Ville Skyttä wrote: > On Saturday 10 April 2010, Luca Olivetti wrote: > > En/na Andreas Mair ha escrit: > > > Another problem I have is that audio doesn't work very well. After > > > doing some tests I'd say that enabling Dolby Digital makes it worse. > > > If DD is disabled audio is sometimes lost and if DD is enabled audio > > > and video is lost on channel switching. > > > > There's definitely a problem with Dolby Digital: the plugin > > unconditionally switches the output on digital ac3 when there's an ac3 > > channel and never switches iy back. > > It should switch it back for a non ac3 channel and don't do anything at > > all if you're using the analogue output. > > This patch and the rest of your work is now merged back to the vdr-dxr3-0-2 > branch. > > I've been using it for a while with VDR 1.6.0-2, and in addition to the > issues already discussed/noted (no audio when moving cut marks, A/V tends > to go off sync somewhat more than before) I noticed yesterday that DVB > subtitles aren't as well synced as they were (they seem to appear too > early). It could be that this is an issue just with the one recording I > was watching yesterday, I need to try it out with 0.2.10 to be sure. Just to follow up, I've now confirmed this. Subtitles at least appear much too early. |
|
From: Luca O. <lu...@ve...> - 2010-04-24 20:49:11
|
Al 24/04/10 21:23, En/na Ville Skyttä ha escrit: >> >> I've been using it for a while with VDR 1.6.0-2, and in addition to the >> issues already discussed/noted (no audio when moving cut marks, A/V tends >> to go off sync somewhat more than before) I noticed yesterday that DVB >> subtitles aren't as well synced as they were (they seem to appear too >> early). It could be that this is an issue just with the one recording I >> was watching yesterday, I need to try it out with 0.2.10 to be sure. > > Just to follow up, I've now confirmed this. Subtitles at least appear much > too early. Well, the only thing that could affect subtitles timing (an issue that I don't see btw) is the change I made to get/set the pts. Revert that and fast forward/rewind stop working (with ts recordings, I don't remember if that's also the case for pes recordings). Choose your poison ;-) Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-08-24 16:16:35
|
On Saturday 24 April 2010, Luca Olivetti wrote: > Al 24/04/10 21:23, En/na Ville Skyttä ha escrit: > >> I've been using it for a while with VDR 1.6.0-2, and in addition to the > >> issues already discussed/noted (no audio when moving cut marks, A/V > >> tends to go off sync somewhat more than before) I noticed yesterday > >> that DVB subtitles aren't as well synced as they were (they seem to > >> appear too early). It could be that this is an issue just with the one > >> recording I was watching yesterday, I need to try it out with 0.2.10 to > >> be sure. > > > > Just to follow up, I've now confirmed this. Subtitles at least appear > > much too early. > > Well, the only thing that could affect subtitles timing (an issue that I > don't see btw) is the change I made to get/set the pts. > Revert that and fast forward/rewind stop working (with ts recordings, I > don't remember if that's also the case for pes recordings). > Choose your poison ;-) I ended up reverting the PTS related changes and it fixes the subtitles timing issue and does not cause any problems with fast forward/rewind with VDR 1.6.0-2 (PES only naturally). By the way, the subtitles appearing too early issue was most prominent for me when playing back recordings. There was a bit of it also in live TV, but they were much more off (about a few seconds) when playing back recordings. |
|
From: Luca O. <lu...@ve...> - 2010-08-24 18:02:41
|
Al 24/08/10 17:58, En/na Ville Skyttä ha escrit: > I ended up reverting the PTS related changes and it fixes the subtitles timing > issue and does not cause any problems with fast forward/rewind with VDR > 1.6.0-2 (PES only naturally). But that's not going to work with ts recordings :-( > By the way, the subtitles appearing too early issue was most prominent for me > when playing back recordings. There was a bit of it also in live TV, but they > were much more off (about a few seconds) when playing back recordings. Yes, I see it too now with some channels. Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-08-24 18:58:36
|
On Tuesday 24 August 2010, Luca Olivetti wrote: > Al 24/08/10 17:58, En/na Ville Skyttä ha escrit: > > I ended up reverting the PTS related changes and it fixes the subtitles > > timing issue and does not cause any problems with fast forward/rewind > > with VDR 1.6.0-2 (PES only naturally). > > But that's not going to work with ts recordings :-( Yes, that's what I gathered from previous messages in this thread. That's too bad, but this is the "stable" branch of the dxr3 plugin, and its primary target is the current stable VDR. Which in my (strong) opinion means that things added solely for VDR development releases' needs must not come at the expense of regressions (at least this big ones) when used with the current stable VDR. I already had some concerns about missing audio when moving cut marks caused by some portions of this patch, but it also makes things better with some channels with higher than usual bitrates (e.g. SuomiTV was pretty much unwatchable for me before these changes) so I'm willing to accept that tradeoff within 1.6.x functionality. These may be due to different parts of the patch but it's hard to tell given the size of it (and my lack of competence in this area); it should have really been split into different changesets that each do one self-contained thing so it would have been sanely possible to bisect regressions. (BTW patches that bring back audio when moving cut marks are still welcome.) At least now the PTS reversion changeset can be retrieved separately from CVS with cvsps and looking at that it's probably easier for someone who's interested to work on an implementation that fixes things for VDR 1.7.x without causing 1.6.x regressions. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X