On 3/24/08, Mahmoud M'HIRI <[EMAIL PROTECTED]> wrote: > > 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 >
Hi, Here two other h263-related facts: - VLC is able to correctly stream h263-2000/AMR (using the command-line version) - VLC uses FFmpeg for both h263 and AMR So could we assume that ffmpeg implements h263/AMR-NB streaming capablities? -- Mahmoud M'HIRI [EMAIL PROTECTED] Phone: Under request _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
