Hi,
libmpeg2 has a program called mpeg2dec.c, which can demultiplex and
decode a static transport stream file(.ts) . I modified the program in such
a way that it can accept the input on a UDP port ,where each packet is of
length 188 bytes and then i am sending that recieved packet for
demultiplexing and decoding.As of now i am hardcoding the pid of the video
packets for demux.
The problem that i am facing is that ,i am
not able to test my program properly. I am using vlc player to stream the
(.ts) file on to the port, on which the mpe2dec.c listens .To my irony i
find that the value of the bytes in the packet which i recieve are different
from the value of the bytes which are actually present in the static file .I
used ethereal to see the contents of the actual (.ts) file. So my doubt is
whether VLC actually changes the value of the bytes of a static file(.ts)
when it streams out.? I am ready to clairfy a bit more on this if
required....
The question seems to be a bit out of context from
libmpeg2 ,but if any one can help me on this ,then that would be really
grateful.
Thanks & regards
anand.
On 4/5/07, anand meher <[EMAIL PROTECTED]> wrote:
hi keith,
thanks a lot.I think whatever u have suggested should definitely
work,the problem is that libmpeg2 is not properly documented and it takes
some time to understand the functions.
hope i have not disturbed
u by my chain of mails. this is my last mail for today .....any more doubts
i will definitely route it to u :)
.wish u a happy
easter .
thanks & have a nice day
byeeee
regards
anand.
On 4/5/07, Keith Winstein <[EMAIL PROTECTED]> wrote:
>
> Hi Anand,
>
> I'm sorry, I was mistaken. mpeg2_getpos() returns the amount REMAINING
> in
> libmpeg2's buffer -- not the absolute position within the stream, as I
> wrongly said earlier.
>
> That buffer is replenished when you call mpeg2_buffer() to load more
> bytes
> into the decoder.
>
> So if you want to track position in the stream, you have to save,
> yourself, a running count of the number of bytes you've fed into the
> decoder. You're probably calling mpeg2_buffer() in the demultiplexer, so
>
> that's where you'd have to keep track of this running total.
>
> Check out mpeg2dec.c for an example of how to do this.
>
> ##############
>
> // It defines:
> static int total_offset = 0;
>
> // Every time we load more bytes into the buffer, we add that to the
> // running total:
> mpeg2_buffer (mpeg2dec, current, end);
> total_offset += end - current;
>
> // to get the absolute position within the stream at a certain point:
> total_offset - mpeg2_getpos (mpeg2dec)
>
> ##############
>
> Also, keep in mind that this method will give you the absolute position
> in
> the elemental stream -- after demultiplexing. None of the systems-layer
> headers (TS, PES, etc.) will be included in the count.
>
> Sorry to have confused you,
> Keith
>
> On Thu, 5 Apr 2007, anand meher wrote:
>
> > Hello,
> > thanks keith for your quick reply .ya,whatever you say makes
> a
> > lot of sense. Actually i am using a transport stream as a input.i am
> using
> > demultiplex functions of mpeg2dec.c and then the decode functions.
> >
> > I dont know much about mpeg2 and other codecs, so u need to clarify me
> on
> > one thing. will the no of bytes of definition of pictureheader differs
> for
> > I,B,P frames?If its the same,then my code makes sense.
> >
> > What i observed using mpeg2_getpos() is that it gives the position in
> the
> > current 188 byte packet which is being decoded (in decode_mpeg2).
> >
> > the other difficulty i am facing is that the definition of a frame
> extends
> > over to the next 188 byte packet. so when i actaully take the
> difference of
> > mpeg2_getpos() in STATE_SLICE and STATE_PICTURE, i have started
> getting
> > negative frame sizes :) .
> >
> > so what i am doing now is (return value of mpeg2_getpos() in
> > STATE_SLICE)+(188-(return value of mpeg2_getpos() in STATE_PICTURE).
> hope u
> > have understood my problem. i can calrify you on this a bit more if
> > required.
> >
> > so i need calrification whether
> what i
> > am doing is correct or not..
> > I can use the secondary method u suggested but i am using,libmpeg2
> already
> > for getting the other info like chroam_width etc......
> >
> > thanks in advance
> >
> > regards
> >
> > anand
> >
> >
> >
> >
> > On 4/5/07, Keith Winstein <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi Anand,
> >>
> >> For most real-world streams, that will give you something very close
> to
> >> the exact answer, sure. So yes, I think that should work fine.
> >>
> >> I hesitate for two reasons:
> >>
> >> (1) A picture can have more than one slice, I think, even in the Main
>
> >> Profile. I don't think I've ever seen this in a real stream,
> though.
> >>
> >> (2) Technically, you're calling mpeg2_getpos() AFTER libmpeg2 has
> parsed
> >> the header. So when you're in STATE_PICTURE, your position will
> be at
> >> the end of the picture header, not the beginning of it. This
> only
> >> makes a tiny difference but if you need the "exact" frame size,
> >> you might care about this.
> >>
> >> If you want to do this absolutely perfectly correct, don't use
> libmpeg2 at
> >> all. Just search the MPEG-2 elemental stream for the four-byte string
> >> {0x0, 0x0, 0x1, 0x0}. That's the start of a picture header. Then
> search
> >> for the next picture start code (0x0 0x0 0x1 0x0). That's the start
> of the
> >> next picture. Done -- the difference in absolute position between
> these
> >> two start codes is the number of bytes required to code the picture.
> >>
> >> If you want to have a more refined definition of what the "exact
> frame
> >> size" means, you might want to also stop counting when you get to a
> new
> >> sequence header (0x0 0x0 0x1 0xB3) or an end-of-sequence header (0x0
> 0x0
> >> 0x1 0xB7), and then don't start up the count for the next frame until
> you
> >> hit a picture start (0x0 0x0 0x1 0x0).
> >>
> >> But unless you care about being absolutely precise down to the last
> few
> >> tens of bytes, your method will work fine.
> >>
> >> Hope this helps,
> >> Keith
> >>
> >> On Thu, 5 Apr 2007, anand meher wrote:
> >>
> >> > Hi,
> >> > i am trying to find the frame sizes (in bytes ) using
> decode_mpeg2.
> >> >
> >> > Can i take the difference of
> >> > mpeg2_getpos() return values when it hits the STATE_PICTURE(when
> the
> >> picture
> >> > header is found) and STATE_SLICE(when the last slice of a picture
> has
> >> been
> >> > found) to get the exact frame size.
> >> > Thanks in advance
> >> >
> >> > regards
> >> >
> >> > anand
> >> >
> >> >
> >> >
> >> > On 4/5/07, Keith Winstein <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Hi Anand,
> >> >>
> >> >> Please reply to the list in case somebody else wants to chime in.
> >> >>
> >> >> mpeg2_getpos() returns the total number of bytes (octets) since
> the
> >> start
> >> >> of the stream. So yes, you will have to take the difference
> between
> >> >> hitting one PICTURE header and the next header (probably PICTURE
> or
> >> >> SEQUENCE) in order to find the coded length of the picture (in
> bytes).
> >> >>
> >> >> There's basically no way to determine the coded length of the
> picture
> >> >> until you hit the next header.
> >> >>
> >> >> Best,
> >> >> Keith
> >> >>
> >> >> On Wed, 4 Apr 2007, anand meher wrote:
> >> >>
> >> >> > Hi kieth,
> >> >> > As i mentioned earlier i am looking for the frame
> >> >> > sizes(i.ethe exact no of bytes ) required for coding,
> >> >> > I am calling mpeg2_getpos() in STATE_PICTURE. of
> >> >> decode_mpeg2
> >> >> > function .I am getting an integer number in return.Can u please
> >> explain
> >> >> > further to get the exact frame sizes . do we need to take the
> >> >> > diference(i.ethe difference of the return value pf
> mpeg2_getpos()when
> >> >> > 1st picture header
> >> >> > was hit and the second return value from mpeg2_getpos() when the
> next
> >> >> > picture header is hit.... OR
> >> >> >
> >> >> > will the reurn value of mpeg2_getpos() directly gives the frame
> >> size...?
> >> >>
> >>
> > looking
> >> >> > for ur reply and thanks in advance
> >> >> >
> >> >> > regards
> >> >> >
> >> >> > anand.
> >> >> >
> >> >> >
> >> >> >
> >> >> > i hope i am making sense..please correct me if i am wrong ) .
> >> >> >
> >> >> >
> >> >> > On 4/4/07, anand meher < [EMAIL PROTECTED]> wrote:
> >> >> >>
> >> >> >> Hi keith,
> >> >> >> i am glad to recieve a mail from you.I am working
> on a
> >> >> >> project which requires the exact frame sizes(i.e the no of
> bytes)
> >> >> >> required to code. I am using mpeg2dec.c program in libmpeg2 .
> There
> >> is
> >> >> a
> >> >> >> function called as decode_mpeg2 which is a kind of event
> handler.
> >> >> >>
> >> >> >> The point 1 in ur reply is the exact one i was asking
> about.
> >> I
> >> >> >> think in the decode_mpeg2
> >> >> >> function and in the case STATE_PICTURE ,we need to call
> >> >> mpeg2_getpos().I
> >> >> >> will try for that.
> >> >> >> anyways i am really glad for ur quick reply.
> >> >> >> If i get any more doubts..i
> will
> >> try
> >> >> to
> >> >> >> mail you.
> >> >> >>
> >> >> >> Thanks & regards
> >> >> >>
> >> >> >> Anand.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On 4/4/07, Keith Winstein < [EMAIL PROTECTED]> wrote:
> >> >> >> >
> >> >> >> > Hi Anand,
> >> >> >> >
> >> >> >> > Not sure exactly what you mean. Are you asking about:
> >> >> >> >
> >> >> >> > (1) The number of bits required to code each picture ( e.g.,
> >> "911376
> >> >> bits
> >> >> >> > for the I frame, 115936 for the B frame after it, etc.")? For
> >> this,
> >> >> >> > you'll
> >> >> >> > have to call mpeg2_getpos() to get the position in the stream
> as
> >> you
> >> >> hit
> >> >> >> > PICTURE headers.
> >> >> >> >
> >> >> >> > (2) The horizontal and vertical sizes of the luma and chroma
> >> >> matrices.
> >> >> >> > These are in the sequence header -- see the code to
> dump_state.c
> >> for
> >> >> an
> >> >> >> > example. E.g., "1920x1088 for luma, 960x544 for chroma".
> >> >> >> >
> >> >> >> > (3) The intended displayed area of the frame ( e.g.,
> "1920x1080").
> >> >> This
> >> >> >> > is
> >> >> >> > in the sequence display extension header, also printed out by
> >> >> >> > dump_state.c
> >> >> >> > ("seq->display_width", etc.).
> >> >> >> >
> >> >> >> > Sizes #2 and #3 are not allowed to vary on a
> picture-by-picture
> >> >> basis.
> >> >> >> > Only by ending the sequence and then starting a new sequence
> can
> >> you
> >> >> >> > change the size of the image. (A picture display extension
> header
> >> can
> >> >> >> > vary
> >> >> >> > the location of the "display rectangle" within the full luma
> and
> >> >> chroma
> >> >> >> > matrices, but it can't change the dimensions of the "display
> >> >> >> > rectangle.")
> >> >> >> >
> >> >> >> > Hope that helps. If you can be more specific I'd be happy to
> help
> >> >> >> > further.
> >> >> >> >
> >> >> >> > Best,
> >> >> >> > Keith
> >> >> >> >
> >> >> >> > On Wed, 4 Apr 2007, anand meher wrote:
> >> >> >> >
> >> >> >> > > Hi,
> >> >> >> > > i am trying to find the frame sizes of the individual
> i,b,p
> >> >> frame
> >> >> >> > > sizes using libmpeg2.the current picture data structure
> does not
> >> >> >> > provide
> >> >> >> > > with the frame size.so is there any other way to find the
> frame
> >> >> sizes
> >> >> >> > > usiiiing libmpeg2. i am using the decode function in
> >> >> mpeg2dec.cprogram
> >> >> >> of
> >> >> >> > > libmpeg2.
> >> >> >> > >
> >> >> >> > > thanks in advance
> >> >> >> > >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libmpeg2-devel mailing list
Libmpeg2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
