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