Hi,
I'm having heavy artifacts with the new vdr-1.5.11 in finnish DVB channels. The picture freezes now very often compared to previous VDR version (I reported about the same rare problem in vdr-1.5.10) and it seems that the problem is the new SUBTITLE_PACKS size. I reverted it back to 2048 and haven't noticed the problem after that.
During the freeze VDR's transfer buffer gets full and VDR is clearing transfer buffer to avoid overflows. This happens only on channels with DVB subtitling.
I'm using 4MB FF card as a primary device, if that makes any difference.
BR, -- rofa
Hi,
Rolf Ahrenberg schrieb:
I'm having heavy artifacts with the new vdr-1.5.11 in finnish DVB channels. The picture freezes now very often compared to previous VDR version (I reported about the same rare problem in vdr-1.5.10) and it seems that the problem is the new SUBTITLE_PACKS size. I reverted it back to 2048 and haven't noticed the problem after that.
Thinking about a repacker for subtitles, can anyone provide me some links to documentation about the subtitle PES packet's contents?
Bye.
On 11/5/07, Reinhard Nissl rnissl@gmx.de wrote:
Thinking about a repacker for subtitles, can anyone provide me some links to documentation about the subtitle PES packet's contents?
I think what you're looking for can be found here: http://www.bjpace.com.cn/data/tec/tec-DVB/DVB%20BlueBooks%20Standards/Specif...
Hi,
VDR User schrieb:
Thinking about a repacker for subtitles, can anyone provide me some links to documentation about the subtitle PES packet's contents?
I think what you're looking for can be found here: http://www.bjpace.com.cn/data/tec/tec-DVB/DVB%20BlueBooks%20Standards/Specif...
Thanks for this information. ETS 300 743 V1.3.1 (2006-11) is available -- free of charge -- at www.etsi.org, too.
Bye.
Hi,
Rolf Ahrenberg schrieb:
During the freeze VDR's transfer buffer gets full and VDR is clearing transfer buffer to avoid overflows. This happens only on channels with DVB subtitling.
The problem for this issue is in cRemux::cRemux():
new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result");
IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full.
Bye.
On Tue, 6 Nov 2007, Reinhard Nissl wrote:
The problem for this issue is in cRemux::cRemux(): new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result"); IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full.
Thanks. I made the necessary modification and haven't noticed any freezes afterwards.
BR, -- rofa
Rolf Ahrenberg wrote:
On Tue, 6 Nov 2007, Reinhard Nissl wrote:
The problem for this issue is in cRemux::cRemux(): new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result"); IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full.
Thanks. I made the necessary modification and haven't noticed any freezes afterwards.
I can confirm that.
On 11/07/07 18:27, VDR User wrote:
Can someone make a patch for this fix?
--- remux.c 2007/11/03 14:18:07 1.60 +++ remux.c 2007/11/07 16:19:59 @@ -1883,7 +1883,7 @@ skipped = 0; numTracks = 0; resultSkipped = 0; - resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result"); + resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, SUBTITLE_PACKS, false, "Result"); resultBuffer->SetTimeouts(0, 100); if (VPid) #define TEST_cVideoRepacker
Thanks to Reinhard for finding this one.
Klaus
Hi,
Klaus Schmidinger schrieb:
Thanks to Reinhard for finding this one.
And the attached patch should fix the incorrectly assembled subtitle PES packets, which led to triggering pre 1.3.19 Dolby Digital compatibility mode.
When TS packet's payload looked like that:
a) 00 00 01 bd 1d 7b 85 80 05 b) 27 cb cd b8 8b 20 00 0f ...
The bytes 85 80 and 05 were written to the PES packet as found was 9 after processing TS packet a) which was correct. But for the next TS packet b), found was still 9 which caused writing the bytes 85 80 and 05 again to the PES packet.
So instead of writing
00 00 01 bd __ __ 85 80 05 27 cb cd b8 8b 20 01 00 00 20 00 0f ... ^^ the following was written:
00 00 01 bd __ __ 85 80 05 85 80 05 27 cb cd b8 8b 20 01 00 00 20 00 0f ^^
As a result PlayPES() didn't find the supported SubStreamId 20 but cd which activated compatibility mode.
Bye.
On 11/06/07 20:57, Reinhard Nissl wrote:
Hi,
Rolf Ahrenberg schrieb:
During the freeze VDR's transfer buffer gets full and VDR is clearing transfer buffer to avoid overflows. This happens only on channels with DVB subtitling.
The problem for this issue is in cRemux::cRemux():
new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result");
IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full.
After some testing I'm afraid this only works for Transfer Mode, but not for live mode directly on the primary FF DVB card. In Transfer Mode the result buffer is likely to have 32KB available because it also contains video data. But in direct live mode it only holds subtitle data, which usually takes a while to amount to 32KB. And the result buffer, if set up with Margin=SUBTITLE_PACKS will only deliver data when it has at least 32KB available. Therefore the subtitles are displayed way to late (some 20 to 50 seconds, sometimes even more).
I do see the problems Rolf has reported in Transfer Mode, and using SUBTITLE_PACKS for the repacker does help here. But we also need to make it work in direct live mode.
One more thought: even in direct live mode the result buffer will only return data if it has at least IPACKS bytes available (assuming the change Reinhard suggested is not applied), which may mean that a small subtitle packet may sit any wait in the buffer until more data arrives and "washes" it out. This may explain why sometimes in live mode a subtitle line is displayed for a long time when no new text follows it.
Maybe introducing SUBTITLE_PACKS wasn't such a good idea after all, and we should return to IPACKS, and bite the bullet and introduce a repacker for subtitle data, as Reinhard already suggested...
Klaus
Hi,
Klaus Schmidinger schrieb:
After some testing I'm afraid this only works for Transfer Mode, but not for live mode directly on the primary FF DVB card. In Transfer Mode the result buffer is likely to have 32KB available because it also contains video data. But in direct live mode it only holds subtitle data, which usually takes a while to amount to 32KB. And the result buffer, if set up with Margin=SUBTITLE_PACKS will only deliver data when it has at least 32KB available. Therefore the subtitles are displayed way to late (some 20 to 50 seconds, sometimes even more).
I do see the problems Rolf has reported in Transfer Mode, and using SUBTITLE_PACKS for the repacker does help here. But we also need to make it work in direct live mode.
One more thought: even in direct live mode the result buffer will only return data if it has at least IPACKS bytes available (assuming the change Reinhard suggested is not applied), which may mean that a small subtitle packet may sit any wait in the buffer until more data arrives and "washes" it out. This may explain why sometimes in live mode a subtitle line is displayed for a long time when no new text follows it.
Well, I recall a personal email several months ago where I reported that the last packet in the result buffer cannot be retrieved for the above reason. This is not a matter for normal use, but I had this behavior in a program for testing repackers where the fed in data was shortened for each pass.
Maybe introducing SUBTITLE_PACKS wasn't such a good idea after all, and we should return to IPACKS, and bite the bullet and introduce a repacker for subtitle data, as Reinhard already suggested...
I had a look into the specs and there is no need for a repacker. The packets are already properly aligned. And splitting the packets into smaller pieces (some of about 20 - 30 bytes) wouldn't help in the above issue.
A simple hacked solution might be to put an additional padding packet of size IPACKS into the result buffer whenever it contains less than IPACKS bytes of data. These padding packets (stream ID 0xBE) should be dropped by the recorder and by PlayPESPacket().
Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size).
Bye.
On 11/10/07 15:22, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
After some testing I'm afraid this only works for Transfer Mode, but not for live mode directly on the primary FF DVB card. In Transfer Mode the result buffer is likely to have 32KB available because it also contains video data. But in direct live mode it only holds subtitle data, which usually takes a while to amount to 32KB. And the result buffer, if set up with Margin=SUBTITLE_PACKS will only deliver data when it has at least 32KB available. Therefore the subtitles are displayed way to late (some 20 to 50 seconds, sometimes even more).
I do see the problems Rolf has reported in Transfer Mode, and using SUBTITLE_PACKS for the repacker does help here. But we also need to make it work in direct live mode.
One more thought: even in direct live mode the result buffer will only return data if it has at least IPACKS bytes available (assuming the change Reinhard suggested is not applied), which may mean that a small subtitle packet may sit any wait in the buffer until more data arrives and "washes" it out. This may explain why sometimes in live mode a subtitle line is displayed for a long time when no new text follows it.
Well, I recall a personal email several months ago where I reported that the last packet in the result buffer cannot be retrieved for the above reason. This is not a matter for normal use, but I had this behavior in a program for testing repackers where the fed in data was shortened for each pass.
Maybe introducing SUBTITLE_PACKS wasn't such a good idea after all, and we should return to IPACKS, and bite the bullet and introduce a repacker for subtitle data, as Reinhard already suggested...
I had a look into the specs and there is no need for a repacker. The packets are already properly aligned. And splitting the packets into smaller pieces (some of about 20 - 30 bytes) wouldn't help in the above issue.
A simple hacked solution might be to put an additional padding packet of size IPACKS into the result buffer whenever it contains less than IPACKS bytes of data. These padding packets (stream ID 0xBE) should be dropped by the recorder and by PlayPESPacket().
Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do. Can you suggest a patch for this?
Klaus
Hi,
Klaus Schmidinger schrieb:
Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do. Can you suggest a patch for this?
I hope to get something ready till tomorrow 12:00.
Bye.
Hi,
Reinhard Nissl schrieb:
Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do. Can you suggest a patch for this?
I hope to get something ready till tomorrow 12:00.
See attachment. Tested in transfer mode with audio packets only (= radio), as there is no broadcast running which would provide subtitles.
Bye.
El Sábado, 10 de Noviembre de 2007, Reinhard Nissl escribió:
Hi,
Reinhard Nissl schrieb:
Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do. Can you suggest a patch for this?
I hope to get something ready till tomorrow 12:00.
See attachment. Tested in transfer mode with audio packets only (= radio), as there is no broadcast running which would provide subtitles.
Bye.
This patch fix problems with pvrinput radio an CRepacker. Thanks. Jose Alberto
El Domingo, 11 de Noviembre de 2007, Jose Alberto Reguero escribió:
El Sábado, 10 de Noviembre de 2007, Reinhard Nissl escribió:
Hi,
Reinhard Nissl schrieb:
Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do. Can you suggest a patch for this?
I hope to get something ready till tomorrow 12:00.
See attachment. Tested in transfer mode with audio packets only (= radio), as there is no broadcast running which would provide subtitles.
Bye.
This patch fix problems with pvrinput radio an CRepacker. Thanks. Jose Alberto
I still have problems with this patch and pvrinput and live radio, with CRepacker. If I disable CRepacker, the live radio is ok. Any ideas why to debug it?
Thanks. JHose Alberto
Hi,
Jose Alberto Reguero schrieb:
I still have problems with this patch and pvrinput and live radio, with CRepacker. If I disable CRepacker, the live radio is ok. Any ideas why to debug it?
I need some more information. From what I guess, pvrinput provides a TS stream, VDR runs in transfermode and outputs the remuxed stream via a FF card. Is this correct?
What are the problems you are seeing with cAudioRepacker enabled?
Are there any problems when you replay a radio recording?
Are there any logfile entries mentioning a problem?
Bye.
El Domingo, 18 de Noviembre de 2007, Reinhard Nissl escribió:
Hi,
Jose Alberto Reguero schrieb:
I still have problems with this patch and pvrinput and live radio, with CRepacker. If I disable CRepacker, the live radio is ok. Any ideas why to debug it?
I need some more information. From what I guess, pvrinput provides a TS stream, VDR runs in transfermode and outputs the remuxed stream via a FF card. Is this correct?
Pvrinput is for analog hauppauge cards with harware encoder. Radio is a bit diferent, that tv because the card can't provide a mpeg audio only stream but a mpeg audio stream with a blank mpeg video. Audio channels have pid=0 so remux left only the audio part. If I put video pid in the radio channels in channels.conf then there is no problem with CRepacker. I use xineliboutput for the output.
What are the problems you are seeing with cAudioRepacker enabled?
The problems I have are that sometimes, the audio is not completely smooth, they have some breaks, in live radio.
Are there any problems when you replay a radio recording?
The recordings play without problems.
Are there any logfile entries mentioning a problem?
There are not any messages in the log files.
Bye.
Thanks. Jose Alberto
Hi,
What are the problems you are seeing with cAudioRepacker enabled?
The problems I have are that sometimes, the audio is not completely smooth, they have some breaks, in live radio.
Are there any problems when you replay a radio recording?
The recordings play without problems.
This sounds like buffer underruns when listening to live radio. When cAudioRepacker is enabled and with the recent ringbuffer patch, you'll get each audio frame (~ 24 ms) as soon as it is available.
If the output device starts immediately with playback, it is likely that there are buffer underruns, especially when xine drops some audio frames when syncing.
I don't know whether xineliboutput has some setup options to control buffering in live mode. In vdr-xine's setup page you can specify an initial buffer size (e. g. 4 video frames ~ 160 ms) which must first be established before replaying at normal speed starts.
BTW: The software decoding solutions need such a buffer to compensate latency issues with the threads involved in the chain from input to output.
Bye.
-
Jose Alberto Reguero -
Klaus Schmidinger -
Lauri Tischler -
Reinhard Nissl -
Rolf Ahrenberg -
VDR User