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.

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 ( 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.


vdr mailing list

Reply via email to