On Thu, 4 Sep 2008, Roger Heflin wrote: > Kevin, > > In the US the ATSC streams come with timestamps encoded in them from the start > of the some time earlier (I don't know when), normal recordings made with a > pvr150 start at 0, so most direct digital recordings left timers don't > actually > work because the timestamps are were not 0 to start with and in some cases > appear to be larger than the mvpmc hardware library can return (I added some > code around it to see what was coming back and I was usually getting back 0). > If you run it through mplayer the A: and V: numbers should start with large > non-zero second counts, and those seconds should translate to the time that > shows on the left if my observations are correct and also hold for the UK.
You're basically right here.... The time that is displayed here is derived from the the MediaMVP's hardware MPEG decoder's STC (System Time Clock). This clock is used to keep the video and audio in synchronisation. All the video/audio packets sent out are encoded with a PTS (Presentation Time Stamp) in their headers, and should be displayed when the STC reaches its PTS. The hardware MPEG encoders used for broadcast channels just start the PTS at 0 when they're turned on, and increase it's value from there until it reaches its maximum 33-bit value, at which point it rolls back round to 0 again. So the values in recordings off these channels will be fairly non-sensical. > I don't even get useable numbers on the left on most of the (untranscoded) > ATSC > recordings, each time I seek the number starts over at 0, I believe that is > because the numbers encoded into the stream are too large for the mvpmc to > deal > with properly. Er, no, mvpmc is able to deal fine with these values (*)...The mvpmc code actually resets the MPEG decoders STC to 0 after a seek. This is because if you do a small seek (of the order of a few seconds), the MPEG decoder doesn't jump its STC to reflect the discontinuity in PTS values of the video/audio data its being fed, so mvpmc has to force a STC reset to 0. The STC should re-sync to a sensible value after a couple of seconds. (*) Although the mvpmc code only pays attention to the 32 least significant bits of the PTS/STC values in a lot of places, this doesn't really matter or affect this value. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
