On date Wednesday 2008-07-09 11:52:46 +0200, Luca Abeni wrote:
> Hi Stefano,
>
> Stefano Sabatini wrote:
> > Hi all, just some test cases:
> >
> > [EMAIL PROTECTED] ~/s/ffmpeg>
> > ./ffmpeg -i ~/test2.flv -f rtp -vcodec h263p "rtp://localhost:5004"
>
> Three problems, here:
> 1) You need the "-re" option before "-i <filename>, otherwise ffmpeg will
> send RTP packets as fast as possible, and the client's playback buffer
> will overflow immediately.
> Note that for some reason "-re" does not work with some input formats
> (and .flv seems to be one of such formats :). In general, it works well
> with .mpg files and .avi files produced by ffmpeg (I've seen some other
> AVIs for which "-re" does not work well).
> 2) H.263 (and H.263+) is not currently supported by the RTP muxer. Try
> mpeg{1,2}video, mpeg4, or H.264 instead
> 3) An RTP flow can contain only one stream. So, you probably need "-an"
>
> [...]
> > Duration: 00:00:30.01, start: 0.000000, bitrate: 96 kb/s
> > Stream #0.0: Video: vp6f, yuv420p, 320x240, 25.00 tb(r)
> > Stream #0.1: Audio: mp3, 44100 Hz, mono, 96 kb/s
> > Output #0, rtp, to 'rtp://localhost:5004':
> > Stream #0.0: Video: h263p, yuv420p, 320x240, q=2-31, 200 kb/s, 25.00
> > tb(c)
> > Stream #0.1: Audio: pcm_mulaw, 44100 Hz, mono, 352 kb/s
> > Stream mapping:
> > Stream #0.0 -> #0.0
> > Stream #0.1 -> #0.1
> > Could not write header for output file #0 (incorrect codec parameters ?)
>
> This is due to the reason 3) shown above.
>
> > ./ffmpeg -i ~/test2.flv -f rtp -vcodec mpeg4 -an "rtp://localhost:5004"
>
> 1) is still a problem, here.
>
>
> [...]
> > It seems to works fine
>
> Actually, if you look at the "time=..." entry in ffmpeg's output, you will
> see that it's increasing too fast...
>
>
> > the number of streams to write in the header
> > is just one due to -an, the strange thing is that the Payload type as
> > shown by wireshark is always 96, the same with -vocodec h263p.
>
> This is ok. 96 is a dynamic payload type, and the
> m=video 5004 RTP/AVP 96
> a=rtpmap:96 MP4V-ES/90000
> a=fmtp:96 profile-level-id=1
> lines in the SDP say that in this case it is MPEG4 video.
> So, no problem here.
>
>
> > ./ffmpeg -i ~/test2.flv -f rtp -vn "rtp://localhost:5004"
>
> Again, you might have problem 1) here.
> [...]
> > the PT is correctly recognized.
>
> Because you are using a static payload type.
>
>
> > Please note that in all these cases it seems the -re option isn't
> > working
>
> Yes, "-re" does not work with .flv input. I do not know if this is
> a bug in ffmpeg.c, or there is some reason for this behaviour.
>
>
> > and a runnning ffplay process launched like this:
> > [EMAIL PROTECTED] ~> ffplay "rtp://localhost?localport=5004"
>
> This is wrong. Never use "rtp://" URLs directly. If you want to play
> an RTP stream, you have to use its SDP description (as printed by
> ffmpeg). Just copy it in a .sdp file, and use "ffplay file.sdp".
>
> [...]
> > The only case when I can actually see something working, and only
> > apparently randomly, is this:
> >
> > [EMAIL PROTECTED] ~/s/ffmpeg>
> > ./ffmpeg -i ~/test2.flv -f rtp -acodec libmp3lame "rtp://localhost:5004"
>
> If this works, it happens by pure luck.
>
> [...]
> > My question is:
> >
> > is all this severely borken or am I simply badly misusing/misunderstanding
> > all this?
> Try this:
> 1) ffmpeg -i test.flv -vcodec mpeg2video -b 400k -acodec copy test.mpg
> 2) ffmpeg -fflags +genpts -re -i test.mpg -vcodec copy -an -f rtp
> rtp://127.0.0.1:10000 -vn -acodec copy -f rtp rtp://127.0.0.1:20000 -newaudio
> (note: when I use "vcodec copy" and/or "acodec copy", I need "-fflags
> +genpts";
> if you transcode when streaming, this option is not needed).
> 3) Copy the SDP in a file named test.sdp: it should look like
> v=0
> o=- 0 0 IN IPV4 127.0.0.1
> t=0 0
> s=No Name
> a=tool:libavformat 52.16.0
> m=video 10000 RTP/AVP 32
> c=IN IP4 127.0.0.1
> b=AS:104857
> m=audio 20000 RTP/AVP 14
> c=IN IP4 127.0.0.1
> b=AS:64
> 4) ffplay test.sdp
Works fine, yeah!
> If this does not work, please report the problems and I'll try to fix them.
>
> Once this works for you, you can try experiencing with on-the-fly
> transcoding, with other codecs (currently, mpeg1 and 2 video, mpeg4 video,
> H.264, mp2, mp3, AAC, and some PCM codecs are supported). In case you use
> mpeg4 or H.264 for the video, you can use in-band global headers or
> out-of-band global headers (when encoding, use the "-vglobal ..." option).
>
> [...]
> > Also (sorry for the possibly dumb question) is there a particular
> > reason for which there is an RTP muxer (libavf/rtpenc.c) but not a
> > demuxer?
>
> That's the RTSP or the SDP demuxer (in rtsp.c)
Many thanks for the fast and punctual response, I'll take some time to
digest all this then I'll report any eventual problem I'll fine (for
now I'm just curious about the -re pesky problem), also would be nice
to improve the error reporting to explicitely warn about problems such
as the unsupported payload types.
Ciao.
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
