[linux-dvb] Re: [PATCH] section demux rewritten

[Ralph Metzler <rjkm@metzlerbros.de>]

Emard writes:
 > >  > builds some larger chunks
 > >  > without PUSI, to still avoid loosing some section data. 
 > >  > (in few tests so far I haven't seen building them over 4096 but..)
 > > 
 > > If that really happens (doubt it) they are sending a broken stream.
 > > Your truncate_copy prevents access to more than 4096 bytes anyway.
 > 
 > I'm planning to use same #define in truncate_copy so it could access over
 > 4096 if #define is set so. So far there's no need for it but I hope I
 > will find a TS where it will be a benefit of

You can always dump one section before 4097 is reached, even if such
TS you describe exist. 
 

 > > I don't understand several other things in your code:
 > > 
 > > - unnecessary pointer juggling (when is secbuf ever not finally reset to
 > >   secbuf_real in the dump routine?)
 > 
 > This is the true pointer mastery, to minimize changes accross the code.
 > I could have passed pointer from dump routine to the next layer section
 > code, but then I have to modify next layer code too. By juggling of the 
 > pinter I just avoided touching other code than directly involved with the
 > problem I was fixing
 > 
 > secbuf is always saved before the juggling and when the juggling is
 > over, secbuf is reverted to the saved value. This is universal approach, 
 > will work for secbuf_real as well for malloc()ed secbuf

OK, if you plan to use it for other stuff.
I was just confused that the saved value right now would always be the
same.

 
 > > - probably timing problems with low bandwidth PIDs with long (>183
 > >   bytes) sections (think about when dump is called in this case)
 > 
 > I don't see a problem, because sections spanning over 1 TS packet will be 
 > finished and dumped instantly as they are received, if we assume the
 > PUSI=1 bit is set as it has to be set and the stream is not wasting 
 > its bandwidth by padding sections to the end of TS, 
 > 
 > Even if it does, in worst case section will be dumped before the start of 
 > next section's TS packet. 

Exactly.
 
 > There's never going to be any delay longer than 1 TS-to-TS span.

I see it as: "There will be delays up to one TS-to-TS span (of
the same PID)". This can be a long time (seconds) in the worst case.
It should be dumped as soon as possible.



 > > - thrown away CC checking
 > >   of course it it not foolproof (e.g. if you miss exactly 16 packets of one PID)
 > >   but at least it can show minor dropouts and reject this data.
 > 
 > I plan to again use CC checking, but I'm still considering a some smart way to
 > apply CC checking in smart way, so that it also minimizes loss of the good data 
 > before that have been received before CC was found discontinuous

There should not be any other broken data from before if it already
was dumped in time. Unless those broken TS which you did not find yet exist.

 
 > > The only advantage (less copying with small sections in same packet)
 > > is trivial to add to the old code.
 > 
 > Really? but what about the boundary conditions in the old code, prematurely
 > discarding the section (see my fix to your code of previous week) 
 > or loosing data e.g. at section boundary conditions.

That was to the Convergence code tree. I did not compare it to my
current code yet. But if the other code is fixed now anyway ...


 
Ralph


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.