Simon Hyde wrote:
> 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.
>
It is not ever coming back to a sensible value after a seek on a straight ATSC
recording. The % value is sensible, the the time value starts and counts from
0 after a seek.
And I checked the values coming out of the ioctl and they appear to restart at
0
after a seek and continue counting (from 0) until the next seek again sets them
back to 0.
But this is only on original ATSC recordings, after I transcode them everything
is fine.
Roger
-------------------------------------------------------------------------
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/
