[vdr] VDR-1.3.27: updated cVideoRepacker

[Reinhard Nissl]

Hi,

Stefan Lucke wrote:

>>> - a quick reminder of why this needs to be changed, and 
>>
>>VDR's index file for recordings has byte granularity but adresses 
>>complete PES packets. When VDR needs to send an I frame to a device (e. 
>>g. for fast forward or editing cutting marks) it seeks to the index of 
>>the I frame and reads the data up to the next B frame, i. e. it stops 
>>just before the PES packet which contains the start of the B frame. But 
>>it is likely that this packet also contains the tail of the I frame 
>>before the B frame starts. So VDR will read to few data which results in 
>>an incomplete I frame. The result is that xine doesn't show incomplete 
>>frames, i. e. moving a cutting mark results in no screen update. 
> 
> Are there some sample streams available ? I'm asking this because I
> get an updated picture upon moving cut marks. That is with
> softdevice running with vdr-1.3.27 and vdr-1.2.1 recordings. 

Well, any stream will do, especially HDTV streams. The result depends on 
the implementation. When softdevice displays incomplete frames, 
everything works almost properly. Maybe you see that part of the image's 
last slice may be black or garbage.

xine-lib discards incomplete frames. The problem exists for quite a long 
  time already. My first approach in successfully displaying a still 
image was to send the data 4 times to xine. But this didn't work anymore 
when I wanted to edit cut marks for the HDTV broadcast Spiderman. After 
debugging a lot, I realized that the I frame was incomplete. The last 
slice was completely missing.

With the patches it is now possible to send the still image just once to 
xine, which speeds up moving cut marks accordingly.

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