[Live-devel] live-devel Digest, Vol 34, Issue 6

David Arnold darnold at futurec.net
Mon Aug 14 16:50:37 PDT 2006


Ross, could you give us sample psuedo-code that demonstrates the event
method you describe?  How would this new EventLoop interact with
FramedSource derived classes and MultiFramedRTPSink derived classes?

The interface to the H.264 encoder I am using requires that I call
DSP_GetFrame() at correct intervals or else it will always return frames at
30 fps.

Thank you,

Dave Arnold
Future Concepts, La Verne

From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] Behavior of DeviceSource::doGetNextFrame()
	when no data available
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <f06230900c10120c29cad@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>On 8/10/06, David Arnold <darnold at futurec.net> wrote:
>>  What should a DeviceSource, such as a frame grabber, do in
doGetNextFrame()
>>  when it determines there is no frame available?  I find no answer in the
>>  FAQ.  The comment in DeviceSource.cpp reads:
>
>You need to reschedule a retry.
>
>In my device source (which I copied from one of the examples), after
>reading and validating the frame from the device it uses
>scheduleDelayedTask with a 0 delay to schedule a call to
>'afterGetting'. If a frame is not available it uses
>scheduleDelayedTask to retry reading a frame from the device at some
>point in the future. If you have a read selectable file descriptor for
>your device then there is a more efficient method to do this.
>
>For example:
>         /* poll again in 5ms */
>         nextTask() = envir().taskScheduler().scheduleDelayedTask (
>             5 * 1000, (TaskFunc*) dspRetryGet, this );

This works, but can be inefficient - because it polls frequently, and
because it incurs a delay of at least 5 ms (in your example), even if
new frame data becomes available almost immediately.

A better way is to make the availability of new frame data an
'event', and just handle this in the event loop.

If your frame grabber is implemented as a readable open file (i.e.,
socket), then you can just call
"envir().taskScheduler().turnOnBackgroundReadHandling( ...)" on it.
This will schedule a handler function that gets called (via
"select()") within the event loop.

If your frame grabber is *not* a readable socket, then you need to do
something else to trigger the arrival of new frame data as being an
'event'.  One simple way to do this is to use the "watchVariable"
parameter to "doEventLoop()".  (Look at the code, and the FAQ.)  If
your custom events are more complicated than can be handled using the
"watchVariable", then you would need to write your own event loop -
i.e., your own subclass of "TaskScheduler" - that handles them.

>The problem is if I just return, as in:
>
>doGetNextFrame()
>{
>	if (grabNextFrame() == NO_FRAME_AVAILABLE)
>		return;
>}
>
>The task scheduler seems to stop.

The task scheduler doesn't 'stop', it is just waiting until events
happen.  That's why you need to make the availability of new frame
data an 'event'.  Apart from that, your code above is correct.

>   It appears as though I must invoke
>afterGetting(this).  If I must invoke afterGetting() what to I set all the
>expected output parameters to (such as fFrameSize, etc) to.

You must invoke "afterGetting()" *only* after you have new data that
you have just delivered to the downstream reader - i.e., only after
you have copied new data to "fTo", and set "fFrameSize", etc.

--

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


------------------------------

Message: 3
Date: Fri, 11 Aug 2006 02:04:17 +0200
From: Derk-Jan Hartman <hartman at videolan.org>
Subject: Re: [Live-devel] [vlc-devel] Re: [vlc] Illegal characters in
	RTSP	stream user/password mechanism
