> > If I took the TS of something predictable and outputting result, I could > > binary search in the TS and find it or at least locate neighbouring packets > > that are before and after the missing one, so in the TS the missing one > > should be located inbetween them most likely. > > That would be most helpful.
Of course it's a huge bulk of data, we need something in common for a reference. Perhaps we can sync our clocks with ntp servers to get them in the one second precision, define the time of the reception and sample 20 seconds of the same TS, you capture and analyze raw TS and I will analyze it with ethereal and send you a small binary file of several KB with the missing packet inside, missing data replaced with 00-bytes Provided the stream has neighbouring data of sufficient uniqueness (a compressed data e.g.), You can binary search neighbouring data in the TS and exactly locate in TS place of the missing data > Well, go ahead. This part (buf[p]!=0) worked in tests but maybe > there are special cases where it does something wrong. > Since it seems the version in linuxtv CVS was changed it may > also not react the same as the original version but I want to test > my new code anyway. That's right, I have rewritten the section code very cleanly and obvios, but now I'm going to boot the test disk... wish me luck and save me from oops > Could be. But would they already start doing this at half bandwidth? They could, because at half bandwidth something must go back-to-back so it has to be sent with packing/optimization Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
