[x264-devel] x264 documentation

[rupert.mish]

Hi all,

I am new to this forum. I'd like to know if x264 has an API that might allow custom implementions of different parts of the encoder (for example a different entropy encoder or prediction scheme). I'd really appreciate if I could get any help with any existing documentation or just a few pointers to where I might want to look.

Thanks,
- Rupert

[Loren Merritt]

Post by rupert.mish
I'd like to know if x264 has an API that might allow custom
implementions of different parts of the encoder (for example a
different entropy encoder or prediction scheme).

API? No. You might be able to do so by modifying x264, but that was not a
design goal. For example, the arithemetic coder backend is modular enough
that you could replace it with a range coder or the like, but if you want
to change the selection of contexts that's a lot more work. Motion
prediction is pretty hard-coded.
Furthermore, as x264 is only an encoder, you'd have to modify some other
h264 decoder to support whatever non-standard-compliant feature you add,
which could be much duplication of work.

Post by rupert.mish
I'd really appreciate if I could get any help with any existing
documentation or just a few pointers to where I might want to look.

--Loren Merritt

[rupert.mish]

And the motion prediction code is in predict.c? It seems that prediction is done on 16x16,8x8 and 4x4 blocks since all 3 functions are called. At what is it determined that which one will be used?

Thanks,
- Rupert
-------------- Original message ----------------------
From: Loren Merritt <lorenm at u.washington.edu>

Post by Loren Merritt

Post by rupert.mish
I'd like to know if x264 has an API that might allow custom
implementions of different parts of the encoder (for example a
different entropy encoder or prediction scheme).

API? No. You might be able to do so by modifying x264, but that was not a
design goal. For example, the arithemetic coder backend is modular enough
that you could replace it with a range coder or the like, but if you want
to change the selection of contexts that's a lot more work. Motion
prediction is pretty hard-coded.
Furthermore, as x264 is only an encoder, you'd have to modify some other
h264 decoder to support whatever non-standard-compliant feature you add,
which could be much duplication of work.

Post by rupert.mish
I'd really appreciate if I could get any help with any existing
documentation or just a few pointers to where I might want to look.

--Loren Merritt
--
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html

[Loren Merritt]

Post by rupert.mish
And the motion prediction code is in predict.c? It seems that prediction
is done on 16x16,8x8 and 4x4 blocks since all 3 functions are called. At
what is it determined that which one will be used?

predict.c is intra prediction, not motion. Yes, you could modify that.
The decision of which intra prediction to use happens in
encoder/analyse.c:x264_mb_analyse_intra(). The decision will still work
with modified prediction methods, as long as you remove
pixf->intra_satd_x3* and pixf->intra_sa8d_x3*, which are optimizations
specific to the h264 versions. (just removing the initializions from
common/pixel.c is enough).

--Loren Merritt

[Son Minh Tran]

Dear all,
I would like to know more about the option -b-pyramid. As I understand,
it makes available the new feature of h264: frame B can be also used as
reference frame. But whenever I use this option, the coded results
(according to the verbose information written out on the console)
contain no more B frames? Why does it happen this way? Is it a bug of
writting out the information or a quick implementation of reference B
frames (can be considered as P frames)
Thank you for your clarification
Son TRAN

[Guillaume POIRIER]

Hi,

Post by Son Minh Tran
Dear all,
I would like to know more about the option -b-pyramid. As I understand,
it makes available the new feature of h264: frame B can be also used as
reference frame. But whenever I use this option, the coded results
(according to the verbose information written out on the console)
contain no more B frames? Why does it happen this way? Is it a bug of
writting out the information or a quick implementation of reference B
frames (can be considered as P frames)
Thank you for your clarification

I assume that you also need to set --bframes to smth >= 0 (there's 0
per default).


Guillaume (who's happy that he recently got his code merged ^^ )

[Son Minh Tran]

Hi,
Thank you for the hint. I made a double check already. Maybe I replaced
the --bframe N with --b-pyramid then I got only I and P frames. I must
use these two arguments at the same times
Sorry for the false alarm :-)
Thank you once more time
Son TRAN

Post by Guillaume POIRIER
Hi,

Post by Son Minh Tran
Dear all,
I would like to know more about the option -b-pyramid. As I understand,
it makes available the new feature of h264: frame B can be also used as
reference frame. But whenever I use this option, the coded results
(according to the verbose information written out on the console)
contain no more B frames? Why does it happen this way? Is it a bug of
writting out the information or a quick implementation of reference B
frames (can be considered as P frames)
Thank you for your clarification

I assume that you also need to set --bframes to smth >= 0 (there's 0
per default).
Guillaume (who's happy that he recently got his code merged ^^ )