Hi, Werner wrote: >>>in recent recording from premiere i saw that not all pictures in >>>the data stream are indexed in index.vdr. The displayed movie lenghts are >>>slightly to short and the cutmarks in marks.vdr are wrong. I use >>>marks.vdr in an external program. The resulting cutted movies are >>>sometimes about 1-2 minutes too short. This does not affect normal >>>vdr users too much because vdr cutted movies have the right len. >>> >>>Im not an mpeg expert, so only some speculations: >>>It looks that every index.vdr entry points to an "packet start code" >>>(0x000001). Vdr assumes that every packet has mostly one picture start >>>code. The difference i saw between old recordings and new recordings >>>is that in new recordings are sometimes two picture start codes in a >>>packet. The second one is dropped by vdr. >>>I have no idea of how to fix this assuming that vdr can only resume >>>on a packet start code. Anyone any idea? >> >>If you were right, then cVideoRepacker is buggy. Are you shure that you >>see two picture start codes (0x00000100) in one PES-Packet? > > yes, thats what i saw. My app demuxes the data stream (with the help > of some libmpeg2 code) and two printfs show that sometimes (<5%) there are > two picture start codes in a packet. I assume you've used at least VDR-1.3.32 for taking the recording. Please run the attached hack (chECKpICTUREsTARTcODEpERpESpACKET) on an uncut recording where your software complains, like that: cat 0*.vdr | chkpscppp No news means good news ;-) But in the expected case, would you please provide me with a little sample for downloading? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx -------------- next part -------------- A non-text attachment was scrubbed... Name: chkpscppp.cpp Type: text/x-c++src Size: 1270 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20051106/f48f586b/chkpscppp.cpp
