Hello Matthias, Thank you for this update.
>>I would like to ask about the H.263+ implementation in wengophone that >>should be compliant to RFC >>2429 - Why is it signaled as H263 in the SDP and not as H263-1998 like >>proposed in RFC 3555? Why >>is the rtp payload type used 34, which should be H.263 (without +), and >>not dynamically negotiated >>in the 96+ range (RFC 3551) ? This could be the reason for the >>incompatibility problems faced with >>other H.263 clients. Unfortunately also for H.263+/RFC 2429 no >>wireshark/ethereal dissector exists >>yet. We're going to look into this to try and solve the interop issue Jérôme -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Matthias Schneider Envoyé : dimanche 30 juillet 2006 02:14 À : [email protected] Objet : [Wengophone-devel] Update on work on H.264 codec integration Hi all, having some time working on the H.264 codec I would like to send you an updagte on the current status. Right now I have a working proof of conceptimplementation that encodes H.264 video, generates the H.264/RFC 3984 RTP payload + markbit + timestamp, passes these directly to a deencap routine and decodes the resulting reassembled NALs. I rely on x264 for encoding, ffmpeg for decoding and code from the mpeg4ip project for the RFC 3984 encap and decap. The RFC 3984 encapsulation and deencapsulation supports the following NALs: Single Time Aggregation Packets A (stap A) Single NAL Unit Packets (snup) Fragmentation Units (fu) I have made tests with different MTU sizes, the fragmentation stuff seems to work quite well. Furthermore I have been working on an wireshark/ethereal dissector for RFC 3984/H.264 that already should be able to decode all the RFC 3984 stuff (tested with stap As, snups and fus) and partially some H.264 NALs (PIC & SEQ params up to now, however there is still work in progress to get at least the most common NALs into it). I also plan to integrate the dynamic payload support, which until now I wasnt able to see since I do not have a an implementation yet that does H.264 signaling. In case anyone has access to H.264/RFC3984 wireshark/ethereal tracefiles I would welcome any input to test my dissector. I would like to ask about the H.263+ implementation in wengophone that should be compliant to RFC 2429 - Why is it signaled as H263 in the SDP and not as H263-1998 like proposed in RFC 3555? Why is the rtp payload type used 34, which should be H.263 (without +), and not dynamically negotiated in the 96+ range (RFC 3551) ? This could be the reason for the incompatibility problems faced with other H.263 clients. Unfortunately also for H.263+/RFC 2429 no wireshark/ethereal dissector exists yet. Right now I am digging into the development of a video codec plugin system, in one of the following days I will post another message with more specific information. Matthias ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
