Hello,
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?
/Werner
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?
Bye.
On Sunday 06 November 2005 10:58, Reinhard Nissl wrote:
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?
Bye.
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.
/Werner
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.
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.
In the sample you sent me, there really are two picture start codes in one PES packet. You've already got the attached patch which records a snipplet of the TS stream in such a case.
Do you already have some test material, as I'm ready to replay and debug it?
Bye.
-
Reinhard Nissl -
Werner