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
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)
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
