Re: [patch] minor ctor/dtor leak in liveMedia/MP3ADUinterleaving.cpp
Thanks for the report. This bug will be fixed in the next release of the software. -- -- Ross Finlayson Live Networks, Inc. http://www.live555.com/
Thanks for the report. This bug will be fixed in the next release of the software. -- -- Ross Finlayson Live Networks, Inc. http://www.live555.com/
Hi
I'm trying to compile the live555 Streaming Media packet on Linux. I have 2 problems and can't find the solution in the FAQ. So I wrote to ask. Hope you will reply to me :)
1. When I compile the source code package, I follow the instructions that :
- extract the package to a folder, then type the command : cd home/hannah/Documents . This is the folder contains the "live".
- After that I create the makefile by the command : ./genMakefiles linux. But I got the error "new line". So I can't proceed further. (can't "make" )
What's the problem when I create Makefile? I search google to find answer, but can't find it. Any modifications I should make before compiling the package? (I have the gcc compiler already).
2. I have one idea that, like the Bittorrent, I will have a server (tracker) and clients connect together, but I will not need to wait for it to finish downloading, but I just wait for it to buffer, then play.
- Can I use live555 Streaming Media package to do that?
- If yes, it means I will need to create a database for server, to track down which client got which file and need which file? How can I create database?
- Can I let 2 clients connect together? Like client 1 got file A, client 2 need that file, can I let the 2 clients connect and take the file it need? (for example use openRSTP client). If yes, how can I connect them?
This is just the idea. But I don't know how to implement.
Hope you will reply to me.
Thank you very much
Have a nice day.
_______________________________________________ live-devel mailing list live-devel@... http://lists.live555.com/mailman/listinfo/live-devel
1. When I compile the source code package, I follow the instructions that :
- extract the package to a folder, then type the command : cd home/hannah/Documents . This is the folder contains the "live".
2. I have one idea that, like the Bittorrent, I will have a server (tracker) and clients connect together, but I will not need to wait for it to finish downloading, but I just wait for it to buffer, then play.
- Can I use live555 Streaming Media package to do that?
_______________________________________________ live-devel mailing list live-devel@... http://lists.live555.com/mailman/listinfo/live-devel
Hello, I use the testOnDemandRTSPServer to stream live video (captured using an analog camera and encoded to MPEG 4 ES using a co-processor). I use ByteFileStreamSource.cpp in (ASYNCHRONOUS mode) as a base model for my device. I have modified doReadFromFile in such a way that it reurns an MPEG 4 frame from the "codec engine"(capture device + mpeg 4 encoder). I am having problems with the BANK_SIZE defined in StreamParser.cpp. Since I keep on reading from the codec engine and filling data untill BANK_SIZE (am I right ???) . When I reach the boundary (around BANK_SIZE) and I read X bytes and if adding X bytes would exceeed BANK_SIZE I end up with an error (and a visible glitch) at the decoder (mplayer compiled with LIVE555 support and MAX_RTP_FRAME_SIZE increased to 100000). Here is the output at the mplayer end: [mpeg4 <at> 0x889a290]Error at MB: 89 [mpeg4 <at> 0x889a290]concealing 1584 DC, 1584 AC, 1584 MV errors [mpeg4 <at> 0x889a290]ac-tex damaged at 20 17 [mpeg4 <at> 0x889a290]Error at MB: 802 [mpeg4 <at> 0x889a290]concealing 884 DC, 884 AC, 884 MV errors [mpeg4 <at> 0x889a290]ac-tex damaged at 12 22 Here is the debug output(newly added) at the Server end, ---------------------- ByteCount exceeded ---------------------- bufferSize = 79020 byteCount = 9954316 ---------------------- ByteCount exceeded ---------------------- bufferSize = 13086 byteCount = 999549 and the explanation: bufferSize - size of frame returned by the codec engine. byteCount - current amount of bytes I have filled into "fTo" buffer What should I do to ignore the last frames since they exceed BANK_SIZE ? or my understanding of the problem is flawed ?. I can stream videos with really low latency using live555 server. The only glitch I have now is there error happening once in 30 sec or so. Any suggestion on how to fix this would be of great help. Mit freundlichen Grüßen / Best regards Kumar Bala
Hello,
I wanted to ask if there is anyone who have managed to write some code for streamming (like the example testMPEG4Streammer) MPEG4 files (not the elementary) and wouldn't mind to share. I have tried the example with the elementary files and it works fine, but I would like to stream normal mp4 files.
Thanks.
_______________________________________________ live-devel mailing list live-devel@... http://lists.live555.com/mailman/listinfo/live-devel
>I use the testOnDemandRTSPServer to stream live video (captured using >an analog camera and encoded to MPEG 4 ES using a co-processor). I use >ByteFileStreamSource.cpp in (ASYNCHRONOUS mode) as a base model for my >device. I have modified doReadFromFile in such a way that it reurns an >MPEG 4 frame from the "codec engine"(capture device + mpeg 4 encoder). Because your input device returns discrete MPEG-4 video frames, rather than a byte stream, it'd be better if you used "MPEG4VideoStreamDiscreteFramer", rather than "MPEG4VideoStreamFramer". However, your first test should have been using the *unmodified* source code - to stream from a MPEG-4 Video Elementary Stream *file*. I.e., you should have first created a file "test.m4e" - from the output of your encoder - and then tried streaming this, using the *unmodified* "testOnDemandRTSPServer" (or "testMPEG4VideoStreamer") application. (In general, once you've modified the supplied code, you can't expect to get much support on this mailing list.) I suspect that perhaps the output from your encoder is not in the proper form - i.e., not a true MPEG-4 Video Elementary Stream. If you this may be true, then please put your "test.m4e" file on a web server, and send us the URL, so we can download and test this for ourselves. -- -- Ross Finlayson Live Networks, Inc. http://www.live555.com/
Oops, I omitted a word from my previous answer: >I suspect that perhaps the output from your encoder is not in the >proper form - i.e., not a true MPEG-4 Video Elementary Stream. If >you think >this may be true, then please put your "test.m4e" file on a web >server, and send us the URL, so we can download and test this for >ourselves. -- -- Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@... http://lists.live555.com/mailman/listinfo/live-devel
>Hi, > >I would like to be able to let the client survive a 15 second >ethernet cable disconnect when streaming over TCP! Where exactly in >the code would I have to make modifications to make this happen? I >suspect the problem lies with trying to send RTCP packets? No, I suspect the problem lies with your operating system - it's probably responsible for closing the TCP connection in this case. -- -- Ross Finlayson Live Networks, Inc. http://www.live555.com/
>> Because your input device returns discrete MPEG-4 video frames, rather than a byte stream, it'd be better if you used "MPEG4VideoStreamDiscreteFramer", rather than "MPEG4VideoStreamFramer". That did the trick, I streamed for 30 min without one single error !!! Thanks a ton. Mit freundlichen Grüßen / Best regards Kumar Bala (Software Developer and System Designer) DSP-Weuffen Software/Hardware für DSP- und MCP-Konzeption und Optimierung ihres Systems DSP-Weuffen GmbH Schomburger Strasse 11 88279 Amtzell Tel: +49 7520 / 96673 - 146 Fax: +49 7520 / 96673 - 124 Mail: kumar.bala@... <mailto:kumar.bala@...> Web: http://www.dsp-weuffen.de <http://www.dsp-weuffen.de/> Geschäftsführer: Dieter Weuffen | Amtsgericht 89014 ULM | HR-NR: HRB621135 Bitte beachten Sie, dass diese E-Mail einschließlich aller eventuell angehängten Dokumente vertrauliche und/oder rechtlich geschützte Informationen enthalten kann. Der Inhalt ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der richtige Adressat oder dessen Vertreter sind, setzen Sie sich bitte mit dem Absender der E-Mail in Verbindung und löschen Sie die E-Mail sofort. Jede Form der Verwendung, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts fehlgeleiteter E-Mails ist unzulässig. Ross Finlayson wrote: >> I use the testOnDemandRTSPServer to stream live video (captured using >> an analog camera and encoded to MPEG 4 ES using a co-processor). I use >> ByteFileStreamSource.cpp in (ASYNCHRONOUS mode) as a base model for my >> device. I have modified doReadFromFile in such a way that it reurns an >> MPEG 4 frame from the "codec engine"(capture device + mpeg 4 encoder). > > Because your input device returns discrete MPEG-4 video frames, rather > than a byte stream, it'd be better if you used > "MPEG4VideoStreamDiscreteFramer", rather than "MPEG4VideoStreamFramer". > > However, your first test should have been using the *unmodified* > source code - to stream from a MPEG-4 Video Elementary Stream *file*. > I.e., you should have first created a file "test.m4e" - from the > output of your encoder - and then tried streaming this, using the > *unmodified* "testOnDemandRTSPServer" (or "testMPEG4VideoStreamer") > application. (In general, once you've modified the supplied code, you > can't expect to get much support on this mailing list.) > > I suspect that perhaps the output from your encoder is not in the > proper form - i.e., not a true MPEG-4 Video Elementary Stream. If you > this may be true, then please put your "test.m4e" file on a web > server, and send us the URL, so we can download and test this for > ourselves.
RSS Feed56 | |
|---|---|
177 | |
118 | |
167 | |
215 | |
115 | |
92 | |
100 | |
219 | |
155 | |
193 | |
176 | |
172 | |
182 | |
176 | |
128 | |
183 | |
204 | |
199 | |
126 | |
45 | |
113 | |
163 | |
147 | |
66 | |
28 | |
133 | |
57 | |
126 | |
138 | |
148 | |
115 | |
119 | |
62 | |
131 | |
125 | |
60 | |
84 | |
197 | |
99 | |
140 | |
106 | |
106 | |
135 | |
117 | |
117 | |
147 | |
154 | |
130 | |
157 | |
189 | |
119 | |
98 | |
133 | |
176 | |
174 | |
152 | |
130 | |
214 | |
315 | |
180 | |
192 | |
147 | |
134 | |
160 | |
120 | |
122 | |
139 | |
127 | |
117 | |
196 | |
202 | |
88 |