To: vlc-devel at videolan.org
Cc: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <6ABAC197-FE96-4976-A1A9-C5697A340523 at videolan.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On 6-aug-2005, at 8:09, Ross Finlayson wrote:
>> It seems that when there is an illegal character in the user/password
>> authentication mechanism of an RTSP URL, then VLC fails to deliver
>> the content.
>>
>> For example, for user "user" and password "passw at rd" the RTSP URL
>> is: rtsp://user:passw@rd@somesite/somecatalog/file.rm and that's
>> something that causes VideoLAN not to show the stream.
>
> The problem here is caused by the RTSP client code's parsing of
> optional "<user>:<password>@" fields in "rtsp://" URLs (in the
> LIVE.COM libraries).  It stops at the first '@' (or '/').
>
> Unfortunately, there doesn't seem to be any good way to fix this,
> because of the fact that the '@', '/' and '.' characters can also
> appear in the stream name portion of the URL (i.e., after the host
> name or address).  I don't believe that this can be parsed
> unambiguously.  Basically, "<username>:password@" is a non-standard
> hack, and one that we shouldn't really be using in any case.
>
> The real solution to this problem is to fix VLC so that - if a RTSP
> (or HTTP!) authentication failure occurs - it will then pop up a
> dialog box in wihch users can enter a <username>,<password> pair.
> Then, retry using that <username> and <password>.
>
> This is what QuickTime Player and other media players do; VLC
> should be doing it as well.
>
> If the VLC developers would implement such a dialog box, and use it
> for HTTP authentication, then I'll add the appropriate code to the
> LIVE.COM libraries and "modules/demux/livedotcom.cpp" to also use
> it for RTSP authentication.  Just let me know...

Since we now have the interaction framework this could be possible.
https://trac.videolan.org/vlc/browser/trunk/modules/access/http.c#L279

So Ross :D how are we gonna do this :D

DJ

BTW I'm rewriting some parts of our live555 module to be a bit more
readable atm. that made me remember this issue.


------------------------------

Message: 4
Date: Fri, 11 Aug 2006 10:23:57 +0800
From: <TonyBai at viatech.com.cn>
Subject: [Live-devel] question about buffer
To: <live-devel at ns.live555.com>
Message-ID:
	<00DA072AF14656448C31F5C0182E7D0A72D9C1 at exchsh01.viatech.com.sh>
Content-Type: text/plain; charset="us-ascii"

Hi, all

Can I control the buffer of RTP data and how?

Thank you,



Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20060810/c5ac9987/
attachment-0001.html

------------------------------

Message: 5
Date: Fri, 11 Aug 2006 12:54:43 +0800
From: SpaceLi <spacelis at gmail.com>
Subject: Re: [Live-devel] Why the testOnDemandRTSPServer show
	0.0.0.0:8554
To: "LIVE555 Streaming Media - development & use"
	<live-devel at ns.live555.com>
Message-ID:
	<4f8ff5c10608102154r7bbb5330g2597f9a9a4153437 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Thank you for your advice, I have secessfully setup ip multicast on
uclinux, the address is now right.
     But I still couldn't link to server, is there any simple way to
check whether the server setup correctly.
     When I tried to capture the packets between server and client, I
found realplayer always send "OPTION" packets with incorrect checksum.
So I don't know who is wrong, server or client.
thx

On 8/10/06, Ross Finlayson <finlayson at live555.com> wrote:
> >I have read that part of code, it seems to use multicast ip to figure
> >out ourSourceAddress. But the os does not support multicast on my
> >board or I am not sure if multicast could work properly on the system.
>
> For many systems, getting multicast to work requires only that you
> add a route for 224.0.0/4 (for your local network interface).
>
> >And I am not very interest in multicast. Is there any way to make it
> >without multicast.
>
> If multicast doesn't work, then the code uses "gethostname()"
> followed by "gethostbyname()" to try to figure out your IP address.
> If neither method works, then I suppose you could hard-wire your
> address into the implementation of "ourSourceAddressForMulticast()".
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>


------------------------------

Message: 6
Date: Thu, 10 Aug 2006 22:33:22 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] Why the testOnDemandRTSPServer show
	0.0.0.0:8554
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <f06230908c101c56e2509@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>Thank you for your advice, I have secessfully setup ip multicast on
>uclinux, the address is now right.
>      But I still couldn't link to server, is there any simple way to
>check whether the server setup correctly.
>      When I tried to capture the packets between server and client, I
>found realplayer always send "OPTION" packets with incorrect checksum.
>So I don't know who is wrong, server or client.

