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@xxxxxx
