[vdr] VDR-1.3.27: updated cVideoRepacker
rnissl at gmx.de
Sat Jul 23 21:29:34 CEST 2005
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.
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
More information about the vdr