Matthieu Weber wrote: >>From what I have understood, there is no time stamp in the TS packet > (http://erg.abdn.ac.uk/research/future-net/digital-video/mpeg2-trans.html#MPEG-TS) > but there are two in the PES header: PTS = presentation time stamp, > which is the time when the frame must be played, DTS (optional) = decode > time stamp, which is the time when the frame must be decoded. I would > say that only the PTS is important in our case.
OK, I added PTS parsing. I don't know how good the detection is and it doesn't work if the time is resetted. I have not many streams to test. But I see why they reset the time, it's because they have no choice. They use 33 bit integer (urgs) to store the time, but in the base of 27000000 / 300. The question is: how does the length help us? We use the mpeg length to prevent the user from seeking over the end of the file with mplayer. But since mplayer outputs the PES time, we don't know were we are. Or do we? We know the last PES time in the stream (I hope). But did we have a reset between our time and mplayer time? How often does this happen? > This can be usefule too: http://dvd.sourceforge.net/dvdinfo/pes-hdr.html > >> CALL THE PROTOCOL POLICE! >> >> Why do people do that? > > :) and why don't they include ntp timestamps? And why 33 bit with some marker bits to confuse me? Dischi -- PCMCIA - People Can't Memorise Computer Industry Acronyms ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
