Krishna, I'm afraid I'm still confused about what you're asking. Maybe you could give more information about what your overarching goal is?
The decoding time-stamp (DTS) refers to the instant in time when an MPEG-2 decoder is supposed to decode a picture. It describes a moment in the future -- a moment after the frame is received, but possibly before the frame is displayed. It has nothing to do with the amount of computation (whether measured in circuit complexity or time or both) required to decode the picture. Regarding computation time, if you're looking for a ballpark estimate, I would say that on a modern x86 chip, for a typical [EMAIL PROTECTED] bitstream (e.g., HDTV), it takes libmpeg2 less than 1/100 second to decode an I, P, or B frame. You can measure this yourself by running mpeg2dec -o null and seeing what frame rate it reports. Hope this helps, Keith On Fri, 15 Feb 2008, Krishna Prasad wrote: > Hello sir > > Thanks for the reply....But I would like to clarify that "Is the decoding > time is the same as DTS or PTS" as per your reply to the first mail, that is > they are sent with the packet stream headers. > > Can i get to know the usual decoding time required by an I, P and B frame. > As per your reply, I also feel that the time required by the decoding time > headers are very negligible but it can be calculated using gprof, valgrind > and other system commands related to that. > > Cheers > Krishna Prasad > > On Fri, Feb 15, 2008 at 2:23 AM, Keith Winstein <[EMAIL PROTECTED]> wrote: > >> Hi Krishna, >> >> Thanks for clarifying. Better not to call that the "decoding time," which >> is a specific defined term in the MPEG-2 standards. >> >> I don't think libmpeg2 has any built-in facility for profiling itself, so >> you'd have to instrument it (either with gprof or something else) to find >> out how much time was being spent decoding the picture headers. >> >> But just intuitively, I can tell you that the vast, vast majority of >> computation time (>99%) is spent decoding slices (including macroblocks >> contained within). That's where all the heavy lifting of MPEG-2 takes >> place -- the variable-length decoding, the inverse discrete cosine >> transform, the application of motion vectors, etc. >> >> By contrast, the entire picture header, including the picture coding >> extension, is maybe 20 bytes, coming 30 times per second, and it's a >> straightforward list of variables of varying bitwidths. >> >> Conservatively estimating, that probably takes fewer than 500 cycles to >> "decode." So I would say the computation time spent decoding the picture >> header is pretty much negligable. >> >> I'm not sure how nitty-gritty you want to get about "fixed time" -- the >> picture header won't be exactly the same length for different frames, so >> decoding it could take slightly different amounts of time (even if they >> were the same length, nothing can be guaranteed on a modern PC). >> >> But basically, I think the amount of time libmpeg2 spends decoding headers >> (or really, anything other than macroblocks) is very very small. If you >> want more precision than that, you'll have to instrument the code. >> >> Best, >> Keith >> >> On Fri, 15 Feb 2008, Krishna Prasad wrote: >> >>> Hello Kieth >>> >>> I ws referring for the comoutation time required to decode the headers. >> Is >>> that a fixed time for all the frames or pictures...if it is so, what is >> the >>> general time or how do i get to know in the libmpeg2 [mpeg2dec 0.4.1]. >>> >>> I am trying to find the decoding time for a GOP using the mpeg2dec.c >>> >>> Cheers >>> Krishna Prasad >>> >>> On Fri, Feb 15, 2008 at 1:58 AM, Keith Winstein <[EMAIL PROTECTED]> wrote: >>> >>>> 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 Libmpeg2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
