Hello Matthias,

Great work so far!

I agree on the fact that encap and deencap are necessary. Nevertheless, from
what I remember in ffmpeg, you need to decode a whole frame.

If the encoded frame is split into N chunks, you get N deencap for 1 decode.
On the encoding side, when you encode 1 frame, you get N encaps

That may lead to a modification of your API where I don't see the slicing
aspect that we have now in phapi and that is necessary to fall below the
1000-1400 MTU limit on most backbone routers in UDP.

Currently, we're missing the whole encap/deencap in phmedia-video + as you
have seen in the commited code we have a mixed H263+ encoder versus H263
decoder ; I have some uncommitted code that hacks everything into H263 and
adds a fixed RFC2190 encap ; I could commit that on the trunk since it is
better than what we have now (and should fix the eyebeam interop problem)

Keep us posted !
Jérôme

-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Matthias
Schneider
Envoyé : mercredi 9 août 2006 15:16
À : Vadim Lebedev
Cc : wengophone-devel
Objet : Re: [Wengophone-devel] Update on work on H.264 codec integration

Hello Vadim,

ffmpeg does feature only an H.264 decoder, although it includes a wrapper to
use x264 for
encoding. However I did not see the use of adding another wrapper, so I
decided to use x264
directly.
Actually it was planned to feature a decoder in x264 as well, however (up to
now) that task was
never completed, so the combo x264 for encoding and ffmpeg for decoding is
the only workable
combination right now.

About the plugin system, of course I will not intend to reinvent the wheel -
however I think that
video codec plugins have to contain more functionality ( and thus a bigger
interface) than the
audio codec plugins used up to now.
Right now a phapi audio codec plugin offers the following functions:

encoder_init
encoder
encoder_cleanup

The same is to be said about the decoder.

I think the functionality for a "complete" video plugin may be divided into
the following:
- encoding/decoding
- encapsulation and deencapsulation for RTP payload
- logging 
- configuration management
- codec specific SDP negotiation 

The following is the functionality that I have partly implemented in my
proof of concept code,
ordered by functional group: 

- encoding/decoding + encapsulation and deencapsulation for RTP payload
    typedef void (frameCallback) (frame_t* decoded_frame, void* priv);
    bool deencap_and_decode (void* context, uint8_t* payload, uint32_t
payload_len, uint64_t
timestamp, bool mbit);
    void* create_decoder ();
    int init_decoder (void* context, const char *media_fmt);
    void reg_decoder_frame_callback(void* context, frameCallback* frameCbk,
void* priv);

    typedef void (rtpCallback) (uint8_t* payload, uint16_t payload_len,
u_int64_t rtpTimestamp,
int mbit, void* priv);
    bool encode_and_encap (void* context, frame_t* frame);
    void* create_encoder();
    int init_encoder(void* context);
    void reg_encoder_rtp_callback(void* context, rtpCallback* rtpCbk, void*
priv);

- logging 
    typedef void (logCallback) (char* message, int severity, void* priv);
    void reg_decoder_log_callback(void* context, int level, logCallback*
logCbk, void* priv);
    void reg_encoder_log_callback(void* context, int level, logCallback*
logCbk, void* priv);

-configuration management
    void config_dec_get_first(void* context, char** key, void** value, int*
type, char** name,
char** description);
    void config_dec_get_next(void* context, char** key, void** value, int*
type, char** name,
char** description);
    int config_dec_set_value(void* context, char* key, void* value);
    void config_dec_set_preset (void* context, uint8_t preset)
    void config_dec_get_preset (void* context, uint8_t preset)
    int config_dec_get_preset_list (void* context, preset_description_list)

-> same for encoder
- SDP stuff
    I havent dealt with that stuff yet, in case of H.264 it has to deal with
parameter
negotiation, (fixed or dynamic RTP payload,mime identifier,
packetization-mode,profile-level-id,
spropo-parameters, etc)
 

As you can see the RTP encap and deencap has to be integrated in the plugin
since it depends on
the specific codec and RFCs. Right now I am working with a RTP and
frameready callback
archictecture which should fit into wengophone nicely, however I am not sure
yet whether this is
the most elegent way to do it.
I have addded a logmessage callback that pipes my encap/deencap logging
inforamation as well as
the x264 and ffmpeg logging information to the application.
My idea about the configration stuff is the following: each encoder and
decoder has a
(varibale-length) list of configurable parameters. This list can be made
accessible in some kind
of advanced confiuration panel. Applications can get the entire list with
getfirst and getnext as
well as set and get the value of a specific key.
Addionally, kind of simple setting, each plugin may offer presets (e.g.
128kbit, 256 kbit) that
configures the same parameter in some pre-determined, optimized way. (like
the stuff in
phmedia-video-bwcontrol.c)

On the SDP stuff I have not yet really worked on.
Please feel free to comment, my implmementation features everything except
the presets and SDP
stuff until now. My next steps would be a cleanup, check windows
compatibility, imlement the
presets. I have also started putting together a wengo-H.263 plugin that will
provide backward
compatibility to the non-standard H.263+ fragmentation and includes all the
code I would like to
kick out of phapi.

Thats all for now, 
Matthias

--- Vadim Lebedev <[EMAIL PROTECTED]> schrieb:

> 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
> 
> 
> 



        

        
                
___________________________________________________________ 
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

Reply via email to