[vdr] VDR-1.3.27: updated cVideoRepacker

[Stefan Lucke]

On Samstag, 23. Juli 2005 21:29, Reinhard Nissl wrote:
> 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.

Thats the same as softdevice does.

>  But this didn't work anymore 
> when I wanted to edit cut marks for the HDTV broadcast Spiderman.

Oh, I never tried HDTV streams.

> 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.

That sounds fine. I'll try "sending once" in softdevice too.
Thanks for your explanation.


-- 
Stefan Lucke