Re: [vdr] Transfer Buffer Overflow
Zitat von Reinhard Nissl <[EMAIL PROTECTED]>: > Hi, > > Thomas Lagemann wrote: > > > Just another thought about the timing: MPEG-2 defines rules for a system > > target decoder, thats in charge for decoding and presenting the media at > > the right time, using the PTS-stamps in the PES packets. > > Is this usually done by the driver or is there a VDR instance that deals > > with this. > > It's done in the driver / xine. > > But it shouldn't be to complicated to extract the PTS value from a TS > packet. The PTS value is very near to the beginning of a PES packet and > a bit in the TS packet tells you that a new PES packet starts in this TS > packet. > > When you extract PTS for each PID and calculate the difference to the > first seen PTS for each PID, then you evaluate, how much time should > have passed since the beginning of the TS file. If you put this > information in relation to the time passed in reality since opening the > TS file, you can throttle the TS stream so that it doesn't overflow the > buffers any more. > > BTW: keep in mind, that video PTS jump back and forth as the images are > broadcast in decoding order while the PTS time stamps describe > presentation order. This works perfekt! Thank you very much, for the idea :-) Regards, Thomas This message was sent using IMP, the Internet Messaging Program. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
Zitat von Thomas Lagemann <[EMAIL PROTECTED]>: > Reinhard Nissl wrote: > > I currently do not see a chance to fix this issue with the current API. > > Several functions would have to be changed to pass the information, that > > the receiving device may be blocked, to the places where buffer > > overflows are detected. > > > For the moment i work around the problem with program called "buffer", > that i read about in this list > (http://linvdr.org/mailinglists/vdr/2005/09/msg00204.html) > It can deliver my stream in smaller packets, and wait a defined time > until it delivers the next one. Still doesn't work perfekt, but but i > can work with that. Found out that it's much easyer to do the waiting thing in my device. No need for an external program this way. But since the bitrate of the stream varies there's still buffer over- and underflows. Is there a way to get the buffer status of a device? This way i could just stop to deliver the ts packets, when the buffer is full and the other way round. I alredy looked in cDevice but all i found was the ::Flush method. But i'm not shure what it does. Documentation states this: "Returns true if the device's output buffers are empty, i.e. any data which was bufferd so far has been processed." I played araund with this a little, but it doesn't seem to depend on the buffer status... Reagards, Thomas This message was sent using IMP, the Internet Messaging Program. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
Marko Mäkelä wrote: I've patched vdr twice so that it'd read the MPEG TS from a regular file instead of the /dev file system. The first time (about 2 years ago) on then-current vdr 1.3.x, it succeeded. The second time (maybe 1 year ago) failed with the symptoms you are reporting. Do you remember how you patched it? Maybe you could make cDevice::Transferring() return false, if it is a virtual method? Tried that, but it deosn't have any effekt. Reinhard Nissl wrote: But shouldn't the rate at which the TS-packets are gathered from the input device be controlled by the output device? But isn't it obvious that the output device cannot tell the TV station "stop broadcasting, I cannot cope with the data flow"? Hardware buffers on the receiving devices are small and tend to run full quickly when fed at a constant rate. Therefore, VDR tries to offload the receiving device by reading the data as fast as the device allows. I currently do not see a chance to fix this issue with the current API. Several functions would have to be changed to pass the information, that the receiving device may be blocked, to the places where buffer overflows are detected. Bye. Well, I just didn't expect the output device to request the packets as fast as possible, especially when buffer overflows occur. But you're right. When you consider that in the normal transmission theres kind of a "natural" limitation of the transfer rate, the system just doesn't need to deal with this. For the moment i work around the problem with program called "buffer", that i read about in this list (http://linvdr.org/mailinglists/vdr/2005/09/msg00204.html) It can deliver my stream in smaller packets, and wait a defined time until it delivers the next one. Still doesn't work perfekt, but but i can work with that. Just another thought about the timing: MPEG-2 defines rules for a system target decoder, thats in charge for decoding and presenting the media at the right time, using the PTS-stamps in the PES packets. Is this usually done by the driver or is there a VDR instance that deals with this. so, thank you for your answers so far. Regards, Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Transfer Buffer Overflow
Hi there, im currently trying to write a Plugin that reads a DVB-TS-File from hard disk acting as a VDR input device. To do this i derived my own device from cDevice, reading the file into a TSBuffer and return it package wise in GetTSPacket. This somehow works. But the playback is only ok for 2 seconds, and after that it starts hanging and skipping and i get these "transfer buffer overflow" messages. It seems like the data from the file is provided too fast, because the parts that are skipped are much longer than the time playback is stuck. Also i can record from the device, and the resulting File is ok, but if the recording runs for 10 seconds i get a file that is 40 seconds long. But shouldn't the rate at which the TS-packets are gathered from the input device be controlled by the output device? I tried this on two systems, both without DVB hardware: 1: vdr-1.3.44, xine-plugin 0.7.9 2: vdr-1.4.4, xineliboutput-plugin 1.0.0pre5 USER PID SPID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 9118 9118 0.0 11.9 78228 61664 ?Sl 12:29 0:00 ./vdr -Px root 9118 9121 0.0 11.9 78228 61664 ?Sl 12:29 0:00 ./vdr -Px root 9118 9122 0.0 11.9 78228 61664 ?Sl 12:29 0:00 ./vdr -Px root 9118 9123 0.0 11.9 78228 61664 ?Sl 12:29 0:00 ./vdr -Px root 9118 9132 6.0 11.9 78228 61664 ?Sl 12:29 0:03 ./vdr -Px root 9118 9133 10.3 11.9 78228 61664 ?Sl 12:29 0:06 ./vdr -Px root 9118 9134 19.8 11.9 78228 61664 ?Rl 12:29 0:12 ./vdr -Px Feb 2 12:29:06 linux vdr: [9132] transfer thread started (pid=9118, tid=9132) Feb 2 12:29:06 linux vdr: [9133] receiver on device 6 thread started (pid=9118, tid=9133) Feb 2 12:29:06 linux vdr: [9134] TS buffer on device 6 thread started (pid=9118, tid=9134) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 90% (tid=9133) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 90% (tid=9132) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:06 linux vdr: [9132] clearing transfer buffer to avoid overflows Feb 2 12:29:06 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 90% (tid=9132) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:06 linux vdr: [9132] clearing transfer buffer to avoid overflows Feb 2 12:29:06 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:06 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:06 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:06 linux vdr: [9132] setting audio track to 33 (0) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 0% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 90% (tid=9132) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9132] clearing transfer buffer to avoid overflows Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9133] buffer usage: 100% (tid=9132) Feb 2 12:29:07 linux vdr: [9133] ERROR: 1 ring buffer overflow (177 bytes dropped) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 100% (tid=9133) Feb 2 12:29:07 linux vdr: [9134] buffer usage: 0% (tid=9133) [...] Feb 2 12:29:14 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 80% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 60% (tid=9132) Feb 2 12:29:14 linux vdr: [9133] buffer usage: 70% (tid=9132) Feb 2 12:29:14 linux vdr: [9134] buffer usage: 0% (tid=9133)
