Hi list,
Attached is a new version of cDevice::PlayTsVideo and cDevice::PlayTsAudio that properly handles partially accepted buffers of the PlayVideo and PlayAudio functions. The original functions would discard any partially written data.
These two functions are only used by devices that do not implement their own PlayTsXXX functions. The FF DVB devices don't use them any more, since TS is passed to (patched) DVB drivers. Other devices will soon play TS directly too.
However, it might still be useful for patches that restore support for older drivers. ;)
Cheers,
Udo
On 25.01.2009 23:53, Udo Richter wrote:
virtual int PlayVideo(const uchar *Data, int Length); ///< ... ///< PlayVideo() shall process the packet either as a whole (returning ///< Length) or not at all (returning 0 or -1 and setting 'errno' accordingly). ///< ... virtual int PlayAudio(const uchar *Data, int Length, uchar Id); ///< ... ///< PlayAudio() shall process the packet either as a whole (returning ///< Length) or not at all (returning 0 or -1 and setting 'errno' accordingly). ///< ...
By definition these two functions shall write "all or nothing". So the higher level functions needn't handle any partially written data.
Klaus
On 26.01.2009 08:39, Klaus Schmidinger wrote:
But in fact they write all or nothing or timeout after one second, in which case they return how much was written. And it seems as if these timeouts do happen.
If you change that behavior so that they never timeout (like in VDR 1.7.2/1.7.3), then PES playback frequently hangs for fractions of a second for me.
And with the timeout and no partial buffer handling (as in VDR 1.7.4), any TS playback frequently drops the remains of a buffer, causing massive picture breakdown.
Cheers,
Udo
On 26.01.2009 12:10, Udo Richter wrote:
I did some more investigating, and things get really strange...
First, there's no evidence for the 1000ms timeout to actually happen. Data in fact seems to be written 'all or nothing' in reality. Both cases, all and nothing, do happen.
The PlayTS functions however are still wrong, since they do not handle the case where -1/EAGAIN is returned immediately. The PES packet was returned by GetPes and will not be returned again, so this PES packet will be dropped.
I also experimented with the VDR-1.7.3 solution again:
do { w = WriteAllOrNothing(fd_video, Data, Length, 1000, 10); if (w < 0 && errno == EAGAIN) { cPoller Poller(fd_video, true); Poller.Poll(200); } } while (w != Length);
WriteAllOrNothing returns either Length or -1/EAGAIN. The poller sleeps for about 0-20ms each time. CPU load isn't too high either. Still I have an ARD recording that reproducibly hangs at the same point every time for a fraction of a second, and only if I use the above loop. This happens 1-2 times per minute, and usually causes heavy audio/video desyncing.
The VDR-1.7.1/VDR-1.7.4 version does not show this hang:
return WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
Anyone has an idea what really causes this?
Cheers,
Udo
-
Klaus Schmidinger -
Udo Richter