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
Hi, [EMAIL PROTECTED] wrote: 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. There is at least a cRingBufferLinear instance in cRemux, that is not related to any device, i. e. cRemux sits between the receiving and the replaying device. Just try to modulate the exhaust of TS packets as I suggested in my last email. This should avoid buffer over- and underflows. You're welcome to ask for further assistance ;-) 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... This function is (only) used by vdr-xine to give xine a chance to display all the decoded and internally buffered frames when VDR replays a recording and reaches its end. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
Hi, Thomas Lagemann 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. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ 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
Re: [vdr] Transfer Buffer Overflow
On Fri, Feb 02, 2007 at 10:24:51PM +0100, Thomas Lagemann wrote: 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? Sorry, no, I didn't save the working patch, because I felt it was a trivial modification. If I remember correctly, I replaced the variable that is assigned /dev/ + something with a character string constant, the absolute pathname of the MPEG TS file. There probably was some wrapper around the open() call. I don't remember changing anything else, but I cannot tell that for sure. I really should have saved the patch that worked. It was just a one-off thing to get a MPEG TS recording converted. The second time (when I failed to patch vdr properly) I ended up using mencoder and genindex. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
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. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
