live tv problems on high bandwith

[avvdr]

Hi all,
after I had a couple of problems especially on high bandwith channels (ARD I)  - vomp locked or crashed, I had some code review and found there is no protection for the shared data structures in playerlivetv. But at the end there are 3 threads working on them - receiver,player,GUI. This can easily lead to data corruption. On the other hand the playing thread could block forever...
So I created some patch that solved the problems (based on cvs 2008/11/28).
Additionally I also rewrote the ts demuxer to avoid at least copying all the data twice - this seemed to increase the performance a bit (less artefacts).

I attach the patches here.

Andreas

[MarkC]

Thanks for the patches. The lack of data locking in the player is certainly a problem. I guess Chris will want to look at this, so I won't apply any changes yet.

I don't understand what the problem is with the demuxer. Can you explain what you mean by "copying all the data twice"? I've had a look at your patch and I think your main concern is with the store[TS_SIZE] array. However, most of the data is written directly from the input buffer ("buf" in the put method) to the PES packets. store[] is used for packets that are split between two calls to put, and yes, these packets are copied twice. But that's just 188 bytes per put, and TV data is received in 50K chunks, so only 0.4% of the data passes through store[].

Maybe I've misunderstood your patch, or maybe the demuxer isn't working as I intended it to. It could also be that your rewrite has removed a bug that was previously causing artefacts.

[avvdr]

Hi,
with the demuxer I'm not really that sure - I was searching for some performance improvements because I saw the demuxer thread (i.e. the player thread) just consuming all the CPU - but most probably you are right - at the end I it's not really clear if the patches did improve anything - at least before them I had a lot of dropped chunks (i.e. artefacts in the video) - afterwards much less. But maybe the demuxer part did not really help a lot (was just to provide it as a basis for discussion).
Maybe you have some other ideas why the demuxer takes that much CPU (for mpeg videos it seems to be much less - even with the demuxer being very similar (of course not handling the ts packets)...
In fact the high CPU usage was really driving the crashes and deadlocks because it increased the chance for multiple threads accessing data at the same time.
But I guess with the changed locking this should not be a problem any more. Anyway it just occurs on really high bandwith channels.

regards
Andreas

[MartenR]

I think that the problem might be in the afeed and vfeed class or in the stream class.
I have seen that the effect of high cpu usage several time during debugging and I think that it is a full buffer.
Maybe we have to change the feeding mechanism from polling to some more interrupt behaviour and/or adjust the ratio of audio and video buffers.
Since the effect might be caused if one of the two buffers is running full.

Marten