<div dir="ltr">I decided to go with ffmpeg instead. So since I'm not using you guys and probably wouldn't be much help when it comes to helping other people solve their problems either, I'd like to unsubscribe.<div>
<br></div><div>Thank you!</div><div>Matt<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 7:16 PM, <span dir="ltr"><<a href="mailto:live-devel-request@ns.live555.com" target="_blank">live-devel-request@ns.live555.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send live-devel mailing list submissions to<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:live-devel-request@lists.live555.com">live-devel-request@lists.live555.com</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:live-devel-owner@lists.live555.com">live-devel-owner@lists.live555.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of live-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. OnDemandRTSPServer working with File as File source but not<br>
File as Pipe (<a href="mailto:temp2010@forren.org">temp2010@forren.org</a>)<br>
2. TS discontinuity when seeking (S?bastien Escudier)<br>
3. Re: getNormalPlayTime after a pause and play (S?bastien Escudier)<br>
4. Re: OnDemandRTSPServer working with File as File source but<br>
not File as Pipe (Ross Finlayson)<br>
5. testH264VideoStreamer multi client play stop (HOFFMANN Eric)<br>
6. Re: testH264VideoStreamer multi client play stop (Ross Finlayson)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 21 Feb 2013 18:40:09 -0500<br>
From: "<a href="mailto:temp2010@forren.org">temp2010@forren.org</a>" <<a href="mailto:temp2010@forren.org">temp2010@forren.org</a>><br>
To: <a href="mailto:live-devel@ns.live555.com">live-devel@ns.live555.com</a><br>
Subject: [Live-devel] OnDemandRTSPServer working with File as File<br>
source but not File as Pipe<br>
Message-ID:<br>
<<a href="mailto:CAK0dNZidNpdvxTqazWosKp3zADqiaq1sb3Vtozw_6ai4wz1UkA@mail.gmail.com">CAK0dNZidNpdvxTqazWosKp3zADqiaq1sb3Vtozw_6ai4wz1UkA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
We want our PC to send a video stream to an iPad, and we sometimes test by<br>
sending to VLC over the local network.<br>
<br>
The video stream gets into linked-in Live555 code via ByteStreamFileSource,<br>
but in two different ways. One way is from a file on disk (File as File).<br>
The other way is through a named pipe (File as Pipe).<br>
<br>
Both File as File and File as Pipe look great on VLC over the lan. But to<br>
the iPad, the File as File looks great but the File as Pipe is very blocky,<br>
as if compression info is missing or whatever.<br>
<br>
This tells me two things: (#1) it seems VLC may be more robust and<br>
forgiving than our iPad app, as expected; and (#2) there's some difference<br>
in what Live555 sends (perhaps presentation time?) depending on whether the<br>
stream came from File as File or File as Pipe.<br>
<br>
I'm writing you to ask about #2. If we can fix #2, then we don't have to<br>
fix #1.<br>
<br>
In detail (sorry, but there's no other way for the quick turn we need this<br>
week), Live555 InputFile.cpp already had a hood in it for filename "stdin".<br>
We tentatively added a hook for "pipe". Thus, we can easily switch<br>
between File as File (real filename) or File as Pipe (hooked "pipe"<br>
filename). This also means that the ONLY difference in the code base from<br>
this point all the way out to the iPad is this tiny difference. One would<br>
expect the output and iPad behavior to be the same... but it's not.<br>
<br>
Meanwhile, the actual stream being sent INTO the Pipe is simultaneously<br>
written to a raw h.264 file, and on later tests, it's that raw h.264 that's<br>
being read in the File as File case. Therefore, the content of the stream<br>
in both cases should be indistinguishable. We tried File as Pipe, and we<br>
got the blockiness. We then took that very raw h.264 file just written,<br>
and ran again with File as File, and we did NOT get the blockiness.<br>
<br>
So, back to #2, there simply must be some difference in what Live555 sends,<br>
between the two cases.<br>
<br>
Do you have any clue at all as to what this difference might be, and what<br>
we might do to get rid of it? My guess is something about presentation<br>
time, but I'm so ignorant on this stuff in general that I don't trust my<br>
own guess.<br>
<br>
(Once we figure it out, we can write alternate InputFile.cpp and<br>
ByteStreamFileSourcesource.cpp (and on up the rather long derivation chain)<br>
in order to return InputFile.cpp to it's pre-pipe-hook content. But it's<br>
too wasteful to do that first, in case this strategy fails to ever work at<br>
all...)<br>
<br>
Thanks very much for you help.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.live555.com/pipermail/live-devel/attachments/20130221/4df1802a/attachment-0001.html" target="_blank">http://lists.live555.com/pipermail/live-devel/attachments/20130221/4df1802a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 22 Feb 2013 15:41:05 +0100<br>
From: S?bastien Escudier <<a href="mailto:sebastien-devel@celeos.eu">sebastien-devel@celeos.eu</a>><br>
To: <a href="mailto:live-devel@ns.live555.com">live-devel@ns.live555.com</a><br>
Subject: [Live-devel] TS discontinuity when seeking<br>
Message-ID: <<a href="mailto:51278381.10101@celeos.eu">51278381.10101@celeos.eu</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi Ross,<br>
<br>
I noticed that after a seek, the first TS packet from live555 server,<br>
does not have the correct continuity counter value (with respect to the<br>
last packet before the seek). There is a discontinuity.<br>
This is error is reported in VLC and wireshark.<br>
<br>
Regards,<br>
S?bastien.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 22 Feb 2013 22:04:35 +0100<br>
From: S?bastien Escudier <<a href="mailto:sebastien-devel@celeos.eu">sebastien-devel@celeos.eu</a>><br>
To: <a href="mailto:live-devel@ns.live555.com">live-devel@ns.live555.com</a><br>
Subject: Re: [Live-devel] getNormalPlayTime after a pause and play<br>
Message-ID: <<a href="mailto:5127DD63.7080400@celeos.eu">5127DD63.7080400@celeos.eu</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Another solution would be to modify your server to return the actual npt<br>
in the PLAY response.<br>
Currently, when your server resume from the previous position, it does<br>
not return any npt value in the PLAY response.<br>
<br>
I guess both fixes would be valid.<br>
<br>
Best regards,<br>
Sebastien.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 22 Feb 2013 20:31:21 +1000<br>
From: Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>><br>
To: LIVE555 Streaming Media - development & use<br>
<<a href="mailto:live-devel@ns.live555.com">live-devel@ns.live555.com</a>><br>
Subject: Re: [Live-devel] OnDemandRTSPServer working with File as File<br>
source but not File as Pipe<br>
Message-ID: <<a href="mailto:88BFA771-C746-4CC1-98BE-729F2BC86C27@live555.com">88BFA771-C746-4CC1-98BE-729F2BC86C27@live555.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
> Both File as File and File as Pipe look great on VLC over the lan. But to the iPad, the File as File looks great but the File as Pipe is very blocky, as if compression info is missing or whatever.<br>
><br>
> This tells me two things: (#1) it seems VLC may be more robust and forgiving than our iPad app, as expected; and (#2) there's some difference in what Live555 sends (perhaps presentation time?) depending on whether the stream came from File as File or File as Pipe.<br>
<br>
No, the difference is not the frames' presentation times, because they are derived from the input H.264 data, which should be the same in both cases.<br>
<br>
The difference is likely that reads from the pipe - and thus transmissions over the network - are not happening smoothly. I.e., you are probably reading a large chunk of data from the pipe, then waiting a long time (for more data to become available in the pipe), then reading a large chunk of data from the pipe, etc. Because of these 'bursty' reads from the pipe, network transmission (of RTP packets) is also happening in a 'bursty' fashion.<br>
<br>
Your receiving application *should* be able to handle this OK, if it does reasonable buffering of incoming data (i.e., data that has just been read from the "RTPSource" object). But the fact that it's not handling this OK (but VLC does) suggests that your receiving player (on the iPad) is not buffering incoming data enough before decoding/rendering it. That is the first thing that you should fix (because bursty/jittery data can happen in many environments).<br>
<br>
However, you should also fix whatever is causing reads from your pipe (i.e., on your server) to be so bursty. Because I don't know anything about your server OS, I can't help you here. But if you are running Windows (which often has a notoriously coarse process-switching granularity), then please stop. In this day and age, Windows is simply not a serious OS for running server applications.<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.live555.com/pipermail/live-devel/attachments/20130222/674243c1/attachment-0001.html" target="_blank">http://lists.live555.com/pipermail/live-devel/attachments/20130222/674243c1/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 22 Feb 2013 14:54:25 +0100<br>
From: HOFFMANN Eric <<a href="mailto:eric.hoffmann@thalesgroup.com">eric.hoffmann@thalesgroup.com</a>><br>
To: "<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>" <<a href="mailto:live-devel@ns.live555.com">live-devel@ns.live555.com</a>><br>
Subject: [Live-devel] testH264VideoStreamer multi client play stop<br>
Message-ID:<br>
<16632_1361541318_512778C6_16632_206_1_8AF751CD48F5A14AADA5E935BB6A406501EC21D29610@THSONEA01CMS03P.one.grp><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi,<br>
I would like to implement the same functionality than testH264VideoStreamer (rtsp, multicast, loop file) but i need to start streaming at first client and stop when the last quit.<br>
Any suggestion would be helpful<br>
<br>
Regards,<br>
eric<br>
<br>
<br>
[@@ THALES GROUP INTERNAL @@]<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.live555.com/pipermail/live-devel/attachments/20130222/b4253d31/attachment-0001.html" target="_blank">http://lists.live555.com/pipermail/live-devel/attachments/20130222/b4253d31/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Sat, 23 Feb 2013 10:16:14 +1000<br>
From: Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>><br>
To: LIVE555 Streaming Media - development & use<br>
<<a href="mailto:live-devel@ns.live555.com">live-devel@ns.live555.com</a>><br>
Subject: Re: [Live-devel] testH264VideoStreamer multi client play stop<br>
Message-ID: <<a href="mailto:E4919ACD-E7AD-45A5-8B58-13B93AF22193@live555.com">E4919ACD-E7AD-45A5-8B58-13B93AF22193@live555.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
> I would like to implement the same functionality than testH264VideoStreamer (rtsp, multicast, loop file) but i need to start streaming at first client and stop when the last quit.<br>
> Any suggestion would be helpful<br>
<br>
I'm not sure how easy this would be to do without a lot of work.<br>
<br>
One thing that might work, though, would be to define your own subclass of "PassiveServerMediaSubsession" and redefine the "startStream()", "deleteStream()", and (perhaps) "getStreamParameters()" virtual functions to do <whatever>, and then call the original (superclass) version of each virtual function. You're pretty much on your own here, though...<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.live555.com/pipermail/live-devel/attachments/20130223/272f786e/attachment.html" target="_blank">http://lists.live555.com/pipermail/live-devel/attachments/20130223/272f786e/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br>
<br>
End of live-devel Digest, Vol 112, Issue 27<br>
*******************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Matt Czarnek, Software Engineer<div><div>Work Phone: (760) 4-OBJVID </div><div> aka: (760) 462-5843</div></div><div><br></div><div>
Cell Phone: HAHAHOORAY</div><div><br></div><div><p style="margin:0px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)"><font size="4">ObjectVideo Inc.</font></p><p style="margin:0px;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="font-size:10.5pt"><a href="http://www.objectvideo.com/" style="color:rgb(17,85,204)" target="_blank">http://www.objectvideo.com</a></span></p></div></div>
</div></div></div>