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

Sergio Fadda superatropo
Tue Jul 17 12:45:43 CEST 2007


Ok, now it works. The problem was I've handled payload header following
RTP-H.263 RFC, but I've to handle H.263+ stream, thus I've found the RFC
4629 instead of RFC 2190!
Thanks a lot and sorry for this stupid mistake :P

2007/7/15, Michael Niedermayer <michaelni at gmx.at>:
>
> Hi
>
> 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?
>
> yes
>
>
> > 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
>




More information about the ffmpeg-devel mailing list