[vdr] VDR-1.3.41: speedup for cVideoRepacker

[Reinhard Nissl]

Hi,

Jon Burgess wrote:

>> +bool cVideoRepacker::ScanDataForStartCodeFast(const uchar *&Data, 
>> const uchar *Limit)
>> +{
>> +  Limit--;
>> +
>> +  while (Data < Limit) {
>> +        if (*Data > 0x01)
>> +           Data += 3;
>> +        else if (*Data == 0x00)
>> +           Data++;
>> +        else if (Data[-2] != 0x00 || Data[-1] != 0x00)
>> +           Data += 3;
>> +        else {
>> +           scanner = 0x00000100 | *++Data;
>> +           return true;
>> +           }
>> +        }
> 
> Did you consider using memchr()? e.g. something like
> ...
>   while (Data < Limit) {
>         Data = memchr(Data, 0x01, Limit - Data);
>         if (Data == NULL)
>            break;
>         if (Data[-2] != 0x00 || Data[-1] != 0x00)
>            Data += 3;
> ...
> 
> It makes no noticeable difference on my AMD64 machine (<1%), but maybe 
> it is worth trying on your EPIA?

I don't think that it is worth a try as it tests every byte while the 
above code tests most of the time only every third byte.

Consider the following data:

hh ii jj kk [ 00 00 01 01 ] mm nn oo 01 01 pp 01
^^^^^^^^^^^^^^^^^^^    ++++++++++^^^   ^   ^^
                   6                4   0    1

which will give you the above distance between consecutive 01 which are 
not part of a startcode (i. e. first slice start code [ 00 00 01 01 ]) 
or immediately following a startcode (the area marked with +++++). ++ or 
^^ indicate bytes which have to be considered for the distance.

For the above case, a statistical analysis will give this numbers:

distance: 0, count: 1
distance: 1, count: 1
distance: 2, count: 0
distance: 3, count: 0
distance: 4, count: 1
distance: 5, count: 0
distance: 6, count: 1
distance: >, count: 0

Now consider real data, like 001.vdr of "Wetten, dass ..?" which was 
broadcast last Saturday on ZDF:

distance:  0, count:    75248
distance:  1, count:   519949
distance:  2, count:   316632
distance:  3, count:   331874
distance:  4, count:   381855
distance:  5, count:   367280
distance:  6, count:   370620
distance:  7, count:   369649
distance:  8, count:   405861
distance:  9, count:   360555
distance: 10, count:   332593
distance: 11, count:   366192
distance: 12, count:   319692
distance: 13, count:   313795
distance: 14, count:   309567
distance: 15, count:   305986
distance: 16, count:   297510
distance: 17, count:   291607
distance: 18, count:   286045
distance:  >, count: 18794252

As you can easily see, it's a waste of time to test every byte (= 
distance 0) for 01 as it is very unlikely to find one.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de