[Live-devel] Re: sample data

Tue May 25 14:08:45 PDT 2004

Hi Ross,
Few days back I told you about a problem that I am having while using camera as a source of video data and you asked me to send the data sample . Here is the URL for the data.

http://www-scf.usc.edu/~murugan/sample.mpg

when I try to stream this file using live.com code...then I get some error about incorrect PES paccket size.

Can you please tell me what is wrong with the data that it fails to pass through MPEG over RTP code in live.com source code.

Thanks a lot 
Moses.

www.mosespawar.com

----- Original Message -----
From: live-devel-request at ns.live.com
Date: Tuesday, May 25, 2004 12:00 pm
Subject: live-devel Digest, Vol 7, Issue 20

> Send live-devel mailing list submissions to
> 	live-devel at lists.live.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.live.com/mailman/listinfo/live-devel
> or, via email, send a message with subject or body 'help' to
> 	live-devel-request at lists.live.com
> 
> You can reach the person managing the list at
> 	live-devel-owner at lists.live.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of live-devel digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: DeviceSource "not so clean" fix (Ross Finlayson)
>   2. RE: DeviceSource "not so clean" fix (Dixon Siu)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 24 May 2004 12:25:30 -0700
> From: Ross Finlayson <finlayson at live.com>
> Subject: Re: [Live-devel] DeviceSource "not so clean" fix
> To: "LIVE.COM Streaming Media - development & use"
> 	<live-devel at ns.live.com>
> Message-ID: <6.0.1.1.1.20040524113605.023ee150 at localhost>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> 
> >Wouldn't there be much less confusion, if these input and output 
> >parameters were just arguments to
> >getNextFrame?
> 
> The 'in' parameters - "to" and "maxSize" - *are* parameters to 
> "FramedSource::getNextFrame()".  The other parameters (the 'out' 
> parameters) are passed to the 'after getting' function (which itself is a 
> parameter to "FramedSource::getNextFrame()").  Note that due to the 
> event-driven nature of the code, it's not possible to do everything with 
> just a single function (with both in and out parameters).  With any 
> event-driven code, you need one function to register interest in an event, 
> and another function to actually handle the event, when it occurs.
> 
> >besides I am not so fond of this strategy of passing buffers from one 
> >Medium to another, especially because
> >it is a "pull", not a "push" strategy. typically the source should know 
> >better when data is available for processing
> 
> It depends.  For some applications - e.g., streaming data that's being 
> read 
> from a file - the 'pull' approach - as used by the "liveMedia" library - 
> seems most appropriate (to ensure that you end up reading from the input 
> file at the correct rate).  It's not clear to me that one approach ('push' 
> or 'pull') is inherently better than the other.
> 
> >I also realized, from reading the source, that most Media classes in 
> >libLive do a lot of fiddling with buffer pointers.
> >one of the worst of all is the MPEG1or2VideoStreamFramer. about 75% of 
> the 
> >code is only about buffer management.
> 
> No, that's not correct.  Most of that code does parsing of the various 
> MPEG 
> video headers - stuff that needs to be done for any implementation.
> 
> It's possible that in the future I'll also support an (optional) 
> alternative memory management scheme, in which the data source can return -
> 
> in the 'after getting' function - a *pointer* to a data buffer, rather 
> than 
> (as in the current scheme) requiring the data source to copy data into a 
> buffer that was supplied by the sink.  That approach would - in some cases 
> - be more efficient for things like raw UDP streaming, because it would 
> eliminate some data copying.  (Note, though, that it wouldn't help for 
> *RTP* streaming (because of the 12-byte RTP header), unless you also had a 
> scatter-gather network interface.)
> 
> In most cases, though, the current memory management approach (where sinks 
> pass a memory buffer to the source) actually seems cleaner and more 
> efficient than the alternative, because it allows the final data sink to 
> have complete control over the memory buffer.  For example, for RTP 
> streaming the "RTPSink" does just one dynamic memory allocation - when 
> it's 
> created - and then uses this same memory buffer throughout its lifetime 
> (with no more allocations or deallocations).
> 
> 
> 	Ross Finlayson
> 	LIVE.COM
> 	<http://www.live.com/>
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 25 May 2004 13:24:12 +0900
> From: "Dixon Siu" <dixonsiu at mediaglue.co.jp>
> Subject: RE: [Live-devel] DeviceSource "not so clean" fix
> To: "LIVE.COM Streaming Media - development & use"
> 	<live-devel at ns.live.com>
> Message-ID: <DFEILNMJCAFGAPLNLEJBCEIOCAAA.dixonsiu at mediaglue.co.jp>
> Content-Type: text/plain;	charset="Windows-1252"
> 
> Hi Ross,
> 
> Thanks for the clarification. From the template of DeviceSource, I
> miss-undetstood the meaning of "In" and thought that I have to initialize it
> and keep it up-to-date. That is why, in my DeviceSource constructor, I also
> assigned a pointer address to fTo. I will review the classes.
> 
> Only one question: how come the following code exists in
> ByteStreamFileSource::doGetNextFrame()
> 	if (fPreferredFrameSize > 0) && fPreferredFrameSize < fMaxSize){
>        	fMaxSize = fPreferredFrameSize;
> 	}
> 
> The above code sets the value of fMaxSize.
> 
> Regards,
> Dixon
> 
> > -----Original Message-----
> > From: live-devel-bounces at ns.live.com
> > [live-devel-bounces at ns.live.com]On Behalf Of Ross Finlayson
> > Sent: Monday, May 24, 2004 11:38 PM
> > To: LIVE.COM Streaming Media - development & use
> > Subject: Re: [Live-devel] DeviceSource "not so clean" fix
> >
> >
> >
> > >         fMaxSize = fPreferredFrameSize;
> >
> > Once again, this is wrong.  "fMaxSize" (just like "fTo") is an input
> > parameter (which was set in the original call to "getNextFrame()").  It's
> > not something that you set yourself (in "doGetNextFrame()").
> >
> > Once again, to summarize: In your "doGetNextFrame()" member function
> > implementation, you
> > - *read* (but don't set) "fTo" and "fMaxSize"
> > - *set* "fFrameSize" and "fPresentationTime"
> > - *optionally set* (if you know the values) "fNumTruncatedBytes" and
> > "fDurationInMicroseconds".
> >
> > >         // Strange! I cannot use the pointer method.
> >
> > There's nothing 'strange' here.  Remember, You Have Complete Source
> > Code.  If you read it (in particular, "FramedSource::getNextFrame()"),
> > you'll see what's going on.
> >
> >
> > 	Ross Finlayson
> > 	LIVE.COM
> > 	<http://www.live.com/>
> >
> > _______________________________________________
> > live-devel mailing list
> > live-devel at lists.live.com
> > http://lists.live.com/mailman/listinfo/live-devel
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.688 / Virus Database: 449 - Release Date: 2004/05/18
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.688 / Virus Database: 449 - Release Date: 2004/05/18
> 
> 
> ------------------------------
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live.com
> http://lists.live.com/mailman/listinfo/live-devel
> 
> 
> End of live-devel Digest, Vol 7, Issue 20
> *****************************************
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpawar.vcf
Type: text/x-vcard
Size: 290 bytes
Desc: Card for moses pawar <mpawar at usc.edu>
Url : http://lists.live.com/pipermail/live-devel/attachments/20040525/007092db/mpawar.vcf