[linux-dvb] Re: section demux rewritten

[emard@softhome.net]

Ralph Metzler writes: 
>  > 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. 
OK, agreed, I'll look for to dump the section immediately and
this would to need some code. I'll try to keep it as simple as I can 
>  > 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.
I planned to support dynamically alloc'ed buffer for purpose
of on-demand stretch or shrinnk buffer as section data creep in.
This is heading toward to allow network all pids reception by dvbnet -p 
8192, which is now non-functional because for 8192 we would have
to alloc 8192 section structs each having 4096 bytes while only few of 
section structs would actuall be in use. 
So average_network_user wouldn't have to care which PID is there,
and as he szap's also restart network apps to change the dvb0_0
for dvb0_1, but instead just register dvbnet -p 8192 and have one
and only dvb0_0 for all network purposes 
> 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.
I see your point, it is of course for the same PID and sometimes
it could last longer. I agree to dump it as soon as we find complete
section in its header's length 
> 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.
:) right, I haven't find them yet but I can imagine
that they might exist 
> 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 ...
The comapre would be beneficial, as it (on my 7146 based card) it 
periodically (1 sec period) reports bursts of longer
out-of-section-syntax data for 1451, while on 451 it reports it
reports out-of-section data much rarely and data are short
(always only 1 byte our-of-section cca 10x a second) 
I wonder between 3 things:
1) do I have phantom DMA issues
2) did we need to implement some new specification standard
3) are they in the TS simply wasting the bandwidth for
 PID 8192 bandwidth > 0.5 full TS bandwidth 
Emard 

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