Hi Krishna,
Sorry, I don't understand your question. Are you talking about the
computation time required to decode the headers, or literally the decoding
time (aka, when must a particular MPEG-2 picture be decoded)? I guess the
real question is, what are you trying to do? I think if you gave us more
information about your project, we could help you better.
The decoding time is really part of MPEG-2 part 1 (the systems layer), and
not directly within the province of libmpeg2, which decodes MPEG-2 video
elementary streams, aka MPEG-2 part 2.
Each "access unit" has a decoding time. An "access unit" is essentially an
entire MPEG-2 coded picture (including the preceeding SEQUENCE and GOP
headers, if any).
The decoding time indicates when the decoder needs to decode the picture.
For a B-picture, this will be the same instant as the presentation time.
(Since B-pictures are decoded and then displayed right away.)
For an I-picture or a P-picture, the decoding time is typically earlier
than the presentation time, since the picture is decoded first to use an
an anchor for later-coded (but earlier-displayed) B-pictures. Usually the
presentation time of an I- or P-picture is equal to the decoding time of
the next I- or P-picture.
The presentation time and decoding time are sometimes given explicitly in
the Packetized Elementary Stream header, as a presentation time-stamp
(PTS) and decoding time-stamp (DTS). They're given as a 33-bit count of
ticks in the 90-kHz system/program clock base. And no, that can't really
be negative, although it does roll over to zero every 26.5 hours.
The demux() function in mpeg2dec.c extracts the PTS and DTS and tells
libmpeg2 to "tag" the next PICTURE with that data. That's about all
mpeg2dec does as far as calculating the decoding time goes. If you run
mpeg2dec -v (and it must be on a Transport Stream or a Program Stream,
with the -t or -s demultiplexing options -- once you've gone to the
elementary stream, the PES header is gone, including the DTS and PTS).
But you won't always get a decoding time-stamp -- in fact, you can't put a
DTS on a B-picture. The encoder can only put a DTS on a PES header if (a)
there's the beginning of a PICTURE header in the PES packet, (b) there's a
presentation time-stamp in the PES header, and (c) the DTS is different
from the PTS.
So the rule for figuring out the decoding time is:
(a) If there's a decoding time-stamp in the PES header, that's the
decoding time of the picture whose start code begins in this PES packet.
(b) If there's a presentation time-stamp in the PES header and no
decoding time-stamp, then the decoding time is the same as the
presentation time (given by the time-stamp). You get a presentation
time-stamp at least every 0.7 seconds.
(c) If there's no PTS *or* DTS on the picture, then your encoder is not
being very nice to you. (In practice, I think every stream I've seen
has a PTS on every picture, so you shouldn't have this problem.) If
it comes to this, you have to calculate the decoding time
using the video-buffering-verifier math in MPEG-2 video (part 2).
Anyway, hope that background information helps. If you can clarify what
your real goal is, we can probably help you better.
Best,
Keith
On Thu, 14 Feb 2008, Krishna Prasad wrote:
> Hello
>
> I would like to know about the decoding time for only the pictue headers. Is
> there any standards that gives the time for headers or otherwise how it is
> calculated using the mpeg2dec.c source code.
>
> Can the decoding time be negative?
>
> Cheers
> Krishna
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libmpeg2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
