Hi Ross and other active friends, This is second time I am writing this email but I got no answer in my first attempt. Thought every body is busy. The trouble I have is with Trick Play using Amino 110 and Live555. I am using ts / tsx but I can see a 10-15 second stuttering and soft of delay while I am doing FF and then Play. does anybody faced with this problem before or something is wrong with my configuration??? Also there is 3 second static delay when I am playing a movie on the Amino with this configuration. Please advise. Cheers, Yousef. Opensoft Australia.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 05, 2007 7:37 AM To: [EMAIL PROTECTED] Subject: live-devel Digest, Vol 48, Issue 5 Send live-devel mailing list submissions to live-devel@lists.live555.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.live555.com/mailman/listinfo/live-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..." Today's Topics: 1. Re: Streaming a H.264 file (Raymond Tam) 2. Re: Socket handling problem with live555 (M-A Loyer) 3. audio stream problems (Cristaldi Ambra) 4. Re: Streaming a H.264 file (Ross Finlayson) 5. Re: audio stream problems (Ross Finlayson) 6. Re: Streaming a H.264 file (Raymond Tam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 4 Oct 2007 18:46:39 -0700 From: "Raymond Tam" <[EMAIL PROTECTED]> Subject: Re: [Live-devel] Streaming a H.264 file To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi, I've implemented my own H.264 framer and testH264AudioVideoStreamer, and the test program is now streaming RTP/H.264 packets to a VLC client and I can see the video playing on the VLC client. But after running for a while, I get this error: About to throw NO_MORE_BUFFERED_INPUT! twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) *** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid next size (normal): 0x086923a8 *** ======= Backtrace: ========= /lib/libc.so.6[0x9b9efd] /lib/libc.so.6(cfree+0x90)[0x9bd550] /usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] My test program runs on Linux. I've tried to increase "BANK_SIZE" in StreamParser.cpp from 150,000 to 1,5000,000 but no difference. It always happens when "throw" happens in StreamParser::ensureValidBytes1(). Any idea ? Thank you in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071004/f5f4e999/ attachment-0001.html ------------------------------ Message: 2 Date: Thu, 04 Oct 2007 23:50:58 -0400 From: M-A Loyer <[EMAIL PROTECTED]> Subject: Re: [Live-devel] Socket handling problem with live555 To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=iso-8859-1 We're currently using quicktime for java, but we're in the process to switch to another RTSP client as the free java class set of QuickTime is not well maintained and not working on all our target platforms. Thanks for the pointer, we'll give VLC a try ! Marc-Andre Le October 4, 2007, Ross Finlayson a ?crit?: > I suspect (although am not 100% sure) that this is the same RTSP > server issue that Peter Leese identified last month. > > I'm hoping to include a fix in the next release of the software > (probably sometime later this month). > > In the meantime, you may be able to overcome the problem by using a > different RTSP client. What RTSP client do you use now? (I don't > think the VLC client will trigger this problem.) ------------------------------ Message: 3 Date: Fri, 5 Oct 2007 10:16:21 +0200 From: "Cristaldi Ambra" <[EMAIL PROTECTED]> Subject: [Live-devel] audio stream problems To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi Ross, I have a problem streaming files recorded by an Ateme Camera. I record a complete (audio + video) flow coming from this camera: I store it in two separated files, that will be named "video-MP4V-ES-1" and "audio-MPEG4-GENERIC-2", as I found in documentation. The video one is in MPEG4 format, and I can stream it using "testOndemandRTSP" and VLC player, after renaming itself "test.m4e". The problem is with the audio one. The Ateme- producers ensure me that the file format is ADTS, so I try to rename it "test.aac" and stream it using "testOndemandRTSP" and VLC player, but nothing seems to work. Where is the problem? May it be possible that the file is not an ADTS one? I try to analyze it with some Stream-analyzer program, but I didn't get any information, so I thought the problem could be in the packets of the audio signal. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071005/135d3c27/ attachment-0001.html ------------------------------ Message: 4 Date: Fri, 5 Oct 2007 01:20:12 -0700 From: Ross Finlayson <[EMAIL PROTECTED]> Subject: Re: [Live-devel] Streaming a H.264 file To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" >I've implemented my own H.264 framer and testH264AudioVideoStreamer, >and the test program is now streaming RTP/H.264 packets to a VLC >client and I can see the video playing on the VLC client. >But after running for a while, I get this error: > >About to throw NO_MORE_BUFFERED_INPUT! >twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior >- *not* an error) Why do you think that's an error, when the comment in the code explicitly says that it's not? There's nothing wrong here. This is just a C++ language exception (*not* an error) that is raised whenever the StreamParser's buffer runs out. (It tells the code that more data needs to be read from the upstream source.) The *real* error is this: >*** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid >next size (normal): 0x086923a8 *** >======= Backtrace: ========= >/lib/libc.so.6[0x9b9efd] >/lib/libc.so.6(cfree+0x90)[0x9bd550] >/usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] I have no idea where this error is occurring, but I see no evidence that it's occurring in the "LIVE555 Streaming Media" code. Perhaps it's occurring in your new code - e.g., when it's handling a read from the downstream object? > >My test program runs on Linux. I've tried to increase "BANK_SIZE" in >StreamParser.cpp from 150,000 to 1,5000,000 but no difference. This is a 'red herring'. As I've noted, this C++ language exception is *not* an error; it's the code working normally. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071005/7eb643d1/ attachment-0001.html ------------------------------ Message: 5 Date: Fri, 5 Oct 2007 01:33:34 -0700 From: Ross Finlayson <[EMAIL PROTECTED]> Subject: Re: [Live-devel] audio stream problems To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" >I record a complete (audio + video) flow coming from this camera: I >store it in two separated files, that will be named >"video-MP4V-ES-1" and "audio-MPEG4-GENERIC-2", as I found in >documentation. >The video one is in MPEG4 format, and I can stream it using >"testOndemandRTSP" and VLC player, after renaming itself "test.m4e". >The problem is with the audio one. The Ateme- producers ensure me >that the file format is ADTS No it's not. The file contains raw AAC audio data. An ADTS-format file, however, is different: it contains a short header in front of each audio frame. (To help understand this, see the code for "ADTSAudioFileSource".) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071005/4fdc36b4/ attachment-0001.html ------------------------------ Message: 6 Date: Fri, 5 Oct 2007 07:34:08 -0700 From: "Raymond Tam" <[EMAIL PROTECTED]> Subject: Re: [Live-devel] Streaming a H.264 file To: "LIVE555 Streaming Media - development & use" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" Thanks Ross. Yes I know the exception is not an error, in fact I've been getting it all along while parsing the stream normally. ________________________________ From: [EMAIL PROTECTED] on behalf of Ross Finlayson Sent: Fri 10/5/2007 1:20 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Streaming a H.264 file I've implemented my own H.264 framer and testH264AudioVideoStreamer, and the test program is now streaming RTP/H.264 packets to a VLC client and I can see the video playing on the VLC client. But after running for a while, I get this error: About to throw NO_MORE_BUFFERED_INPUT! twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) Why do you think that's an error, when the comment in the code explicitly says that it's not? There's nothing wrong here. This is just a C++ language exception (*not* an error) that is raised whenever the StreamParser's buffer runs out. (It tells the code that more data needs to be read from the upstream source.) The *real* error is this: *** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid next size (normal): 0x086923a8 *** ======= Backtrace: ========= /lib/libc.so.6[0x9b9efd] /lib/libc.so.6(cfree+0x90)[0x9bd550] /usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] I have no idea where this error is occurring, but I see no evidence that it's occurring in the "LIVE555 Streaming Media" code. Perhaps it's occurring in your new code - e.g., when it's handling a read from the downstream object? My test program runs on Linux. I've tried to increase "BANK_SIZE" in StreamParser.cpp from 150,000 to 1,5000,000 but no difference. This is a 'red herring'. As I've noted, this C++ language exception is *not* an error; it's the code working normally. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ ------------------------------ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 48, Issue 5 ***************************************** _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
