Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Bug in software demux still in 2.6.10



Hi,

Back in august 2004, I wrote an Email to this mailing list about a bug in dvb/dvb-core/dvb_demux.c that sometimes cause the first section received after a tunning to be bad. I didn't find that thread in the archive (?!?! what happened? I've got censured? I've been rude without knowing it? If yes, I'm sorry) so I've put my original email near the end of this one.

After that, Holger Waechtler said:
  sounds like you're right. Do you have a simple fix?

I replied with a patch that he put in CVS. But then some people complained that it was causing buffer overflows so it was removed. I didn't have such problem with my setup (haupaugge NOVA-S and a home soft) and I can understand that my patch may have some side effects unknown to me. But the bug is here and it is still not patched.

So can somebody, with a good knowledge of the dvb_demux.c innards, have a look a it and make a patch? My patch proposal for kernel 2.6.10 is at the end of the email, but it has greate chances of raising the same problems than the one for 2.6.7.

Thanks.


-------------------------------------------------
original email
==============
All,

Sometimes, just after I tune to another transport and I setup the DMX filters, I get some crappy sections (too small or bad CRC). I had a look at the source code (dvb-core/dvb-demux.c) and I think I found the reason for it to have a weird section going out of the demux every once in a while.

Let's imagine that the first packet we receive after starting the filter contains the end of a section (but not the beginning) and the begining of the next one. dvb_dmx_swfilter_section_packet is called with that guy in parameter. We have PUSI=1 so we have the following code executed:

  - dvb_dmx_swfilter_section_copy_dump is called with the end of the previous section (before .. before+before_len)

  - dvb_dmx_swfilter_section_new

  - dvb_dmx_swfilter_section_copy_dump is called with the beginning of the next section (after .. after+after_len)

If you look how dvb_dmx_swfilter_section_copy_dump is implemented, it will forward everything that looks like a section. So if the end of the previous section looks remotely like a section, it will be forwarded to the demux device.

I think a special case must be done for the first packets and all the data received before the first section start must be ignored.

What do you guys think?

Thanks
-------------------------------------------------
2.6.10 patch
============

--- dvb_demux.c.org     2005-01-04 11:27:10.000000000 +0100
+++ dvb_demux.c 2005-01-04 11:31:42.000000000 +0100
@@ -340,7 +340,8 @@
                        const u8 *after = before+before_len;
                        u8 after_len = count-1-before_len;

-                       dvb_dmx_swfilter_section_copy_dump(feed, before, before_len);
+                       if(feed->feed.sec.tsfeedp > 0)
+                         dvb_dmx_swfilter_section_copy_dump(feed, before, before_len);
                        dvb_dmx_swfilter_section_new(feed);
                        dvb_dmx_swfilter_section_copy_dump(feed, after, after_len);
                }
@@ -350,7 +351,7 @@
                                printk("dvb_demux.c PUSI=1 but %d bytes lost\n", count);
 #endif
        }
-       else
+       else if(feed->feed.sec.tsfeedp > 0)
        {
                // PUSI=0 (is not set), no section boundary
                const u8 *entire = buf+p;




Home | Main Index | Thread Index