[vdr] Re: [PATCH] (DVB-T) statmux fix vbr tagging for pic header

[Gregor Lawatscheck <gpel@mpex.net>]

>From my limited point of view, I think it would be better to set
>only the vbv delay without touching the rest:

> p[i + 5] |= 0x07;
> p[i + 6] |= 0xFF;
> p[i + 7] |= 0xF8;

Quite right... I've had learn bitwise manipulation first, certainly the 
better way of doing it :)

> IMO we should not modify the data during recording.
> We should fix it during replay. It's a firmware bug and it should be
> fixed in the firmware. If this is not possible it should be fixed in
> the driver.
I completely agree. I've submitted it as a patch but wouldn't like to see 
it applied to the sourcetree just yet. It was intended for testing. As you 
say it should be fixed in the firmware, if not there then in the driver. 
Only as a last resort by some sort of special setting in channels.conf 
should vdr have to deal with it.

Moreover it looks like just tagging just the I-FRAME once it's synced 
doesn't help the situation reliably enough. For some reason it needs to be 
done outtside case VIDEO_STREAM_S ... VIDEO_STREAM_E (odd, I'll look into 
it) and there are better effects (i.e less sporadic deadlocks) by setting 
vbv_delay to 0xFFFF throughout
i.e.

   if (PictureType != NO_PICTURE) {
                              resultBuffer[i + 5] |= 0x07;
                              resultBuffer[i + 6] |= 0xFF;
                              resultBuffer[i + 7] |= 0xF8;
                        }

Setting it on NO_PICTURE breaks stuff. PVAStrumento likewise sets it for 
all but NO_PICTURE.

> This might also help with old RTL recordings that cannot be played with
> the current firmware. I haven't had the time yet to look into this
> issue but I'll try to do this next weekend.
Thanks - sounds good. I hope this can be fixed in the firmware / driver...

- Gregor 


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