vdr-1.5.11 & subtitling problems
Commit Message
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.
Comments
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.
@@ -60,12 +60,17 @@ private:
int gotten;
uchar *buffer;
char *description;
+ bool assumePesContent;
+ bool HasPesPacket(int &Count);
public:
- cRingBufferLinear(int Size, int Margin = 0, bool Statistics = false, const char *Description = NULL);
+ cRingBufferLinear(int Size, int Margin = 0, bool Statistics = false, const char *Description = NULL, bool AssumePesContent = false);
///< Creates a linear ring buffer.
///< The buffer will be able to hold at most Size-Margin-1 bytes of data, and will
///< be guaranteed to return at least Margin bytes in one consecutive block.
///< The optional Description is used for debugging only.
+ ///< AssumePesContent specializes the buffer and changes its behavior when less
+ ///< than Margin bytes are available. The buffer is then allowed to return at
+ ///< least a complete PES packet.
virtual ~cRingBufferLinear();
virtual int Available(void);
virtual int Free(void) { return Size() - Available() - 1 - margin; }
@@ -151,9 +151,10 @@ void cRingBufferLinear::PrintDebugRBL(vo
}
#endif
-cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description)
+cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description, bool AssumePesContent)
:cRingBuffer(Size, Statistics)
{
+ assumePesContent = AssumePesContent;
description = Description ? strdup(Description) : NULL;
tail = head = margin = Margin;
gotten = 0;
@@ -299,7 +300,7 @@ uchar *cRingBufferLinear::Get(int &Count
int cont = (diff >= 0) ? diff : Size() + diff - margin;
if (cont > rest)
cont = rest;
- if (cont >= margin) {
+ if (cont >= margin || assumePesContent && HasPesPacket(cont)) {
p = buffer + tail;
Count = gotten = cont;
}
@@ -308,6 +309,19 @@ uchar *cRingBufferLinear::Get(int &Count
return p;
}
+bool cRingBufferLinear::HasPesPacket(int &Count)
+{
+ uchar *p = buffer + tail;
+ if (Count >= 6 && !p[0] && !p[1] && p[2] == 0x01) {
+ int Length = 6 + p[4] * 256 + p[5];
+ if (Length <= Count) {
+ Count = Length;
+ return true;
+ }
+ }
+ return false;
+}
+
void cRingBufferLinear::Del(int Count)
{
if (Count > gotten) {
@@ -1883,7 +1883,7 @@ cRemux::cRemux(int VPid, const int *APid
skipped = 0;
numTracks = 0;
resultSkipped = 0;
- resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result");
+ resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result", true);
resultBuffer->SetTimeouts(0, 100);
if (VPid)
#define TEST_cVideoRepacker