How to start a program from satelite?

[Jean-Paul Saman]

Arnaud de Bossoreille de Ribou wrote:
> 
> Ok, here we go... :-)
> 
> 1/ A little bit of theory about the NetList.
> 
> It shouldn't be empty provided that
> 
>  sizeof(NetList) >= sizeof(internal bufferization) + sizeof(SyncFifo) +
>                     sizeof(output buffer) + 1
> 
> Why ? Simply because before getting another packet from it the caller is
> blocked by the SyncFifo.
> 
> The problem in the DVB input is that there may be a lot of SyncFifos for
> only one NetList. So I put a big size for the NetList (500) and small
> sizes for the SyncFifos (2 * sizeof output buffer) and we have to pray
> about the fact that there are not enough programs to have a packet
> shortage. _Yes_ this is a kludge.
> 
> 
> 2/ Now the SyncFifo.
> 
> I think one problem is that the both Push and Pop methods of C_Fifo
> are modifying m_iSize at the same time. I never saw this problem in 3
> years of use but I've made a little patch I suggest you to try (diff
> attached).
> 
This is a threading problem (two functions manipulating the same 
counter) it manifast itself on a *very* fast machine,

The patch solves the problem adequately I think.(with the limiting 
testing I did) Provided that the counters are correct at any one time.

> The ASSERT above say that
> 
>   - either a NULL packet has been pushed but there should have some
>     other assertions before so I don't think this possible;

I think a NULL packet has been popped.

>   - or the Fifo has a bug which may be solved by my patch.
> 

The patch seems to solve the problem in SyncFifo with m_iSize. You're 
solution to this problem is cleaner, then mine ;-).

> 
> Just for me: could you remind me which architecture you use ?
> 
I did not tell you yet ;-) Here it goes:

The server is a dual Pentium Xeon 1,7 GHz with 2 Hauppage WinTV Nova for 
DVB streaming from satelite. Running Linux 2.4.18 smp + preemptible + 
lowlatency patches.

We over dimensioned a bit.;-)

> 
> 3/ I don't know why you have to check the continuity of the TS stream
> since the packets can't be lost in VLS (or it's a bug).
> 

The best way to tell if your TS stream is correct is to check for every 
PID the continuity counter (according to MPEG specialists here). If 
there is a discontinuity then a packet has been lost, between the curent 
measurement and the last.

I have several reasons:

1) To make sure the stream I play does not have any inconsistencies 
somewhere along the chain. Also inside vls. We have two different usages 
for vls.
1) file -> reader -> converter -> queue -> streamer -> netout -> network 
-> client
2) dvb -> reader -> converter -> queue -> streamer -> netout -> network 
-> client

2) The bug in vls you just pointed out.
- Due to those problems vls did pop() an empty packet and had a wild 
running m_iSize pointer in SyncFifo. Got modified by Pop and Push in an 
undetermined way (threading problem).
- A packet got lost when the SyncFifo was full. I encountered that in my 
tests and of course this introduces artefacts in the stream. Hence the 
test for continuity.

If you know the file you read is correct at TS level and correct at the 
converter, but has inconsistencies in the streamer. Then you know for 
sure that between converter and streamer there is an error (probably a 
lost packet).
But if at the reader there is a inconsistency, then you should distrust 
the correctness of the file. Which by the way is read from the DVB-card. 
It helps me pin-point errors, when I build more functionality in this chain.

I need two measure points for the Continuity Counter in VideoLAN server 
one at the input and one at the output, My first guess is:
+ one at the start (convertor) and
+ one at the ouput (streamer).

What is according to you the correct place in the code for this?

-- 
Kind greetings,

Jean-Paul Saman

Software Architect

e-mail (work): saman at natlab.research.philips.com
phone  (work): 040 27 42909
------------------------------------------------------------
Ordina TA,
Science Park Eindhoven 5602, Postbus 293, 5600 AG Eindhoven
e-mail : jean-paul.saman at ordina.nl
phone  : 040 2601200
fax    : 040 2601199


-- 
This is the vls-devel mailing-list, see http://www.videolan.org/vls-devel/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>