Matthias Schneider wrote:
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
Hi Mattias,
Very impressive!!!!
I thought however that ffmpeg has h264 encoder too, so why you decided
not to use it?
Btw, phapi does have a codec plugin system already, (used for G729 fro
example) so why do you think it is necessary to develop
a separate one for video codecs?
Thanks
Vadim
_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