Your client - realplayer - is wrong: It is badly non-standards
compliant.  Don't bother using it - instead, use VLC
<http://www.videolan.org/vlc/>, or QuickTime Player.

You can also use the "openRTSP" client
<http://www.live555.com/openRTSP/> - especially with the "-V"
(verbose output) option.
--

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


------------------------------

Message: 7
Date: Fri, 11 Aug 2006 03:25:17 -0700 (PDT)
From: Tran Huu Tri <huutribk2001 at yahoo.com>
Subject: [Live-devel]  How to stream jpeg buffer?
To: live-devel at ns.live555.com
Message-ID: <20060811102517.99401.qmail at web52310.mail.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1

Hi,
I need to streaming jpeg buffer frames,
I implemented a frame source that drive JPEGVideoSource
as class MyJPEGFramedSource : public  JPEGVideoSource,

but in doGetNextFrame I don't know how to encode the buffer
wiht correct format to copy to fTo variable.

I have the jpeg image format already, what stept i need to
do next before call doGetNextFrame function to stream?

I try to follow the code in DeviceSource code to stream
jpeg image buffer(that i capture from webcam and to jpg
format), but i don't know what DeviceParameters type?

Please help me with streaming by using buffer frame input
instead of file input as example programs

Thank in advance!



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


------------------------------

Message: 8
Date: Sat, 12 Aug 2006 08:05:55 +0800
From: Tire <tire.tw at gmail.com>
Subject: [Live-devel] fixe the RTP port and the RTCP port
To: live-devel at ns.live555.com
Message-ID:
	<7992557a0608111705g75a34922v958c1db261001439 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

In live.2006.08.07 version, you can choose server port numbers starting with
a specific port number.

Whether we can through the fixed RTP port and the RTCP port to send package
and receive the package ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20060811/0b3ffa9a/
attachment-0001.html

------------------------------

Message: 9
Date: Sat, 12 Aug 2006 15:08:03 +0800 (CST)
From: "weiyutao36" <weiyutao36 at 163.com>
Subject: [Live-devel] About detection of network connection
To: "live?*7"U_SJ<~AP1m " <live-devel at ns.live555.com>
Message-ID: <44DD7E53.000078.21745 at bj163app20.163.com>
Content-Type: text/plain; charset="gb2312"

Hi everyone,
I am using live libray.
When the network connection is down,I want

to continuously send some command/request

to the RTSP server in order to know when the

network connection is OK and if it is OK,I

continue receiving data from the server.

Does anyone know which function can I use to

this?
Any advice will be appreciated.
==================
FilexBlue

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20060812/202ea14c/
attachment-0001.html

------------------------------

Message: 10
Date: Sun, 13 Aug 2006 17:01:07 +0200
From: Derk-Jan Hartman <hartman at videolan.org>
Subject: [Live-devel] H264 FU-A
To: LIVE555 Streaming Media - development & use
	<live-devel at ns.live555.com>
Message-ID: <2BD95C26-5839-4286-874D-ADF58FFA1116 at videolan.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

He Ross,

I'm looking into H264 a bit more.
I was wondering. I cannot find what liveMedia does with "incomplete"
FU-A or FU-B packets.

As far as I know, if an FU-A or FU-B packet becomes "broken", the
receiver should discard all data up to the next packet, and may pass
along what it has already received, as long as it marks the NALU as
invalid (or discard it completely of course).

Is this happening?
I'm wondering why I need to feed the liveMedia stream trough our
packetizer. Either ffmpeg is just very fault intolerant for H264, or
something is wrong with the data fed from RTSP.

DJ


------------------------------

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


End of live-devel Digest, Vol 34, Issue 6
*****************************************

The information contained in this electronic mail transmission is intended only for the use of the individual or entity named above and is privileged and confidential. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Any dissemination, distribution or copying of this communication other than to the person or entity named above is strictly prohibited. If you have received this communication in error, please immediately delete it from your system.




More information about the live-devel mailing list