[Live-devel] help
Czarnek, Matt
mczarnek at objectvideo.com
Mon Feb 25 06:45:50 PST 2013
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.
Thank you!
Matt
On Fri, Feb 22, 2013 at 7:16 PM, <live-devel-request at ns.live555.com> wrote:
> Send live-devel mailing list submissions to
> live-devel at 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
> live-devel-request at lists.live555.com
>
> You can reach the person managing the list at
> live-devel-owner at lists.live555.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of live-devel digest..."
>
>
> Today's Topics:
>
> 1. OnDemandRTSPServer working with File as File source but not
> File as Pipe (temp2010 at forren.org)
> 2. TS discontinuity when seeking (S?bastien Escudier)
> 3. Re: getNormalPlayTime after a pause and play (S?bastien Escudier)
> 4. Re: OnDemandRTSPServer working with File as File source but
> not File as Pipe (Ross Finlayson)
> 5. testH264VideoStreamer multi client play stop (HOFFMANN Eric)
> 6. Re: testH264VideoStreamer multi client play stop (Ross Finlayson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Feb 2013 18:40:09 -0500
> From: "temp2010 at forren.org" <temp2010 at forren.org>
> To: live-devel at ns.live555.com
> Subject: [Live-devel] OnDemandRTSPServer working with File as File
> source but not File as Pipe
> Message-ID:
> <
> CAK0dNZidNpdvxTqazWosKp3zADqiaq1sb3Vtozw_6ai4wz1UkA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> We want our PC to send a video stream to an iPad, and we sometimes test by
> sending to VLC over the local network.
>
> The video stream gets into linked-in Live555 code via ByteStreamFileSource,
> but in two different ways. One way is from a file on disk (File as File).
> The other way is through a named pipe (File as Pipe).
>
> 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.
>
> 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.
>
> I'm writing you to ask about #2. If we can fix #2, then we don't have to
> fix #1.
>
> In detail (sorry, but there's no other way for the quick turn we need this
> week), Live555 InputFile.cpp already had a hood in it for filename "stdin".
> We tentatively added a hook for "pipe". Thus, we can easily switch
> between File as File (real filename) or File as Pipe (hooked "pipe"
> filename). This also means that the ONLY difference in the code base from
> this point all the way out to the iPad is this tiny difference. One would
> expect the output and iPad behavior to be the same... but it's not.
>
> Meanwhile, the actual stream being sent INTO the Pipe is simultaneously
> written to a raw h.264 file, and on later tests, it's that raw h.264 that's
> being read in the File as File case. Therefore, the content of the stream
> in both cases should be indistinguishable. We tried File as Pipe, and we
> got the blockiness. We then took that very raw h.264 file just written,
> and ran again with File as File, and we did NOT get the blockiness.
>
> So, back to #2, there simply must be some difference in what Live555 sends,
> between the two cases.
>
> Do you have any clue at all as to what this difference might be, and what
> we might do to get rid of it? My guess is something about presentation
> time, but I'm so ignorant on this stuff in general that I don't trust my
> own guess.
>
> (Once we figure it out, we can write alternate InputFile.cpp and
> ByteStreamFileSourcesource.cpp (and on up the rather long derivation chain)
> in order to return InputFile.cpp to it's pre-pipe-hook content. But it's
> too wasteful to do that first, in case this strategy fails to ever work at
> all...)
>
> Thanks very much for you help.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.live555.com/pipermail/live-devel/attachments/20130221/4df1802a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 22 Feb 2013 15:41:05 +0100
> From: S?bastien Escudier <sebastien-devel at celeos.eu>
> To: live-devel at ns.live555.com
> Subject: [Live-devel] TS discontinuity when seeking
> Message-ID: <51278381.10101 at celeos.eu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Ross,
>
> I noticed that after a seek, the first TS packet from live555 server,
> does not have the correct continuity counter value (with respect to the
> last packet before the seek). There is a discontinuity.
> This is error is reported in VLC and wireshark.
>
> Regards,
> S?bastien.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 22 Feb 2013 22:04:35 +0100
> From: S?bastien Escudier <sebastien-devel at celeos.eu>
> To: live-devel at ns.live555.com
> Subject: Re: [Live-devel] getNormalPlayTime after a pause and play
> Message-ID: <5127DD63.7080400 at celeos.eu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Another solution would be to modify your server to return the actual npt
> in the PLAY response.
> Currently, when your server resume from the previous position, it does
> not return any npt value in the PLAY response.
>
> I guess both fixes would be valid.
>
> Best regards,
> Sebastien.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 22 Feb 2013 20:31:21 +1000
> From: Ross Finlayson <finlayson at live555.com>
> To: LIVE555 Streaming Media - development & use
> <live-devel at ns.live555.com>
> Subject: Re: [Live-devel] OnDemandRTSPServer working with File as File
> source but not File as Pipe
> Message-ID: <88BFA771-C746-4CC1-98BE-729F2BC86C27 at live555.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > 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.
> >
> > 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.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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/20130222/674243c1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Fri, 22 Feb 2013 14:54:25 +0100
> From: HOFFMANN Eric <eric.hoffmann at thalesgroup.com>
> To: "live-devel at lists.live555.com" <live-devel at ns.live555.com>
> Subject: [Live-devel] testH264VideoStreamer multi client play stop
> Message-ID:
>
> <16632_1361541318_512778C6_16632_206_1_8AF751CD48F5A14AADA5E935BB6A406501EC21D29610 at THSONEA01CMS03P.one.grp
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
> 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.
> Any suggestion would be helpful
>
> Regards,
> eric
>
>
> [@@ THALES GROUP INTERNAL @@]
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.live555.com/pipermail/live-devel/attachments/20130222/b4253d31/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Sat, 23 Feb 2013 10:16:14 +1000
> From: Ross Finlayson <finlayson at live555.com>
> To: LIVE555 Streaming Media - development & use
> <live-devel at ns.live555.com>
> Subject: Re: [Live-devel] testH264VideoStreamer multi client play stop
> Message-ID: <E4919ACD-E7AD-45A5-8B58-13B93AF22193 at live555.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > 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.
> > Any suggestion would be helpful
>
> I'm not sure how easy this would be to do without a lot of work.
>
> 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...
>
> 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/20130223/272f786e/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
> End of live-devel Digest, Vol 112, Issue 27
> *******************************************
>
--
Matt Czarnek, Software Engineer
Work Phone: (760) 4-OBJVID
aka: (760) 462-5843
Cell Phone: HAHAHOORAY
ObjectVideo Inc.
http://www.objectvideo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130225/51a1c9e5/attachment-0001.html>
More information about the live-devel
mailing list