On 3/24/08, Luca Abeni <[EMAIL PROTECTED]> wrote: > > Hi Mahmoud,
Hi Luca Mahmoud M'HIRI wrote: > > I'm trying to live transcode input (mp2/mpeg2video) to > > libamr_nb/ffh263(Supported formats in mobile devices), the problem is > > that when launching > > ffmpeg: > > > > ffmpeg -i rtp://0.0.0.0?localport=2020 -acodec libamr_nb -ar 8000 -ac 1 > -ab > > 12.2k -f rtp rtp://192.168.50.147:8082 -an -vcodec h263p -flags aic -r > 14 -b > > 20k -s 176*144 -f rtp rtp://192.168.50.147:8080 > > > There are some problems here: > 1) I suspect "-i rtp://0.0.0.0?localport=2020" could be wrong This way of input is confirmed since I use it to save streams I receive into disc files (which I replay correctly). (I used to enter: @:port and it won't work, i think that I got the answer in this mailing list). 2) AMR and H.263 packetizations are not currently supported by the RTP > muxer, and by the SDP generator. It could be the case for the SDP generator and for AMR, but I'm successfully live-transcoding from mpeg2 to h263p (tested with ffplay -f h263 rtp://0.0.0.0?localport=5050). I am not sure if H263+ requires a > dynamic payload type, or if payload type 34 can be used. In any case, > the SDP generator should be extended to support H263. 34 is used when the -vcodec is h263, but when it's h263p, the PT given by the SDP generator is dynamic. 3) When there are two streams with dynamic payload types, libavformat > ends up giving the same PT to both the two streams. I suspect this is > not wrong, but having the same PT for two different codecs confuses some > players. I agree that the same dynamic PT do not cause troubles to players, but I'm not sure. But I noticed that ffmpeg is putting 0 in the ssrc field for both streams (A / V), does this cause any troubles to players? [...] > > > I have this very poor SDP: > > > > v=0 > > o=- 0 0 IN IPV4 127.0.0.1 > > t=0 0 > > s=No Name > > a=tool:libavformat > > m=audio 8082 RTP/AVP 96 > > c=IN IP4 192.168.50.42 > > m=video 8080 RTP/AVP 96 > > c=IN IP4 192.168.50.42 > > > This happens because H263 and AMR in RTP are not supported (yet). > > [...] > > > I attached the SDP file I'm using. Realplayer is buffering until 100% > but > > not displaying video, and the audio is very fast as if the sampling > > frequency is incorrect. > > > Since the RTP muxer does not support H263 and AMR, the packetization is > probably wrong. Also, I do not know where you got the config values > from, but they might be wrong. Yes they could... have you any idea how and where to hack ffmpeg for AMR packetization support? Why ffmpeg displays output as if he was correctly streaming when he does noit support amr for rtp (using this command: ffmpeg -i rtp://0.0.0.0?localport=2020 -vn -acodec libamr_nb -ar 8000 -ac 1 -ab 12.2k -f rtp rtp://192.168.50.144:8080 ) Thanks Luca > _______________________________________________ > libav-user mailing list > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > -- Mahmoud M'HIRI [EMAIL PROTECTED] Phone: Under request _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
