[FFmpeg-devel] Problem with H.263+/RTP payload

Michael Niedermayer michaelni
Sun Jul 15 14:10:55 CEST 2007


On Sun, Jul 15, 2007 at 12:08:35PM +0200, Sergio Fadda wrote:
> Hi all.
> I'm writing a patch for the alsa channel of asterisk (I hope someone knows
> what I'm talking about... however it's not important).
> I've redirect RTP payloads sent by a SIP soft-phone (linphone for instance)
> and I'm trying to decode the H.263+ stream (or H.263-1998 if you prefer) in
> that channel. The status is:
> - I receive fragmented video frames that, as RFC-2190 says, represent the
> payload of RTP packets.
> - That fragments are organized in a H.263 header that preceding a H.263payload.
> - The last fragment of a H.263 complete frame is characterized by a marker
> flag in the corresponding RTP packet and I can recognize it.
> - RTP payloads are _correct_: I've compared it with captured (with
> wireshark) RTP payloads sent from linphone.
> Now, some questions:
> 1) are these points correct?
> 2) ffmpeg support H.263+ decoding? I mean, there's a CODEC_ID_H263 for
> enc/decoding, but there's only a CODEC_ID_H263P for encoding! Is
> CODEC_ID_H263 decoding compatible with H.263+ stream?
> Now, what I'm doing to accomplish this is (in metalanguage):
> a) Initialization of ffmpeg environment
>   - avcodec_init
>   - avcodec_register_all
>   - avcodec_find_decoder(CODEC_ID_H263)
>   - avcodec_alloc_context
>   - avcodec_get_context_defaults [see question 3]

>   - context->flag |= CODEC_FLAG_TRUNCATED

dont do this

>   - avcodec_open
>   - avcodec_alloc_frame
>   - avcodec_get_frame_defaults [see question 3]
>   - av_parser_init(CODEC_ID_H263) [see question 4]
> b) Read a new fragment
> c) av_parser_parse [see questions 4 and 5]
> d) avcodec_decode_video [see question 6]
> And now, more questions:
> 3) Are these functions ('avodec_get_(context|frame)_defaults') usefull?

avcodec_alloc_* calls them already so if you use that you dont need to
call them again

> 4) are they necessary?


> 5) I don't really understand what this function does! Perhaps it analyses
> H.263 headers... The problem is that when I call this function to a fragment
> it return that no output data is available.

it merges a randomly choped up stream into proper frames

> 6) And here is another trouble: since 'av_parser_parse' returns no data I've
> call it with original fragment; after call it, it return 0 and no matter how
> many times I call it: 'got_picture' parameter is always 0!
> Does anyone know what is wrong or if I've missed anything?
> Thanks a lot for your help.

your point 5 and 6 sound like the fragments you feed to av_parser_parse() are
not valid h.263 this is very common, go and read the rtp-h263 RFC again
also dont forget that the fragments are split at _bits_ not bytes while
avparsers dont allow such madness, libavcodec supports h263 not
rtp-bastarized-h263 you must remove all rtp trash before passing the fragments
into any lavc functions

also this was disscussed at leas 500 times on this list already, everyone
has problems with removing the rtp trash not only with h263 but other
rtp bastardizations of codecs too, people think the payload of h263-rtp
would be valid h263, no, it is NOT you at least have to merge the bits of
the first and last bytes, maybe more, i dunno

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070715/52c6e151/attachment.pgp>

More information about the ffmpeg-devel mailing list