>14:28:06 > Groupsock(5: 232.34.164.65, 8888, SSM source: >> 192.168.2.46): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) >> error: No such device >> 14:28:06 Groupsock(6: 232.34.164.65, 8889, SSM source: 192.168.2.46): >> failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: No such >> device >> >> And VLC doesn't display anything. Same thing if I try to access it >> with ffmpeg. What's wrong? > > You don't have multicast configured properly on your client computer. > (Make sure you have a route for 224.0.0/4 ) > > Also, of course, you will need to have multicast connectivity between > your server and client. (If you're on a LAN then that should not be > an issue.) OK, that seems to work for VLC, but not for FFMPEG, I stillt get the same error there... (I'm on a LAN) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5198 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.live555.com/pipermail/live-devel/attachments/20070511/d8285146/attachment.bin From odjosc at free.fr Fri May 11 14:35:34 2007 From: odjosc at free.fr (Olivier DJIAN) Date: Fri, 11 May 2007 23:35:34 +0200 Subject: [Live-devel] RTSP source for VDR In-Reply-To: References: <1170082800.45be0bf0406e0@imp.free.fr> <1170168882.45bf5c3265b63@imp.free.fr> Message-ID: <200705112335.34115.odjosc@free.fr> Hi, Finally, I succeeded writing the MediaSink object and all seems to work fine. However, on an Athlon 1800+ computer, VDR consumes 100% CPU when plugin with liveMedia is used (RTSP source) and 3% if not (using a DVB PCI card source). I wonder how the "forever loop" works (e.g. env->taskScheduler().doEventLoop()) Does someone have suggestions to help me diagnose where in my liveMedia using there is some excessive cpu-consuming code (I don't make any video decoding nor encoding with liveMedia as VDR uses TS stream directly) ? Thanks for your help. Olivier. Le mardi 30 janvier 2007, Ross Finlayson a ?crit?: > > > I.e., you must write an appropriate "MediaSink" object to handle the > >> > >> incoming TS data. (However, if you plan to just store this in a > >> file, then you can use most of the "openRTSP" code as is. Or, you > >> can just run "openRTSP" with the "-v" option, to get the incoming TS > >> data written to 'stdout'.) > >> -- > > > >Unfortunately, it's not that easy because I'm only writing a plugin for > > VDR. > > Therefore, you're going to have to figure out how to write such a > 'plugin' that works with the "LIVE555 Streaming Media" event loop. > Because I don't know anything about how such a plugin works - in > particular, whether it has its own event loop (in which case you'd > need to somehow merge it with ours), or whether it has its own > thread, doing reads synchronously - I'm probably not going to be able > to help you any more with this. I suggest consulting an appropriate > mailing list for your VDR software. From dweber at robotics.net Fri May 11 15:44:40 2007 From: dweber at robotics.net (Dan Weber) Date: Fri, 11 May 2007 18:44:40 -0400 Subject: [Live-devel] Fails to reschedule getNextFrame(...,pt) Message-ID: <20070511224440.GA8891@Barney.robotics.net> Hi guys, Attached is a patch that adds multiple payload type support at the RTP Source level. I'm experiencing an issue after I get say DTMF pt 101 and it properly calls my dtmfsource's class afterGettingFunc, and then that rtpsource, seems to either A) stop listening for network input (although no bounces shown in ethereal) or B) fails to reschedule. My DTMFSource class also attached, properly calls FramedSource::afterGetting, this as well. There are two seperate SimpleRTPSinks on the same groupsock (one for audio and one for dtmf). So I'm confused, Does anybody know of an obvious answer to what could be the cause of the problem? Thanks, Dan -------------- next part -------------- Index: live/liveMedia/include/MultiFramedRTPSource.hh =================================================================== --- live.orig/liveMedia/include/MultiFramedRTPSource.hh 2007-05-08 16:10:07.000000000 -0400 +++ live/liveMedia/include/MultiFramedRTPSource.hh 2007-05-08 18:43:01.000000000 -0400 @@ -26,10 +26,64 @@ #include "RTPSource.hh" #endif +#include +#include "FramedSource.hh" + +struct MultiFramedRTPSourceInfo { + typedef void (afterGettingFunc)(void* clientData, unsigned frameSize, + unsigned numTruncatedBytes, + struct timeval presentationTime, + unsigned durationInMicroseconds); + + unsigned char rtpPayloadType; + unsigned char* fTo; + unsigned fMaxSize; + afterGettingFunc* fAfterGettingFunc; + void* fAfterGettingFuncClientData; + + MultiFramedRTPSourceInfo() {} + + MultiFramedRTPSourceInfo(unsigned char pt, + unsigned char* to, + unsigned maxSize, + afterGettingFunc* afterGettingFunc, + void* afterGettingFuncClientData) : + rtpPayloadType(pt), + fTo(to), + fMaxSize(maxSize), + fAfterGettingFunc(afterGettingFunc), + fAfterGettingFuncClientData(afterGettingFuncClientData) {} +}; + + class BufferedPacket; // forward class BufferedPacketFactory; // forward class MultiFramedRTPSource: public RTPSource { +public: + void getNextFrame(unsigned char* to, unsigned maxSize, + afterGettingFunc* afterGettingFunc, + void* afterGettingClientData, + onCloseFunc* onCloseFunc, + void* onCloseClientData) { + FramedSource::getNextFrame(to,maxSize,afterGettingFunc,afterGettingClientData, + onCloseFunc, onCloseClientData); + } + void getNextFrame(unsigned char* to, unsigned maxSize, + afterGettingFunc* afterGettingFunc, + void* afterGettingClientData, + onCloseFunc* onCloseFunc, + void* onCloseClientData, unsigned char rtpPayloadType) { + + mPayloadHash[rtpPayloadType] = MultiFramedRTPSourceInfo(rtpPayloadType, + to, + maxSize, + afterGettingFunc, + afterGettingClientData); + // Can't handle onClose for now + } + + protected: MultiFramedRTPSource(UsageEnvironment& env, Groupsock* RTPgs, unsigned char rtpPayloadFormat, @@ -50,6 +104,9 @@ protected: Boolean fCurrentPacketBeginsFrame; Boolean fCurrentPacketCompletesFrame; + std::map mPayloadHash; + unsigned char fAfterGettingPt; + protected: // redefined virtual functions: @@ -64,6 +121,19 @@ void reset(); void doGetNextFrame1(); + static void alternatePtAfterGetting(FramedSource* framedSource) { + MultiFramedRTPSource* fs = dynamic_cast(framedSource); + if (!fs) + throw; + MultiFramedRTPSourceInfo& info = fs->mPayloadHash[fs->fAfterGettingPt]; + if (info.fAfterGettingFunc) + (*info.fAfterGettingFunc)(info.fAfterGettingFuncClientData,fs->fFrameSize, + fs->fNumTruncatedBytes,fs->fPresentationTime, + fs->fDurationInMicroseconds); + fs->mPayloadHash.erase(fs->fAfterGettingPt); + fs->fAfterGettingPt = 0; + } + static void networkReadHandler(MultiFramedRTPSource* source, int /*mask*/); friend void networkReadHandler(MultiFramedRTPSource*, int); @@ -94,7 +164,7 @@ void assignMiscParams(unsigned short rtpSeqNo, unsigned rtpTimestamp, struct timeval presentationTime, Boolean hasBeenSyncedUsingRTCP, - Boolean rtpMarkerBit, struct timeval timeReceived); + Boolean rtpMarkerBit, struct timeval timeReceived, unsigned char rtpPayloadType); void skip(unsigned numBytes); // used to skip over an initial header void removePadding(unsigned numBytes); // used to remove trailing bytes void appendData(unsigned char* newData, unsigned numBytes); @@ -112,6 +182,7 @@ unsigned char* data() const { return &fBuf[fHead]; } unsigned dataSize() const { return fTail-fHead; } Boolean rtpMarkerBit() const { return fRTPMarkerBit; } + unsigned char rtpPayloadType() const { return fRTPPayloadType; } protected: virtual void reset(); @@ -138,6 +209,7 @@ Boolean fHasBeenSyncedUsingRTCP; Boolean fRTPMarkerBit; struct timeval fTimeReceived; + unsigned char fRTPPayloadType; }; // A 'factory' class for creating "BufferedPacket" objects. Index: live/liveMedia/MultiFramedRTPSource.cpp =================================================================== --- live.orig/liveMedia/MultiFramedRTPSource.cpp 2007-05-08 16:41:44.000000000 -0400 +++ live/liveMedia/MultiFramedRTPSource.cpp 2007-05-10 18:41:40.000000000 -0400 @@ -169,10 +169,20 @@ // The packet is usable. Deliver all or part of it to our caller: unsigned frameSize; - nextPacket->use(fTo, fMaxSize, frameSize, fNumTruncatedBytes, + if (nextPacket->rtpPayloadType() == rtpPayloadFormat()) { + nextPacket->use(fTo, fMaxSize, frameSize, fNumTruncatedBytes, fCurPacketRTPSeqNum, fCurPacketRTPTimestamp, fPresentationTime, fCurPacketHasBeenSynchronizedUsingRTCP, fCurPacketMarkerBit); + } else { + // This implies we have an alternate handler for this payload type + MultiFramedRTPSourceInfo& info = mPayloadHash[nextPacket->rtpPayloadType()]; + fAfterGettingPt = nextPacket->rtpPayloadType(); + nextPacket->use(info.fTo,info.fMaxSize,frameSize,fNumTruncatedBytes, + fCurPacketRTPSeqNum, fCurPacketRTPTimestamp, + fPresentationTime, fCurPacketHasBeenSynchronizedUsingRTCP, + fCurPacketMarkerBit); + } fFrameSize += frameSize; if (!nextPacket->hasUsableData()) { @@ -192,16 +202,33 @@ // Common case optimization: There are no more queued incoming packets, so this code will not get // executed again without having first returned to the event loop. Call our 'after getting' function // directly, because there's no risk of a long chain of recursion (and thus stack overflow): - afterGetting(this); + + if (nextPacket->rtpPayloadType() == rtpPayloadFormat()) { + afterGetting(this); + } else { + MultiFramedRTPSourceInfo& info = mPayloadHash[nextPacket->rtpPayloadType()]; + (*info.fAfterGettingFunc)(info.fAfterGettingFuncClientData,fFrameSize, + fNumTruncatedBytes,fPresentationTime, + fDurationInMicroseconds); + mPayloadHash.erase(nextPacket->rtpPayloadType()); + } } else { // Special case: Call our 'after getting' function via the event loop. + nextTask() = envir().taskScheduler().scheduleDelayedTask(0, - (TaskFunc*)FramedSource::afterGetting, this); + nextPacket->rtpPayloadType() == rtpPayloadFormat() ? + (TaskFunc*)FramedSource::afterGetting : (TaskFunc*)alternatePtAfterGetting, this); + } } else { // This packet contained fragmented data, and does not complete // the data that the client wants. Keep getting data: - fTo += frameSize; fMaxSize -= frameSize; + if (nextPacket->rtpPayloadType() == rtpPayloadFormat()) { + fTo += frameSize; fMaxSize -= frameSize; + } else { + MultiFramedRTPSourceInfo& info = mPayloadHash[nextPacket->rtpPayloadType()]; + info.fTo += frameSize; info.fMaxSize -= frameSize; + } fNeedDelivery = True; } } @@ -265,7 +292,8 @@ // Check the Payload Type. if ((unsigned char)((rtpHdr&0x007F0000)>>16) != source->rtpPayloadFormat()) { - break; + if (source->mPayloadHash.find((unsigned char)((rtpHdr&0x007F0000)>>16)) == source->mPayloadHash.end()) + break; } // The rest of the packet is the usable data. Record and save it: @@ -287,7 +315,7 @@ gettimeofday(&timeNow, NULL); bPacket->assignMiscParams(rtpSeqNo, rtpTimestamp, presentationTime, hasBeenSyncedUsingRTCP, rtpMarkerBit, - timeNow); + timeNow, (unsigned char)((rtpHdr&0x007F0000)>>16)); if (!source->fReorderingBuffer->storePacket(bPacket)) break; readSuccess = True; @@ -360,13 +388,14 @@ ::assignMiscParams(unsigned short rtpSeqNo, unsigned rtpTimestamp, struct timeval presentationTime, Boolean hasBeenSyncedUsingRTCP, Boolean rtpMarkerBit, - struct timeval timeReceived) { + struct timeval timeReceived, unsigned char rtpPayloadType) { fRTPSeqNo = rtpSeqNo; fRTPTimestamp = rtpTimestamp; fPresentationTime = presentationTime; fHasBeenSyncedUsingRTCP = hasBeenSyncedUsingRTCP; fRTPMarkerBit = rtpMarkerBit; fTimeReceived = timeReceived; + fRTPPayloadType = rtpPayloadType; } void BufferedPacket::skip(unsigned numBytes) { -------------- next part -------------- #include "DTMFSource.h" #include namespace msoup { DTMFSource::DTMFSource(UsageEnvironment& ue, MultiFramedRTPSource* fs, uint8_t payloadType) : FramedFilter(ue, fs), mBuffer(1000), mPayloadType(payloadType) { } void DTMFSource::doGetNextFrame() { if (!fInputSource) { return; } MultiFramedRTPSource* fs = static_cast(fInputSource); fs->getNextFrame(&mBuffer[0], 1000, afterGettingFrame, this, FramedFilter::handleClosure, this, mPayloadType); } void DTMFSource::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { std::copy(mBuffer.begin(),mBuffer.begin()+frameSize,fTo); fPresentationTime = presentationTime; fDurationInMicroseconds = durationInMicroseconds; fNumTruncatedBytes = numTruncatedBytes; fFrameSize = frameSize; FramedSource::afterGetting(this); } DTMFSource::~DTMFSource() { } } -------------- next part -------------- #ifndef DTMFSOURCE_H_ #define DTMFSOURCE_H_ #include "liveMedia.hh" #include namespace msoup { class DTMFSource : public FramedFilter { std::vector mBuffer; const uint8_t mPayloadType; public: DTMFSource(UsageEnvironment& ue, MultiFramedRTPSource* fs, uint8_t payloadType = 101); virtual void doGetNextFrame(); virtual ~DTMFSource(); private: static void afterGettingFrame(void* clientData, unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { static_cast(clientData)->afterGettingFrame(frameSize,numTruncatedBytes,presentationTime,durationInMicroseconds); } void afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds); }; } #endif /*DTMFSOURCE_H_*/ From finlayson at live555.com Fri May 11 22:18:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 11 May 2007 22:18:53 -0700 Subject: [Live-devel] IP_ADD_MEMBERSHIP error In-Reply-To: <4644C102.5080007@mytum.de> References: <46446568.9020703@mytum.de> <4644C102.5080007@mytum.de> Message-ID: >OK, that seems to work for VLC, but not for FFMPEG This mailing list has nothing to do with FFMPEG. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yinglcs at gmail.com Sat May 12 13:50:13 2007 From: yinglcs at gmail.com (ying lcs) Date: Sat, 12 May 2007 15:50:13 -0500 Subject: [Live-devel] Using live555 as the RTSP streaming library Message-ID: <568e62a40705121350h5a4acbeaub2197c52095c09eb@mail.gmail.com> Hi, Can you please tell me if live555 sends out RSTP Sender Report when it streams a file? Thank you. From finlayson at live555.com Sat May 12 22:46:25 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 12 May 2007 22:46:25 -0700 Subject: [Live-devel] Using live555 as the RTSP streaming library In-Reply-To: <568e62a40705121350h5a4acbeaub2197c52095c09eb@mail.gmail.com> References: <568e62a40705121350h5a4acbeaub2197c52095c09eb@mail.gmail.com> Message-ID: >Can you please tell me if live555 sends out RSTP Sender Report when it >streams a file? I think you mean "RTCP Sender Report" (not "RTSP Sender Report"). Yes, our RTSP server implementation (more precisely, the "OnDemandServerMediaSubsession" and "PassiveServerMediaSubsession" classes) creates "RTCPInstance" objects for each stream, and these send out RTCP Sender Report ("SR") packets. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rajeshkumar.r at imimobile.com Mon May 14 01:52:58 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Mon, 14 May 2007 14:22:58 +0530 Subject: [Live-devel] Transfering the Multimedia Content from one Port to different Port References: <0fba01c793aa$98289bb0$6902000a@imidomain.com> Message-ID: <15b501c79605$4592f410$6902000a@imidomain.com> Re: [Live-devel] Transfering the Multimedia Content from oHi Ross, Thanks for the Reply. if I want to transfer multimedia content on port number on different system(IP). instead of local system I want to transfer multimedia content on different system. Thanks and Regards Rajesh Kumar Software Enginner Cont-9908400027 NOTE: mobile not in use in office time. ----- Original Message ----- From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Friday, May 11, 2007 7:24 PM Subject: Re: [Live-devel] Transfering the Multimedia Content from one Port to different Port using openRTSP client ,I am able to recv the multimedia streaming on 6000 and 60002 port. I want to transfer the same data to different port say 3000-3002. 3000 and 3002 port are being used by Application that will transfer the same content to the mobile. You can do this using openRTSP's "-p " option. (See the documentation.) -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070514/5fda74f6/attachment.html From philip.marivoet at gmail.com Mon May 14 05:16:45 2007 From: philip.marivoet at gmail.com (Philip Marivoet) Date: Mon, 14 May 2007 14:16:45 +0200 Subject: [Live-devel] Index file for H.264/AAC over mpeg2ts Message-ID: <2c14d2900705140516t1c9773e3y315327f4e26391f4@mail.gmail.com> Hi, >>I've seen some recent posts regarding H.264 - specifically one >>regarding the creation of index files. I have placed an HD H.264 >>sample clip from a live encoder and was wondering if someone (Ross >>?) could take a look to see what would be required to be able to >>support indexing? >> >>You can access the file here: >>http://www.geeknet.ca/~temp/tenten16-2.ts > >Thanks. (I'm downloading this now.) We are using the live555Mediaserver to stream MPEG2/TS files containing H.264 video and AAC audio. This is working very well (thank you), but we would like to use the trick mode functionality. Did you already make some progress on the index file generation for H.264 TS files? Regards, Philip From finlayson at live555.com Mon May 14 07:50:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 May 2007 07:50:54 -0700 Subject: [Live-devel] Index file for H.264/AAC over mpeg2ts In-Reply-To: <2c14d2900705140516t1c9773e3y315327f4e26391f4@mail.gmail.com> References: <2c14d2900705140516t1c9773e3y315327f4e26391f4@mail.gmail.com> Message-ID: >We are using the live555Mediaserver to stream MPEG2/TS files >containing H.264 video and AAC audio. This is working very well (thank >you), but we would like to use the trick mode functionality. > >Did you already make some progress on the index file generation for >H.264 TS files? When this is available, I'll announce it to the mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yinglcs at gmail.com Mon May 14 09:28:51 2007 From: yinglcs at gmail.com (ying lcs) Date: Mon, 14 May 2007 11:28:51 -0500 Subject: [Live-devel] Using live555 as the RTSP streaming library In-Reply-To: References: <568e62a40705121350h5a4acbeaub2197c52095c09eb@mail.gmail.com> Message-ID: <568e62a40705140928v4b8a7813r96b99546863f6480@mail.gmail.com> I am using vlc to tanscode a file in boardcast mode, like this: vlc -I dummy mask.wmv --sout #transcode{vcodec=mp4v,vb=400,acodec=mpga,ab=128}:rtp{dst=10.20.20.68,port-video=3444,port-audio=3448,sdp=file:///usr/local/movies/mytest4.sdp} I think vlc depends os live555 as it rtp transport. And I have setup a network trace to capture rtp packet sent out: 10.. .... = Version : RFC 1889 Version (2) ..0. .... = Padding: False ...0 .... = Extension: False .... 0000 = contributing source identifiers count: 0 0... .... = Marker: False Payload type: Unknown (96) Sequence number: 18499 Timestamp: 719731146 Synchronization Source identifier: 1472073403 Payload: 043D8DF8180F84208524064B .... My question is why the payload type is 96? If that is the case, how can the client decode this RTP packet? Thank you. On 5/13/07, Ross Finlayson wrote: > >Can you please tell me if live555 sends out RSTP Sender Report when it > >streams a file? > > I think you mean "RTCP Sender Report" (not "RTSP Sender Report"). > > Yes, our RTSP server implementation (more precisely, the > "OnDemandServerMediaSubsession" and "PassiveServerMediaSubsession" > classes) creates "RTCPInstance" objects for each stream, and these > send out RTCP Sender Report ("SR") packets. > -- > > 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 > From finlayson at live555.com Mon May 14 10:30:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 May 2007 10:30:27 -0700 Subject: [Live-devel] Using live555 as the RTSP streaming library In-Reply-To: <568e62a40705140928v4b8a7813r96b99546863f6480@mail.gmail.com> References: <568e62a40705121350h5a4acbeaub2197c52095c09eb@mail.gmail.com> <568e62a40705140928v4b8a7813r96b99546863f6480@mail.gmail.com> Message-ID: >I think vlc depends os live555 as it rtp transport. Only when it is *receiving* RTP packets. If you are using VLC to *send* RTP packets, then it currently does not use the "LIVE555 Streaming Media" software. It wasn't clear (to me) from your description whether you are using VLC to receive RTP packets, or to send them. In any case, questions about VLC should really be sent to a VLC mailing list... >My question is why the payload type is 96? If that is the case, how >can the client decode this RTP packet? From a "a=rtpmap:" line in the SDP description. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andreas at videosave.net Mon May 14 13:18:11 2007 From: andreas at videosave.net (Andreas Schobel) Date: Mon, 14 May 2007 16:18:11 -0400 Subject: [Live-devel] Looking for a contractor to do some customization work on OpenRTSP Message-ID: Howdy, Our goal is to store audio & video to disk from a VivoTek IP7135 and then be able to play back that video in the latest version of Quicktime. http://www.vivotek.com/products_ip7135.htm We already used OpenRTSP to store the A/V from the rtsp stream from that camera to one big file and played it back in an older version of QuickTime. What we need is have OpenRTSP save the A/V in two minute mp4 files and be playable in the latest version of QuickTime. Cheers, Andreas http://videosave.com From serkanboz80 at yahoo.com Tue May 15 00:17:15 2007 From: serkanboz80 at yahoo.com (serkan bozkurt) Date: Tue, 15 May 2007 00:17:15 -0700 (PDT) Subject: [Live-devel] H.264 streaming Message-ID: <857974.6332.qm@web54205.mail.re2.yahoo.com> Hi To All, I am currently trying to play a DVB-H stream that has the h.264video codec. Unfortunately my player do not support stream playing it only supports playing from files. The DVB-H stream has the RTP headers and I think that if I extract RTP header and adding the remaining parts I can obtain a h.264 file format so that my player can play it. Any idea about this? Best Regards... ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 From finlayson at live555.com Tue May 15 00:37:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 May 2007 00:37:45 -0700 Subject: [Live-devel] H.264 streaming In-Reply-To: <857974.6332.qm@web54205.mail.re2.yahoo.com> References: <857974.6332.qm@web54205.mail.re2.yahoo.com> Message-ID: >Hi To All, > >I am currently trying to play a DVB-H stream that has >the h.264video codec. > >Unfortunately my player do not support stream playing >it only supports playing from files. > >The DVB-H stream has the RTP headers and I think that >if I extract RTP header and adding the remaining parts >I can obtain a h.264 file format so that my player can >play it. > >Any idea about this? Is your stream accessible via RTSP? If so, try using "openRTSP" to save the incoming stream as a file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From serkanboz80 at yahoo.com Tue May 15 01:20:35 2007 From: serkanboz80 at yahoo.com (serkan bozkurt) Date: Tue, 15 May 2007 01:20:35 -0700 (PDT) Subject: [Live-devel] H.264 streaming In-Reply-To: Message-ID: <72433.85240.qm@web54206.mail.re2.yahoo.com> Since DVB-H is a live streaming there is no RTCP and RTSP implementation just RTP is implemented. So what should I do to make a h.264 file from a RTP stream? Best regards... --- Ross Finlayson wrote: > >Hi To All, > > > >I am currently trying to play a DVB-H stream that > has > >the h.264video codec. > > > >Unfortunately my player do not support stream > playing > >it only supports playing from files. > > > >The DVB-H stream has the RTP headers and I think > that > >if I extract RTP header and adding the remaining > parts > >I can obtain a h.264 file format so that my player > can > >play it. > > > >Any idea about this? > > Is your stream accessible via RTSP? If so, try > using "openRTSP" to > save the incoming stream as a file. > -- > > 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 > ____________________________________________________________________________________Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 From lucabe72 at email.it Tue May 15 01:54:23 2007 From: lucabe72 at email.it (Luca Abeni) Date: Tue, 15 May 2007 10:54:23 +0200 Subject: [Live-devel] H.264 streaming In-Reply-To: <72433.85240.qm@web54206.mail.re2.yahoo.com> References: <72433.85240.qm@web54206.mail.re2.yahoo.com> Message-ID: <4649753F.1030200@email.it> Hi, serkan bozkurt wrote: > Since DVB-H is a live streaming there is no RTCP and > RTSP implementation just RTP is implemented. I think this is not fully correct... DVB-H is unidirectional, so there is no RTSP server, but RTCP packets are obviously sent. I succesfully played various DVB-H streams with vlc, for example. You just need the SDP describing the stream (if you don't have it, you will have to parse the ESG for obtaining an SDP, but that's not easy). I do not remember the details, but I am pretty sure I've been able to play a DVB-H stream with mplayer too (you just need to compile mplayer with live555 libraries). > So what should I do to make a h.264 file from a RTP > stream? You can use vlc, for example... Or you can use the live555 libraries to write a program that downloads a stream given the SDP describing it (I did something similar some time ago... I remember it was quite easy, but I do not remember the details; if you search the mailing list archives, you'll find a mail from Ross explaining how to write such program). Luca From finlayson at live555.com Tue May 15 01:53:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 May 2007 01:53:50 -0700 Subject: [Live-devel] H.264 streaming In-Reply-To: <4649753F.1030200@email.it> References: <72433.85240.qm@web54206.mail.re2.yahoo.com> <4649753F.1030200@email.it> Message-ID: > > So what should I do to make a h.264 file from a RTP >> stream? >You can use vlc, for example... Or you c