Hi Keith
The problem was with the code [on the subtraction betwen the stop and start
time between the pictures] as you said. I have
removed the errror and I wanted to ensure, whether the following steps in
the below is the procedure to calculate the decoding time?
In the soource code mpeg2dec.c, in the function "void decode_mpeg2", in the
*CASE STATE_PICTURE*, I start a timer (t1) and end the timer(t2) in the *CASE
STATE_SLICE. *I calculate the difference in both the timers [t2-t1 = diff]
which I suppose is the decoding time for picture1.
For picture 2, in the *CASE STATE_END,* I find the difference in the ending
time(t2) of picture2 with the timer t1 and subtract it with the previous
difference [diff] to calculate the decoding time required for frame2. This
is the proecedure which i follow to calculate the decoding times for all the
frames in the GOP.
All the time values are positive here.
This is how I am calculating the decoding times for all the frames in the
GOP and I think it works efficiently for closed GOPs.
I am thankful to you for the replies you have given to me from time to time
which was quite useful.
If there any more doubts, I will keep you posted.
Cheers
KrishnaPrasad
On Fri, Feb 15, 2008 at 1:16 AM, Keith Winstein <[EMAIL PROTECTED]> wrote:
> I see. No, it's not possible to take "negative time" to decode a frame. If
> you're getting negative numbers, probably you have a bug in your code
> where you subtract one struct timeval from another?
>
> Good luck!
>
> Keith
>
> On Fri, 15 Feb 2008, Krishna Prasad wrote:
>
> > Hello Sir
> >
> > Actually I wanted to calculate the decoding times for the I ,P and B
> frames
> > in a GOP.
> >
> > Using the code in mpeg2dec.c may i know the steps that would be used in
> > calculating the same. Currently, I have done up to understanding the
> logic
> > part up to state_picture, state_slice etc.....
> >
> > In this connection, i m using the gettimeofday function to calculate the
> > difference in times in the various case statements.But sometimes it
> comes
> > out negative which i hope is possible.
> > Hence forth, I was roughly estimating the decoding time for the various
> > frames.
> > since, the picture header is also present, I couldn't analyze in the
> code of
> > getting the time for decoding the picture header.
> >
> > But still, I have certain ideas through which it can be calculated based
> on
> > certain assumptions which I will post in my next mail if required.
> >
> > Thanks for the reply...If i have doubts, I will keep u posted.
> >
> > Cheers
> > KrishnaPrasad
> >
> > On Fri, Feb 15, 2008 at 2:51 AM, Keith Winstein <[EMAIL PROTECTED]> wrote:
> >
> >> 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
