On Thu, Feb 17, 2011 at 2:55 PM, Steffen Ebersbach <[email protected]> wrote: > On 16.2.2011 11:21, michael chua wrote: >> >> The last 3 lines are: >> >> main debug: TIMER module_need() : 0.904 ms - Total 0.904 ms / 1 intvls >> (Avg 0.904 ms) >> main debug: `rtp://@:6001' successfully opened >> macosx debug: input has changed, refreshing interface >> >> After that, nothing. I can dump the entire log if it would help. This >> is the result when I listen to rtp://:6001 >> >> I think you might be right about needing to be contained within an >> MPEG2TS mux for RTP to work in VLC. Would you happen to know of any >> clients without this limitation? And is their a guide for muxing in >> MPEG2TS before sending packets to the RTP target? Does ffserver do >> this for outgoing RTP streams? >> > > No, I don't now about players without this restriction. The reason I think > mpegts is used, because there are packets that describe the stream and video > formats inside, so the right decoder can be used. But only a few codecs can > be muxed with mpegts (mpeg2, mpeg4, vc-1). For sending other Media through > rtp, rtsp is used to describe the session. > For sending mpegts with rtp look at the archive of the list for "Output > mpeg-ts to rtp". >
Thank you. I'll go have a look. I found an interesting white paper on the issue: http://www.envivio.com/files/white-papers/RTPvsTS-v4.pdf It seems like VLC doesn't support native RTP streaming, and requires MPEG2-TS RTP to work (I've found claims on their mailing list that the command line client supports it, but no descriptions as to how it can be used that way). For that matter, I'm not sure libav does... Not sure if its a design decision either, or simply a feature that hasn't been implemented yet. > >> As an experiment, I tried using plain udp instead (udp://:6001), and >> the streaming sort of worked. Frames were being received by VLC and >> displayed, but the quality was very poor (lots of artefacts, blotchy >> colors, and smudging). I was getting lots of errors in VLC's message >> log too: >> >> main warning: late picture skipped (8732> -9382) >> avcodec warning: cannot decode one frame (199 bytes) >> avcodec warning: cannot decode one frame (378 bytes) >> avcodec warning: cannot decode one frame (12 bytes) >> avcodec warning: cannot decode one frame (12 bytes) >> avcodec warning: cannot decode one frame (35 bytes) >> avcodec warning: cannot decode one frame (519 bytes) >> avcodec warning: cannot decode one frame (522 bytes) >> avcodec warning: cannot decode one frame (378 bytes) >> ... >> >> I think packets were probably being lost, so VLC couldn't decode some >> frames. This is probably the consequence of using plain UDP... >> > > Do you send the packets over wlan or wan? Because in a local network (say > 100 Mbit/s, one switch) normally not many udp packets are lost, then the > traffic is low. > I think the frames are not correct decoded, because on the sender you make > rtp and on the receiver udp, so vlc want to decode the Bytes inside udp as > video, without stripping the rtp header. > I was sending the packets to localhost. You're right, packet loss doesn't make sense. I'm not sure it's due to the RTP header not being stripped out though... if the RTP header is included in decoding, wouldn't that make the stream completely unplayable? I can still see the face in my sample video (I'm using foreman.yuv), and the motions and background objects are recognizable. It's just relaly blotchy. I think it's more likely that VLC doesn't check PTS and reorder packets to the correct sequence of frames. > > _______________________________________________ > libav-user mailing list > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
