Hi there !
I am interested in Dirac video codec. I would like to help, but I don't know what I could do...
I have some experience in H.264 encoding, MPEG-2 decoding, and C programming especially for embedded systems.
I can help or development, or for algorithmic research, if you want to make a better codec.
Well, my message is here, I hope I will be helpful.
PS: Sorry if my english is not very good...
If you're coming from the video coding angle, then I think improving the encoder speed and performance would be good. The big thing is the motion estimator - we've put quite a lot of work into getting a reasonable algorithm, but it's still quite slow and doesn't perform so well at low bit rates.
One idea I've been mulling on is adapting the motion estimator from the x264 implementation to work with Dirac, because that seems to be much faster and hold on much better at low bit rates. That would mean changing from fixed block sizes to variable sizes and overlapping blocks but the basic search algorithm should go through fine. Dirac has far fewer block modes to search so that would be simpler.
Another thing is global motion estimation. I need to finalise this in the specification, but we need to have a good estimator, maybe from a pixel-by-pixel motion field. We have a branch in the code which does global motion estimation from the block motion vectors, but it doesn't work very well.
Then there's improving the choice of quantiser in the wavelet coefficient coding. We don't have a good implementation for multi-quantiser coding of code blocks (we split the subbands up into code blocks and you can either have a single quantiser for all the blocks in a band, or one for each block).
what do you think?
Well, I think that is interesting :).
I will have a look at how Dirac does its motion estimation. I think I can already hand shaking, that sounds really good to me.
Ok, I have read the Dirac specifications.
It seems to be "on work" (I don't know how to tell it :) ) ?
Is it possible to extract the good and bad points in Dirac and H.264 Inter pictures coding ?
I think that variable size blocks would be a good point, in order to improve the performance, but I am a newbie with Dirac for the moment ;).
There's now a new version of the spec: http://dirac.sourceforge.net/specification.html. It's pretty final i.e. it needs proof-reading for mistakes and a small amount of stuff added like levels and profiles, and then that's it.
We do support variable-size blocks for motion compensation. You can set pretty much any sane block size at the encoder command-line.
At for H264 inter coding versus Dirac: well you can use more different prediction frames with H264 and it has more block modes; Dirac is quite a bit simpler, easier to implement and has completely variable block sizes, unlike h264.
The link is broken because of the extra dot.
What needs to be done to the software to conform to the specs?
Not very much at all I think. Dave Schleef is cross-testing against Schrodinger, and he'll be flagging bugs, but I'm expecting it to be minor stuff, e.g.:
- He's flagged an issues about byte-alignment already: in the spec we don't byte align after zero-length subbands, and in the software we do.
-The wavelet filter indexes have changed in the spec and we need to include the Fidelity filter in Dirac
- We need to support global motion decoding (as does Schrodinger)
I hope to go through over the next few weeks verifying the code "by eye" against the spec, as I de-bug it.
Apart from that, we'll be adding stuff to the spec for Dirac Pro tools like VLC-only coding. There should be minimal impact on the main Dirac system, but the diracpro module will need substantial work to conform, and we don't yet know whether it will be merged into the Dirac module.
I have a problem to embed the dirac in openphone (softphone).i dont know how to start?i will appreciate if u would help me.
I need dirac video codec plugin bcuz in openphone the video codec embedding process is via video codec plugin. if any1 have info. regarding the DIRAC video codec plugin plz inform me.
waiting for good rply.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.