Dirac VFW codec?

[Sirber]

Is there one avalible? I looked on their site and only found a DShow splitter :confused:

[Doom9]

Nope. It's on the todo list afaik but not a high priority feature. Imho, a cli encoder would suffice.. it just has to support AviSynth / AVI input and write to some usable format.

I noted that the latest videolan can encode and decode Dirac.

[unskinnyboy]

So I take it we can't encode with Dirac at all currently since there is no CLI or VfW encoders available?

[Doom9]

oh yes you can.. videloan ;) and there's of course a commandline encoder.. but if you read the manual you're ready to shoot yourself.. that cli app is really of no use.. it takes weird input formats that mean you have to decode your source frame by frame into something you're never going to use other than for dirac, and the output is also not directly playable.

[Tommy Carrot]

These utils (http://carrotland.uw.hu/yuvutils.7z) might be helpful for the testing, with them you can convert .avi files to .yuv (input for diracencoder) and you can convert the outputted .yuv back to uncompressed .avi (but don't be surprised, you'll need to have huge storage space for this method of testing).

Imo dirac doesn't worth the time right now, it's still slow (although improved a lot since the earlier versions) and the quality is subpar. The only reason it's so interesting because the specs suggest quite a big potential (theoretically it should be able to surpass Snow, for example), but if the development is continuing at this pace, it will take years before it'll become useful.

[unskinnyboy]

oh yes you can.. videloan ;) and there's of course a commandline encoder.. but if you read the manual you're ready to shoot yourself.. that cli app is really of no use.. it takes weird input formats that mean you have to decode your source frame by frame into something you're never going to use other than for dirac, and the output is also not directly playable.
My bad. Yes, you did mention Videolan in your 2nd post. Thanks, will give it a look.

[Doom9]

These utils might be helpful for the testing, with them you can convert .avi files to .yuv Well.. diracencoder should at least support yuv streams via stdin.. that way we could use avs2yuv. Not so long ago, that was needed to properly encode x264.

[Sirber]

Nope. It's on the todo list afaik but not a high priority feature. Imho, a cli encoder would suffice.. it just has to support AviSynth / AVI input and write to some usable format.

I noted that the latest videolan can encode and decode Dirac.
That could do it. And implement it like I did for x264 :)

[superdump]

The nightlies available from http://www.videolan.org/~videolan don't appear to contain dirac. Can someone give us a link to a videolan binary that does include dirac? I've tried to compile it myself using mingw + msys but it's proving difficult.

[easyfab]

@superdump

I compile vlc +dirac -> http://rapidshare.de/files/3034595/vlc-0.8.4-svn_dirac.7z.html

just use vcodec=drac instead of other codec in the "destination target"
Like this for exemple : :sout=#transcode{vcodec=drac}:duplicate{dst=std{access=file,mux=ogg,url="01.ogm"}}

Caution dirac codec is very slow to encode for the moment

Have fun with it

[Mr C]

Hey,

first of all, I'm not really an expert in video encoding, but I'm trying my best. Currently I'm experimenting with a couple of open source codecs.

I have a few (basic) questions about Dirac. After a day I managed to compile the source code on my windows machine :) I converted an avi file to yuv and used the dirac_encoder to encode it. So far so good... (although it took 20 minutes to encode a 720x486 30fps video of 100 frames) but I get 3 files:
.yuv
.imt
.drc
Can anyone explain where these files come from? I suppose the drc file is the compressed one? I have decoded the drc file back with the dirac_decoder an I've played the generated yuv file, but it's cr*p. The video is green and I hardly recognize the original movie.

Here the parameters I used:
dirac_encoder -verbose -x 720 -y 486 -qf 5 -start 5 -stop 105 original dirac
Anyone a tip or a 'how do you en/de-code with dirac' guide for beginners? After 3 days of google and reading the forum, I just couldn't find the right way to encode. :(

Thx in advance

[Tommy Carrot]

Well, i used those tools i linked in this thread, the usage is very easy, with avitoyuv, you can convert avi files to yuv, and with yuvtoavi, you can convert the output of dirac to lossless avi. Imo this is the most simple way to check the quality. There are other tools as well to convert and decode yuvs, like avs2yuv (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/) (usage example: avs2yuv -raw -seek 50 x.avs y.yuv), and afaik ffmpeg is also able to process yuv files.

Don't expect too much from dirac, it's still has a long way to go to catch the popular codecs, and -qf 5 gives very bad quality anyway. I suggest that don't go under -qf 7 or 8 if you want to get watchable quality.

[Mr C]

Thanks Tommy,
I've already used those tools you linked here to convert my avi to yuv. I noticed the avitoyuv also supports avisynth scripts as input. Maybe my expectations about Dirac were a little bit to high after I encoded with Snow :p . Anyway, could you tell me more about the 3 files that are generated? You said:
with yuvtoavi, you can convert the output of dirac to lossless avi So the compressed file is the file with the yuv extension? Or am I going the wrong way here :)

I think I'll skip dirac and move to the next codec, let's say theora...

Greetz

[Tommy Carrot]

The compressed file is .drc, but playing it back directly is not possible. The yuv file is the decoded output, the content of it should be identical to the .drc file, so this is the only way to check the quality. Currently Dirac is only good for testing, but otherwise it has no practical use, you cannot compress movies with it.

Theora is definitely more usable, if you care about royalty-freeness, it's the best choice, but if you don't, xvid and x264 is the way to go. :p

[S_O]

Well.. diracencoder should at least support yuv streams via stdin.. that way we could use avs2yuv. Not so long ago, that was needed to properly encode x264.It took me less than 30 minutes to merge avs2yuv source with xvid_encraw (I couldn´t get stdin stuff working) to get a useable xvid cli encoder, and my programming abilities are very limited.
If Dirac supports the normal yv12 / yuv2 format avisynth outputs it should be quite easy to add avisynth support.

[Doom9]

S_O: have you submitted those changes for inclusion in the CVS? I've long been looking at encraw as a potential replacement for mencoder when it comes to XviD encoding (adding the missing features seems much more straightforward in encraw).

[S_O]

S_O: have you submitted those changes for inclusion in the CVS? I've long been looking at encraw as a potential replacement for mencoder when it comes to XviD encoding (adding the missing features seems much more straightforward in encraw).No, but I still have the source somewhere on my HD, I´ll have a look at it, maybe clean it up, and then I´ll post it in the XviD forum.

[ak]

The compressed file is .drc, but playing it back directly is not possible.
How come? I'm pretty sure at least mplayer/ffplay (with patches from dirac sf.net page) can play it.

[celtic_druid]

There is definatly a dirac patch for mplayer. Also presumably Gabest's filter should work if it is linked with a current dirac lib.

[Mr C]

This night I ran the following script on a 780 frames long, 29.97 fps (approx. 26 sec) video fragment with a size of 720x486, file size 399Mb :dirac_encoder -verbose -qf 9 -fr 29.97 original diracI started the encoding at 5h30 PM en it ended at 1h30 AM, so that's 6 hours of encoding for not even 30 seconds of video. This resulted in the following files:
dirac.drc (93Mb)
dirac.imt (117Mb)
dirac.yuv (399Mb)
Is this normal? By now, I know the dirac codec is way from optimal, but even for experimental purposes it seems to be awkward.

Grtz

Edit: I downloaded the mplayer patch from the sf pages, but what to do with it? I tried to patch it in windows with mingw32, but it asks for what file to patch all the time. The version of mplayer I have: MPlayer-mingw32-1.0pre7.

[celtic_druid]

patching file `MPlayer-1.0pre7/configure'
patching file `MPlayer-1.0pre7/etc/codecs.conf'
patching file `MPlayer-1.0pre7/libavcodec/snow.c'
patching file `MPlayer-1.0pre7/libmpcodecs/Makefile'
patching file `MPlayer-1.0pre7/libmpcodecs/vd.c'
patching file `MPlayer-1.0pre7/libmpcodecs/vd_dirac.c'
patching file `MPlayer-1.0pre7/libmpdemux/demux_dirac.c'
patching file `MPlayer-1.0pre7/libmpdemux/demuxer.c'
patching file `MPlayer-1.0pre7/libmpdemux/demuxer.h'
patching file `MPlayer-1.0pre7/libmpdemux/Makefile'
patching file `MPlayer-1.0pre7/libmpdemux/parse_dirac.c'
patching file `MPlayer-1.0pre7/libmpdemux/parse_dirac.h'
patching file `MPlayer-1.0pre7/libmpdemux/video.c'
patching file `MPlayer-1.0pre7/Makefile'

Works fine here.

[Mr C]

Yeah,

works fine here to. Apparently something went wrong with the tar file. The readme and the patch were melted together as one file :)

After some stupid problems with cygwin and gcc, I finally managed to compile the MPlayer with Dirac support. So let's play some dirac files with MPlayer. :rolleyes: At least I thought so... it doesn't seem to play the files at all.

Btw, the codec is way from ready ??? Check this out: http://www.newscientist.com/article.ns?id=dn7537 Private demonstrations of Dirac, given on 9 June at the BBC’s research and development labs in London, UK, show that the technology is almost ready for launch.
I'd really like to see those tests :) :) :)

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/force.php?file=./mplayer-1.0pre7.7z
Worked ok with a small clip I encoded.

http://mirror05.x264.nl/celtic_druid/force.php?file=./diracsplitter.7z
Works better. mplayer had some weird colour artifacts going on.

[Doom9]

show that the technology is almost ready for launch.At these speeds and with that amount of hassle to be played back? Yeah right.

[Sirber]

I agree on that.

[Mr C]

Thx Celtic Druid,

I tried your build. I registered the DirectSplitter.ax in the registry. Then I played the file with mplayer, but I got the following error:Assertion ^ Input Bitstream version 4 supported ^ failed in file dirac_cppparser.cpp at line 192 I have no idea where this comes from. :) Maybe you can tell me what parameters you used to play the file?

[ak]

They break compatibility with like every version of the lib or sth, ie you need encoder of same version as decoder.
BTW mplayer makes no use of DS filters.

[celtic_druid]

It can if you add them to the codec config.

Yeah, I build the filter with current cvs dirac and encoded the test sample with current cvs dirac.

[Mr C]

Any chance you can post the encoder too? So I don't have to rebuild the whole thing again? ;)

[ak]

It can if you add them to the codec config.
Sure, but you don't have register them ;)

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/force.php?file=./dirac_encoder.7z
cvs has been updated again since. Somehow I doubt it would be much different though. Anyway I can't see any point in playing with dirac at the moment.

[Sirber]

same here!

[Mr C]

Anyway I can't see any point in playing with dirac at the moment.It's for my final year project at school. I have to compare all sorts of video codecs. So if anyone has tips, you're allways welcome ;)

Btw, it's the third week of research and I love doom9. If you can't find it here, you'll never find it.

:thanks:

[Tommy Carrot]

I played around a bit with dirac, and a couple of remarks:

The latest encoder is significantly slower than the previous build from may, which is a bit surprising, considering that the devs were working on the mmx support lately, and that should greatly improve the encoding speed.

The quality is actually not so hopeless, the detail level is quite a bit better than xvid's with every feature enabled, i would say it's about on par with snow... BUT! The quality is very inconsistent, the picture is littered with strong chroma artifacts, dirac cannot cope with fast motions, and the keyframes has much lower quality than the rest of the frames, so every detail goes away with the keyframes, then the sharpness gradually comes back with the predicted frames, and all of this looks very ugly.

Well, all i can say that dirac is actually quite promising, but in it's current state it's still unusable, and i think something is wrong with the mmx optimization.


Sirber, what's wrong with you lately? Why are you trying to increase you post count so desperately with these meaningless posts? If you don't have something to say, please don't spam the board.

[easyfab]

The speed is a bit better for me with the latest cvs version.
Have you do ./configure --enable-mmx for your build ??

[Tommy Carrot]

The speed is a bit better for me with the latest cvs version.
Have you do ./configure --enable-mmx for your build ??Dunno, i used celtic druid's builds. :)

Meanwhile i finished the encoding with the new version (it only took 3.5h on a 4 min long sequence :)), and apparently the keyframe-blurring bug is fixed (it occured with the older build from may), but now every moving object leaves motion trail behind.

[celtic_druid]

Actually I didn't. Didn't even run --help to check out the options to be honest. Usually I just use MSVC and compile the --mmx project files.

Guess I should do a new compile of the encoder.

edit: everything updated. What a hassle though. Every small update means that you need a new decoder and old encodes no longer decode.

[Tommy Carrot]

I finished my little comparison test, here come some frameshots:

xvid simple profile (ok, i cheated a bit :D):
http://carrotland.uw.hu/sample_xvid.jpg

theora:
http://carrotland.uw.hu/sample_theora.jpg

dirac:
http://carrotland.uw.hu/sample_dirac.jpg

snow:
http://carrotland.uw.hu/sample_snow.jpg

x264:
http://carrotland.uw.hu/sample_x264.jpg

Of course the images don't truely represent the quality, for example they don't show the motion artifacts, but they are good indications for the texture detail. Dirac is quite good in this regard, and it has clearly a big advantage in potential over theora.

EDIT: i forgot to add that i used yesterday's build for the test, which doesn't exploit the mmx optimizations. The updated build is much faster, but it always crashes after a couple hundreds of frames.

[Mr C]

Dirac is quite good, but you use a rather slow motion scene. But as you say, it's a reference for detail. I used the test videos of VQEG, took 3 different sequences and pasted them together, as they did in the c't magazine article.

Susie (ftp://ftp.crc.ca/crc/vqeg/TestSequences/ALL_525/src21_ref__525.yuv) : slow motion scene
Football (ftp://ftp.crc.ca/crc/vqeg/TestSequences/ALL_525/src19_ref__525.yuv) : quick motion scene
Tempete (ftp://ftp.crc.ca/crc/vqeg/TestSequences/ALL_525/src22_ref__525.yuv) : slow outzooming with quick falling leaves

Some codecs are better for slow sequences, other can't work with them. IMHO x264 scores best in all cases.

Btw, you should take Snow in your comparision test. ;)

[Tommy Carrot]

Yep, dirac is better for slow scenes, but other than the extremely fast scenes (where the image falls apart into funny colorful blobs), it does its job correctly. And i agree, x264 is the best, but this picture clearly illustrates my main beef with it: overally it retains details quite well, but the deblocking filter damages the finer details (and unfortunately x264 without deblocking is a blockfest). Wavelet codecs don't have this problem.

I added snow screenshot, it looks very similar to dirac, although snow looks better during playback. :)

[Sirber]

Snow seems cool!

[Mr C]

I attached a little result of my tests. I measured the quality with MSU Video Quality Measure Version 0.73 Beta. Only the results for the Structural Similarity Index are included here. In case you never heard of it, higher is better ;).

Seems like Dirac is the best, but has serieus artefacts. x264 dissapoints me for fast moving objects, but it's very stable for slow motions.

Slow sequence: (girl on the phone) frame 0-240
Fast sequence: (american football) frame 240-500
Mixed sequence: (falling leaves) frame 500-780

Any comments anyone?

PS: I'm still working on the results of Theora.

[Tommy Carrot]

Here is another meaningless comparison, this time at ridiculously low bitrates (the reference was xvid at quant 31):

xvid:
http://carrotland.uw.hu/lq_xvid.jpg
snow:
http://carrotland.uw.hu/lq_snow.jpg
x264:
http://carrotland.uw.hu/lq_x264.jpg
dirac:
http://carrotland.uw.hu/lq_dirac.jpg

Dirac has the best detail level at very low bitrates, but unfortunately the overall quality is not as good as this frame suggests, because sometimes, expecially at fast motion scenes, _extremely_ strong artifacts appear on the image, and as i said, the objects leave motion trails behind. But i have to say i'm very impressed, if the developers will be able to fix these instabilities, dirac can definitely be a serious contender in the video encoding scene.

[Sirber]

Pretty impressive! I wonder how it goes on anime...

[Doom9]

because sometimes, expecially at fast motion scenes, _extremely_ strong artifacts appear on the image, kinda kills the point of even trying, doesn't it?

[Sirber]

kinda kills the point of even trying, doesn't it?
Well, if no one tries, we'll never know :)

[Tommy Carrot]

kinda kills the point of even trying, doesn't it?The artifacts are probably caused by bugs, thus this problem is fixable, i think. Don't get me wrong, dirac is still very far from being usable as an archiving codec, but this is the first time that it actually impressed me, so at least there is some progression (which i cannot say about snow), and bugs and issues notwithstanding, it seems to be a very powerful codec.

[Doom9]

well.. 300 kbit is insanely low, and paired with insanely slow and buggy, I very much doubt Dirac would even make my comparison pre-test.
BTW, PNG rules for screenshots of video.. no compression artifacts introduced by JPEG ;)

[Tommy Carrot]

PNG rules, but i don't want to generate too much traffic, or the bastards would delete everything from my webspace again. :D The quality degradation is negligible from the jpeg conversion, it doesn't change the overall picture.

And yeah, i agree it's too early for serious comparison tests, i just like to play around with unusable, but interesting things. And actually it's 190 kbps. :D (higher quality screenshots from 950 kbps videos are in the previous page).

[IgorC]

http://mirror05.x264.nl/celtic_druid/force.php?file=./dirac_encoder.7z
c.

It accepts as input only yuv. Is it possible to encode via avisynth ?
avs2yuv output is buged

[PatchWorKs]

Hey guyz, just a question: why dirac is not in ffdshow/ffvfw ?
Licensing problems ?

[Shirokuu]

Hey guyz, just a question: why dirac is not in ffdshow/ffvfw ?
Licensing problems ?
FFDSHOW is currently not (yet) able to decode videofiles encoded with the dirac codec because libavcodec doesn't support it yet. There are patches for the FFMPEG project that allow coding/decoding of dirac videostreams though. But i don't know if you can include them in the FFDSHOW compiled binary.

[celtic_druid]

Well in ffdshow's case it would probably be better to have a seperate ff_dirac plugin.

edit: did a ffmpeg dirac compile. dirac in avi plays back quite well via mplayer.
http://mirror05.x264.nl/celtic_druid/force.php?file=./ffmpeg-0.4.9-pre1-dirac.7z

[dirac]

I am a Dirac developer and it certainly has been informative to read all your comments. It will be great if the comments/bugs can be submitted to the Dirac forums/bug tracker on Sourceforge as well. We monitor them regularly and try to respond as quickly as possible, I did notice that some comments posted here have made it to the Open Discussion forum. We are testing Dirac with material of different resolutions and formats. Quite a few people in this forum have complained about Dirac's quality in fast moving sequences.Can you give me more info regarding the resolution, chroma format and the type of material used (interlaced or progressive). It will help us debug the problem. It will also be helpful if the material you used for testing can be made available to us.

[Tommy Carrot]

Sure. Here is a short sample (http://carrotland.uw.hu/test1.drc) (and the source (http://carrotland.uw.hu/fastscene_xvid.avi) for it) which shows the problem quite clearly: the image falls apart into rainbow-colored blocks, and the artifacts remain there until the next keyframe.

The other bigger problem with dirac is the motion trails. The moving objects leave trails behind, it almost looks like motion blur. Example here (http://carrotland.uw.hu/trails.drc). I used low quality setting (-qf 4) to illustrate the problem better, but it is noticable even at higher bitrates, just less so.

I used the august 12 build (http://www.aziendeassociate.it/./cd//dirac/dirac2005.08.12.7z) for encoding, which is not the latest, but still quite recent, so these issues are most probably valid for the cvs version as well.

[dirac]

August 12 was the date I modified the motion estimation to get rid of problems like this. If libdirac_common/motion.cpp has version earlier than 1.16 then it won't have this fix. Basically I tweaked the ME to stop it trying to 'glue' motion vectors of adjacent blocks together too much, which it does to save bit rate.

Thomas

[celtic_druid]

Fairly good chance that it was before the change. Probably about 5:15pm local time when I updated before compiling.

I'll see about putting up some new binaries tonight.

[dirac]

I've just tried with the latest CVS version, and encode parameters

dirac_encoder -qf 4.75 -SD576 -width 720 -height 288 fastscene_xvid fastscene_out

This gave the same filesize. The artefacts seem to me to be reduced. There's still blocking on the fast motion, but it doesn't hang around and is less severe.

It's probably the case that the motion estimator can't track motion that fast, so it's using intra blocks (which is the only time Dirac gets blocky). Probably fixable eventually.

T.

[Sharktooth]

Had problems with the SF CVS (as usual) so i built the 0.5.3 dated 2005.08.23:
http://www.webalice.it/f.corriga/dirac/Dirac0.5.3_20050823.7z

[celtic_druid]

Don't think there have been any updates since then. At least there weren't any changes when I just did a checkout. So I guess no need for me to compile a binary.

[Tommy Carrot]

I've just tried with the latest CVS version, and encode parameters

dirac_encoder -qf 4.75 -SD576 -width 720 -height 288 fastscene_xvid fastscene_out

This gave the same filesize. The artefacts seem to me to be reduced. There's still blocking on the fast motion, but it doesn't hang around and is less severe.
I'm using -CIF preset in my tests, because -SD576 places the keyframes too frequently for my liking, this might explain why the artifacts disappeared earlier in your test. I played around with the new build, and the fast-motion blocking is not really improved from my earlier try, but at least the motion trail artifacts seem to be toned down significantly (although not completely disappeared) in the new version.

[dirac]

You can increase the key frame interval directly by setting the number of L1 frames. For example, doing

-num_L1 11

will give you the same key frame separation (36 frames) as for the CIF preset.

I think the psychovisual weighting with -SD576 will probably be slightly better for this size picture than -CIF.

[Tommy Carrot]

Thx, i will try it. BTW, i don't know if you're aware of this issue, but diracencoder often crashes with this error message:
Compressing frame 3682, 3684 in display orderGetEncodedData failed...
Invalid state. Unrecoverable Encoder Error. Quitting...
This was my luckiest try, the crash usually occurs after a couple hundreds of frames. Not long ago Celtic Druid made a build which had disabled mmx optimization, and while it was much slower, i never experienced crashes with it, so i think that one of the mmx optimized functions might be the culprit.

[dirac]

I will look into this next week. I found that MS Windows is more stringent with unintialised memory reads than *Nix* platforms and maybe this is causing problems. The encoder does not crash on any other platform I tested. Are they coding params the same as before - i.e. 720x288, -CIF preset and Planar yuv 4:2:0 chroma?

[Tommy Carrot]

Yep, and it happens with -SD576 preset too. It seems to happen randomly, one time after ~200 frames, other time after a few thousand, probably depending on the settings.

[Sharktooth]

ill wait for a CVS update to compile both MMX and non-MMX versions.

[Sharktooth]

Finally i could access to SF CVS...
here are the new builds:
*outdated*

[guada2]

Hello :)

I noted that interfaces or GUI make the deals of everyone.
Some times ago Damrod had started with Windirac?

It is for when the GUI of Dirac encoder?

[FireArse]

Hey there,

Just wanted to know how Dirac compares with HD resoltuions? Does encoding 1080 mean a HUGE encoding time?

Thanks,

FireArse

[Shirokuu]

@FireArse

I tested encoding a few lines less than 1080p with the Dirac codec on a 250 frame sequence to compare quality. The encoding time is HUGE, as you have already guessed. But then again the developer posted here that speed optimizations are not yet in question. First there is still a lot of work left on the Dirac encoding algorithm. If that's finished then there should be time left to do code optimisations. (BTW, this would be a nice rolecall for all people who want to help optimizing the code to incorporate MMX and SSE2 calls).

[Doom9]

It is for when the GUI of Dirac encoder?Without being able to frameserve into the encoder (correct me if I'm wrong.. stdin YUV input would already help quite a bit), and without tools to put the encoded stream in a container (once again, correct me if I'm wrong), I think a GUI is really premature at this point.

[dirac]

Actually, I'm just playing with a prototype encoder GUI at the moment. It uses QT so can be compiled on all platforms, if you have QT installed. It just calls the command line tool.

It's helpful mainly because it organises the encoder options more logically and makes it clear what the presets do.

We should be able to get it out in a few weeks if testing goes well.

Thomas

[Doom9]

It just calls the command line tool. then why is qt required? are there any plans on the muxing front?

[Sirber]

then why is qt required?Isn't QT like GTK?

[Doom9]

ahh, THAT QT - that would certainly make more sense than the QT I was thinking of.

[Sirber]

lol!!!, if I think about the QT you were thinking about :D

[hellfred]

lol!!!, if I think about the QT you were thinking about :D
What about using Qt und QT to avoid those missunderstandings?

Hellfred

[Sirber]

Well, I will say QT is the general QT while Qt is the other specefic one?

[celtic_druid]

Encoding with ffmpeg works reasonbly easily. I created an avi containing dirac and it played back fine with mplayer.

[Doom9]

there's no avisynth input patch for ffmpeg, is there? does it at least accept yuv from stdin?

[PatchWorKs]

Encoding with ffmpeg works reasonbly easily. I created an avi containing dirac and it played back fine with mplayer.
Any chance to have a dirac-enabled ffdshow/ffvfw build ?

[celtic_druid]

avs2yuv should work fine. Still even without that the number of supported input formats is still far better than the regular cl encoder.

Ask Milan.

[dirac]

does it at least accept yuv from stdin?

Not at the moment, but we'll try to do that soon. We're in the middle of preparing for a major exhibition so it's down the list of priorities but it shouldn't be hard to do at all.

Thomas

[guada2]

Doom9, celtic_druid, dirac..

Thank you very much for these precise details.
To soon.

[Sharktooth]

New builds:
*outdated*

[Tommy Carrot]

Thx man, i appreciate your (and Celtic Druid's) builds.

I tried lossless mode in the new build. As far as i could check it, it works correctly. In my limited tests, the efficiency seems to be around huffyuv's level, and considering that lossless mode is a very recent addition, this is not bad at all, and i'm sure it can be improved later.

[Sharktooth]

did you tried even the MMX build? if yes, did it work correctly?

[Tommy Carrot]

I tried, but it still crashes after a couple hundred of frames. But this is not surprising, the mmx routines have not yet been revised since the last build.

[AlexeyS]

Could somebody share 720x400 (or 720x288, 720x304 etc) sample video encoded with dirac at 450, 800 Kbits?

[dirac]

We are currently preparing for an exhibition so fixing the mmx routines has taken a back seat for the moment. We hope to fix this soon.

[AlexeyS]

Is there some tool to make YUV or RGB file from simple AVI?

[hellfred]

Is there some tool to make YUV or RGB file from simple AVI?
Install AviSynth and write a script that:
*loads the file with AVISource
*converts it to the desired colorspace

E.G.
AVISource("C:\Path\To\file.avi").convertToYUY2()
or
DirectShowSource("C:\Path\To\file.avi").ConvertToRGB()

See the documentation that comes with AviSynth.

Get avs2yuv to convert to yuv, or load the file to VirtualDubMod, choose Direct Stream Copy and save the file. Now you have another avi with raw video data. You can get the raw video stream by demuxing it.

Hellfred

[AlexeyS]

hellfred
Thanks a lot. It works.

How can I play file? I've downloaded latest Mplayer and VLC - they are not play .drc files. Maybe there are some special builds? BTW, half of links posted in this topic are broken.

[celtic_druid]

Mplayer has to be patched to handle Dirac. Worked fine last time I tested including decoding dirac in avi.

Then there is also Gabest's directshow filter/Media Player Classic. Also I guess ffplay.

[dirac]

Check out

http://www.ee.surrey.ac.uk/Personal/S.Worrall/dloads/
http://shannon.ece.missouri.edu/zhe/ece401.html

Tim

[Sharktooth]

The Dirac CVS server (SF) goes nutz too easy. I always have to try 3 or 4 times before having success updating...

[AlexeyS]

Mplayer has to be patched to handle Dirac. Worked fine last time I tested including decoding dirac in avi.
Could you share this patched Mplayer for windows please?

[Sharktooth]

The patch is on SF: http://prdownloads.sourceforge.net/dirac/MPlayer-1.0pre7_dirac-0.5.x.patch.tgz?download
There are also other patches and stuff: http://sourceforge.net/projects/dirac

[AlexeyS]

The patch is on SF: http://prdownloads.sourceforge.net/dirac/MPlayer-1.0pre7_dirac-0.5.x.patch.tgz?download
There are also other patches and stuff: http://sourceforge.net/projects/dirac
Can I read somewhere how to apply patch?

Also, I've foung DS filter at second link. Tried to Regsvr32 it, but get error (Windows XP). Are there DS filter for XP?

[celtic_druid]

I posted a patched mplayer build earlier. Just do a new build though which I will put up.
Old one is here: http://mirror05.x264.nl/celtic_druid/force.php?file=./mplayer-1.0pre7.7z there is also an older ffmpeg compile with dirac support (encoding and decoding). I will see about updating that to.

[dirac]

The Dirac CVS now has an encoder GUI. It's in directory util/encoder_gui of the compress module.

At the moment it doesn't build when you make the rest of the code - you need to read the README in that directory and follow the instructions there for building and running. You need Trolltech's Qt 4.0 library installed.

We hope to release it as a separate package soon.

Let us know what you think.

Thomas

[AlexeyS]

I posted a patched mplayer build earlier. Just do a new build though which I will put up.
Old one is here: http://mirror05.x264.nl/celtic_druid/force.php?file=./mplayer-1.0pre7.7z there is also an older ffmpeg compile with dirac support (encoding and decoding). I will see about updating that to.
I'm not programmer, so I can't "make build". :)

[IgorC]

there is no need to compile
Alexey, I already explained to you how mplayer works in other forum

More simple command line is - mplayer.exe video.avi
For other settings --help or something like that.

[celtic_druid]

Errr, the link is to a binary. I already ran "make build" or rather just "make".

[FireArse]

Dirac: What's this exhibition you mentioned before? Is it open to the public?

Thanks

F

[dirac]

It's the International Broadcasting Convention in Amsterdam. It's the major European broadcasting technology conference. It has a (huge) exhibition arena, where we're demonstrating Dirac at CIF, SD and HD. We're part of the European Broadcasting Union (EBU) stand.

There's also a conference, and we're giving a talk there tomorrow to introduce Dirac to the broadcasting world.

It is open to the public, and you can register as a private individual. However it's pretty expensive, so company funding is realistically needed. It's basically an industry shindig.

Thomas

[Sharktooth]

New builds:
Dirac CVS (2005.09.09) (http://www.webalice.it/f.corriga/dirac/Dirac_CVS_20050909.7z)
Dirac MMX CVS (2005.09.09) (http://www.webalice.it/f.corriga/dirac/Dirac_CVS_20050909_mmx.7z)

[Sharktooth]

I installed Qt 4.01 (opensource) but i get an error while compiling encoder_gui: 'QtValidLicenseForGuiModule' does not name a type.
I never used Qt libs so i dont know what does it mean...

[dirac]

I installed Qt 4.01 (opensource) but i get an error while compiling encoder_gui: 'QtValidLicenseForGuiModule' does not name a type.
I never used Qt libs so i dont know what does it mean...

You need to set PATH to include the Qt /include directory and LIBPATH and LD_LIBRARY_PATH to include the Qt /lib directory. Does that help?

If not we'll look into it.

[celtic_druid]

Ok from my attempt I get:
'basename' undeclared in filesbox.cpp

edit: got it to compile with msvc, but you get a trial evaluation popup.

edit2: got it to compile with mingw
http://mirror05.x264.nl/celtic_druid/dirac/dirac_encoder_gui.7z
edit3: Doesn't seem to do much. Press done and nothing happens.

[Sharktooth]

You need to set PATH to include the Qt /include directory and LIBPATH and LD_LIBRARY_PATH to include the Qt /lib directory. Does that help?

If not we'll look into it.
Paths are already set:(

@CD: did you get the open source version of Qt?

[celtic_druid]

Yeah, then I got drunk. It still didn't help.
I think that ffmpeg is still probably the best way for encoding dirac. Numerous different input formats, plus .drc, other outputs.

[dirac]

The CVS now contains the encoder improvements I promised, which speed it up by a factor of about 2.5. This mainly comes from doing the motion estimation better.

The original MMX optimisations for motion estimation no longer apply, and this improvement is in source code only. We'll get a further speed-up from assembler.

To get the best speed, encode with -nolocal and compile using icc on Intel platforms.

I hope we can fix problems with installing the encoder GUI soon.

cheers

Thomas

[Sharktooth]

Dirac CVS 2005.09.27 (updated) (http://www.webalice.it/f.corriga/dirac/Dirac_CVS_20050927.7z) - Compiled with VS2003. 7-zip version 4.29.

I wont compile anything with ICL, so i guess CD maybe can do it if anyone wants it...

[Tommy Carrot]

Sharktooth, this new build doesn't work, the encoder needs DiracEncoder.dll, but it's not included in the package. I would very appreciate if you could add it (and DiracDecoder.dll) to the build.

Thomas, i couldn't test the new build yet, so all i could do is to read the changelogs. :) As far as i can see, there are some elements in the speed optimization that can affect the quality, like decreasing the search range in the motion estimation, or changing the default ME precision from 1/8 to 1/4 pixel. I'm sure these features were too expensive computationally, but i'm curious, do these changes cause any noticable quality degradation? I couldn't check it yet, but what is your opinion, if i want to get the maximum possible quality, does it worth to use the original settings, or the quality gain was minimal with them anyway?

[Sharktooth]

I forgot to statically link the dll :(
New build coming soon.

EDIT: It shoul be fixed. Please re-download it.

[Tommy Carrot]

Thanks, it works. :)

[dirac]

do these changes cause any noticable quality degradation?
I reckon the increase in bitrate for the same quality is 1-2% by restricting the searches in this way (on the pictures I tested anyhow), which seemed not too bad to me, given the speed-up. If you find big costs on some pictures let me know.

Thomas

[Sharktooth]

I would keep both search modes like in DivX (insane mode) and x264 (Exhaustive Search) and make them selectable as an option.

[Caroliano]

I agree with Sharktooth.

In some contents, mainly HDTV and low fps videos I think, an higher motion estimation can help a lot. And 1/8 pixel precision can be left as an option too if max quality per size is required at any cost. In an low resolution content it would help isn't?

I'm seeming that Dirac is not only self-restringing his future potential, but also worsen its own quality bit a bit even now. Use profiles if your team want to restrict things, but let an "almost unrestricted profile" for who want the full power of Dirac.

And how wide is your test videos library? There is an uncountable variety of video types: from an interview to an car chase, from an rain day to an tornado, from an Hollywood to an Dadaistic film, etc. And in what resolutions and framerates are you testing?

You is also testing with artificial things like cartoons, animes, CG, Screen captures, harsubs in a common video, etc?

[dirac]

1/8th pixel is still supported. What I changed was using 1/8th pel routines to do 1/2 pel and 1/4 pel matching which is slow and inefficient. There are now specific routines in the code for 1/2, 1/4 and 1/8th pel.

The basic search range has *not* been restricted - that's determined by the search range at the coarsest resolution in the hierarchical search pattern. What I've reduced is search ranges for the later refinement stages. So Dirac can still capture the same range of motion as it could before. The search range and number of stages of hierarchical search increase with the size of the video so there's no problem with HDTV.

[Tommy Carrot]

The encoding speed is indeed much faster than before, it's starting to reach the usable state. I did not measure it precisely, but it appears to be slightly slower than x264 with RDO enabled. The quality seems to be similar than before, except that the video is littered with annoying flashing blocks. They don't last long, so i believe this problem occurs only in the b-frames (or whatever they are called in dirac). It looks like skipped blocks went berserk, especially badly at fast motions, but it's happening everywhere. Here is a sample (http://carrotland.uw.hu/blocks.drc) that shows the problem.

[dirac]

The encoding speed is indeed much faster than before, it's starting to reach the usable state. I did not measure it precisely, but it appears to be slightly slower than x264 with RDO enabled. The quality seems to be similar than before, except that the video is littered with annoying flashing blocks. They don't last long, so i believe this problem occurs only in the b-frames (or whatever they are called in dirac). It looks like skipped blocks went berserk, especially badly at fast motions, but it's happening everywhere. Here is a sample (http://carrotland.uw.hu/blocks.drc) that shows the problem.

Ok, I'm looking into this.

Thomas

[dirac]

I've attached a patch to block_match.cpp. It slows things down a little, but I think it fixes your problem. Check it out.

Thomas

[Sharktooth]

Thomas, please check your PMs.

[Sharktooth]

here we go: http://www.webalice.it/f.corriga/dirac/Dirac_CVS_20050927+patch.7z

[Tommy Carrot]

I've attached a patch to block_match.cpp. It slows things down a little, but I think it fixes your problem. Check it out.
Indeed, the patch has fixed it. :)

[dirac]

Good. I'll check it out on some other material, and probably commit next wk.

Thomas

[Doom9]

is there any chance of having an ffmpeg build with the most recent dirac compiled in, seeing as ffmpeg is the only tool that allows you to put dirac into something workable (as in something that can contain both audio and video.. ).

[FireArse]

Thomas,

How big a challenge is multi-threading the code?
How much slower has this bug fix made the code?

Thanks

[Sharktooth]

The bugfix did not slow it too much (about 5% in my only and maybe inaccutate test).

[dirac]

Thomas,

How big a challenge is multi-threading the code?
How much slower has this bug fix made the code?

Thanks

I guess you mean the encoder specifically? That depends on the level of threading. At the simplest level, most frames have two reference frames and you can do most of the ME for each frame in different threads. I would guess that would save you 20% of the time on a two processor machine for very little effort. You could also code two GOPs independently with a bit more effort, and that would save 50%, but hit compression efficiency (because there's a load of adaptive stuff that wouldn't work so well).

Doing more than two threads and e.g. breaking pictures up into smaller parts would be quite a bit more work, but would get bigger savings in the long run. We do intend to look at the whole threading side, since getting real-time SD encoding on a 4 processor machine would be really useful.

Thomas

[FireArse]

All,

I would be interested in getting raw 1080p HDTV material for encoding & testing Dirac & other codecs - any idea where I can get various types of material - eg Anime, Water scenes & possibly high action footage?

Thanks,

Firas

[stephanV]

you can find some raw yuv test sequences at various resolutions here --> http://www.ldv.ei.tum.de/liquid.php?page=70

you can open them using rawsource for avisynth (or just feed them to dirac directly i guess)

[FireArse]

StephanV - thats a great source, many thanks! :)

[FireArse]

Hey, I've been working on a Windows machine recently - and wish to watch the output of the Dirac (1080p files) on my 1920x1200 Apple Mac screen. Are there any YUV players out there - and has anybody got experience in using/installing them? I'm using OS 10.4.2 if it helps.

Thanks,

Firas

[celtic_druid]

You could try mplayer patched with dirac support to play the drc. files directly.

[FireArse]

Celtic_druid,

Thanks for the suggestion - took a while to find the source for MPlayer, patched it, but I'm getting errors on 'make':

ld: multiple definitions of symbol _glPointParameteriv
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib(gll_api.o) definition of _glPointParameteriv
/usr/X11R6/lib/libGL.a(dri_dispatch.o) definition of _glPointParameteriv in section (__TEXT,__text)
ld: warning multiple definitions of symbol _put_string
libavcodec/libavcodec.a(bitstream.o) definition of _put_string in section (__TEXT,__text)
/usr/lib/libm.dylib(dnssd_ipc.o) definition of _put_string
make: *** [mplayer] Error 1

Any ideas?

Must note - I'm compiling on Mac OS 10.4.2 with XCode 2.1 setup - if anyone has binaries for MPlayer with the Dirac patch it would be greatly appreciated until I sort this issue out. As soon as Apple releases 10.4.3 I'll re-install.

Thanks,

Firas

[Doom9]

I'm being told both mplayer and vlc should be able to handle dirac in avi /ogg and I'm wondering if anybody has any experience with this on Windows.

[dirac]

Mplayer handles Dirac but with only the Dirac patch (available on Sourceforge CVS). So any prebuilt binaries of Mplayer on MS Windows will not work. You will need to download Mplayer source, apply the patch, build dirac, and build MPlayer. Not very convenient for all users I know. But since we release only the source for Dirac and not binaries, this is the way it is done.

It is different with VLC because VLC has built-in support for Dirac (from 0.8.2 onwards I think). However, the pre-built binaries for MS Windows won't support it since Dirac is only supported as an external library. So you will have to go thru the process of building Dirac and then building VLC with Dirac options enabled.

Anuradha

[celtic_druid]

I created a dirac avi via ffmpeg and played it via mplayer some time ago. Links to the patched ffmpeg and mplayer I think can be found earlier in this thread, they would be out of date by now though. ffmpeg patch I think needs updating for current dirac.

[FireArse]

It is different with VLC because VLC has built-in support for Dirac (from 0.8.2 onwards I think).

I cannot get VLC 0.8.2 to playback .drc files on my mac. There isn't an error message - I'll contact the developers in their forums.

I did note that dirac isn't listed in the 'Features' page of VLC:

VLC features (http://www.videolan.org/vlc/features.html)

Thanks

[Doom9]

is anybody up to the task of building a vlc with full dirac support for windows?

[dirac]

I am sorry if I caused some confusion with the statement that VLC has built-in support for Dirac from 0.8.2 onwards. What I meant was that a source code patch is not required to support Dirac in VLC as it is with Mplayer. It is supported as an external library though i.e. Dirac support has to be enabled using the --enable-dirac option of the configure command. So pre-built VLC binaries for all platforms will not have Dirac support. To enable it one needs to build and install Dirac from source, build VLC from source with the Dirac support enabled. Though Dirac is not mentioned in the Features list, it does get a mention in the NEWS.

http://developers.videolan.org/vlc/NEWS
(Changes between 0.8.1 and 0.8.2 section)

[hellfred]

is anybody up to the task of building a vlc with full dirac support for windows?
I can try an mplayer build, if you like.

Hellfred

[hellfred]

Is the MPlayer patch available at sourceforge (MPlayer-1.0pre7_dirac-0.5.x.patch) useable with dirac 0.5.4?
Compiling dirac 0.5.4 with MinGW/MSys on my Pentium M worked fine, so did applying the patch to mplayer source (MPlayer-1.0pre7try2.tar.bz2).
But I can not get MPlayer`s configure script to detect dirac, which was installed to /mingw. Even pointing the configure-skript to the /mingw/lib and /mingw/include does not help.

Building dirac with
$ ./configure --prefix=/mingw --disable-dependency-tracking --disable-libtool-lock
$ make
$ make install
Building mplayer with
$ ./configure --prefix=/opt/mplayer_dirac
But config.h reports:
/* enable Dirac support */
#undef HAVE_DIRAC
configure.log says (without --with-extralibdir / --with-extraincdir)
============ Checking for Dirac support (version 5.2!) ============

#include <libdirac_decoder/dirac_parser.h>
#include <string.h>
int main(void)
{
/* dirac is in flux, make sure that all interface routines and
* datatypes exist and work the way we expect it, so we don't break
* mplayer */
dirac_decoder_t *decoder;
unsigned char *yuv[3];
char buffer[1024];
dirac_chroma_t chroma;
dirac_frame_type_t frame;
dirac_seqparams_t seq_params;
dirac_frameparams_t frame_params;
dirac_framebuf_t frame_buf;
DecoderState state;

decoder = dirac_decoder_init(0);

/* we don't want to execute this kind of nonsense; just for making sure
* that compilation works... */
memset(&buffer, 0, sizeof(buffer));
dirac_buffer (decoder, buffer, buffer + sizeof(buffer));
state = dirac_parse (decoder);
dirac_set_buf (decoder, yuv, NULL);
dirac_skip(decoder, 1);
dirac_decoder_close(decoder);
return 0;
}

gcc -fno-PIC -O4 -march=pentium3 -mtune=pentium3 -pipe -ffast-math -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 /tmp/mplayer-conf-16804-1064.c -o /tmp/mplayer-conf-10946-1064.o -lstdc++
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:1:43: libdirac_decoder/dirac_parser.h: No such file or directory
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c: In function `main':
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:8: error: `dirac_decoder_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:8: error: (Each undeclared identifier is reported only once
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:8: error: for each function it appears in.)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:8: error: `decoder' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:11: error: `dirac_chroma_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:11: error: syntax error before "chroma"
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:12: error: `dirac_frame_type_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:13: error: `dirac_seqparams_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:14: error: `dirac_frameparams_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:15: error: `dirac_framebuf_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:16: error: `DecoderState' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-16804-1064.c:24: error: `state' undeclared (first use in this function)

ldd /tmp/mplayer-conf-10946-1064.o
./configure: ldd: command not found

Result is: no
##########################################

(END)

configure.log says (with extra lib and include directory parameter used)
============ Checking for Dirac support (version 5.2!) ============

#include <libdirac_decoder/dirac_parser.h>
#include <string.h>
int main(void)
{
/* dirac is in flux, make sure that all interface routines and
* datatypes exist and work the way we expect it, so we don't break
* mplayer */
dirac_decoder_t *decoder;
unsigned char *yuv[3];
char buffer[1024];
dirac_chroma_t chroma;
dirac_frame_type_t frame;
dirac_seqparams_t seq_params;
dirac_frameparams_t frame_params;
dirac_framebuf_t frame_buf;
DecoderState state;

decoder = dirac_decoder_init(0);

/* we don't want to execute this kind of nonsense; just for making sure
* that compilation works... */
memset(&buffer, 0, sizeof(buffer));
dirac_buffer (decoder, buffer, buffer + sizeof(buffer));
state = dirac_parse (decoder);
dirac_set_buf (decoder, yuv, NULL);
dirac_skip(decoder, 1);
dirac_decoder_close(decoder);
return 0;
}

gcc -fno-PIC -O4 -march=pentium3 -mtune=pentium3 -pipe -ffast-math -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/mingw/include -L/mingw/lib /tmp/mplayer-conf-22425-3980.c -o /tmp/mplayer-conf-3647-3980.o -lstdc++
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:1:43: libdirac_decoder/dirac_parser.h: No such file or directory
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c: In function `main':
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:8: error: `dirac_decoder_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:8: error: (Each undeclared identifier is reported only once
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:8: error: for each function it appears in.)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:8: error: `decoder' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:11: error: `dirac_chroma_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:11: error: syntax error before "chroma"
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:12: error: `dirac_frame_type_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:13: error: `dirac_seqparams_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:14: error: `dirac_frameparams_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:15: error: `dirac_framebuf_t' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:16: error: `DecoderState' undeclared (first use in this function)
C:/DOKUME~1/Stefan/LOKALE~1/Temp/mplayer-conf-22425-3980.c:24: error: `state' undeclared (first use in this function)

ldd /tmp/mplayer-conf-3647-3980.o
./configure: ldd: command not found

Result is: no
##########################################

(END)
The file dirac_parser.h is located at C:\Programme\MinGW\include\dirac\libdirac_decoder

Hellfred

EDIT
Output of configure to the shell:
Checking for Dirac support (version 5.2!) ... ./configure: pkg-config: command not found
./configure: pkg-config: command not found
no

How to disable pkg-config?

[ak]

You need to add -I/mingw/include/dirac as well, I guess.

As for patch you might want to try this one (against current cvs): https://opensvn.csie.org/4nykey/portage/media-video/mplayer-cvs/files/mplayer-dirac-cvs.diff
(configure/check part from old mplayer patch, decoding/parsing through lavc/lavf)

I think you rather install pkg-config than disable it: http://www.gimp.org/~tml/gimp/win32/pkg-config-0.20.zip plus it would require gtk+ runtime:
http://prdownloads.sourceforge.net/gimp-win/gtk%2B-2.6.9-setup.zip?download

[hellfred]

You need to add -I/mingw/include/dirac as well, I guess.

As for patch you might want to try this one (against current cvs): https://opensvn.csie.org/4nykey/portage/media-video/mplayer-cvs/files/mplayer-dirac-cvs.diff
(configure/check part from old mplayer patch, decoding/parsing through lavc/lavf)

I think you rather install pkg-config than disable it: http://www.gimp.org/~tml/gimp/win32/pkg-config-0.20.zip plus it would require gtk+ runtime:
http://prdownloads.sourceforge.net/gimp-win/gtk%2B-2.6.9-setup.zip?download

I just installed pkg-config form gimp.org (http://www.gimp.org/~tml/gimp/win32/downloads.html)
I have tryed including dirac directory, too, but without success. I will try the mentioned patch next, if detecting of dirac will fail with pkg-config.

Hellfred

[hellfred]

ak, can you tell me, what I did wrong now:
Checking for Dirac support (version 5.2!) ... Must specify package names on the command line
Must specify package names on the command line
no
I get this after:
Installing dirac to /opt/dirac
Including it into mplayers configure skript by setting ./configure --with-extraincdir=/opt/dirac/include --with-extralibdir=/opt/dirac/include

EDIT
The output is the same after patching a mplayer cvs checkout with the patch you mentioned above. Looks like I have to tell pkg-config that I want my packages configured for msys/mingw somehow.

[Yong]

*i think* u need to add PKG_CONFIG_PATH to windows user environment variable.
Example:
http://img223.imageshack.us/img223/8938/clipboard015qu.jpg (http://imageshack.us)

EDIT:
just tried play dirac with mplayer, everthings work fine except seeking...
the video frame will freeze if i try to seek... :(

[hellfred]

*i think* u need to add PKG_CONFIG_PATH to windows user environment variable.
Example:
http://img223.imageshack.us/img223/8938/clipboard015qu.jpg (http://imageshack.us)

EDIT:
just tried play dirac with mplayer, everthings work fine except seeking...
the video frame will freeze if i try to seek... :(
Thanks, Yong.
I am working on the same problem, following the advices given on this page (http://www.ogre3d.org/wiki/index.php/Build_OGRE_dependencies_using_MSYS).
But I do not understand the concept of pkg-config well.
What needs to be in that directory that is defined in PKG_CONFIG_PATH? The instructions given on the page mentioned above do not copy anything into that directory, so the directory is not existing at all on my system.

Hellfred

Edit:
dirac placed a file into MinGW\lib\pkgconfig, so i will point PKG_CONFIG_PATH to that directory.

[Yong]

Thanks, Yong.
I am working on the same problem, following the advices given on this page (http://www.ogre3d.org/wiki/index.php/Build_OGRE_dependencies_using_MSYS).
But I do not understand the concept of pkg-config well.
What needs to be in that directory that is defined in PKG_CONFIG_PATH? The instructions given on the page mentioned above do not copy anything into that directory, so the directory is not existing at all on my system.

Hellfred

Edit:
dirac placed a file into MinGW\lib\pkgconfig, so i will point PKG_CONFIG_PATH to that directory.
here is the answer:
http://pkgconfig.freedesktop.org/wiki/ ;)

BTW, dirac en/decoding speed are really slow(i coundnt play 640x480@24fps dirac video clip at realtime with mplayer), comapare with libavcodec SNOW, IIRC snow en/decoding is about 50% faster than dirac.

[hellfred]

here is the answer:
http://pkgconfig.freedesktop.org/wiki/ ;)

BTW, dirac en/decoding speed are really slow(i coundnt play 640x480@24fps dirac video clip at realtime with mplayer), comapare with libavcodec SNOW, IIRC snow en/decoding is about 50% faster than dirac.
I had visited this side, but could not find any useful information on that side, like:
How to install pkg-config on win32
How to set up pkg-config or what skripts/files need to be adjusted in which way.
How to use pkg-config
At the moment the Wiki consits only of the front page and some general Wiki help pages. If there is more, i need someone to point out the subsites, and the way to the next optician. :)

BTW: I still can not get around the message
Checking for Dirac support (version 5.2!) ... Must specify package names on the command line
Must specify package names on the command line
no
I have tryed it with and without the pkg-config.sh mentioned here (http://www.ogre3d.org/wiki/index.php/Build_OGRE_dependencies_using_MSYS)
and here (http://mail.gnome.org/archives/gtk-devel-list/2005-January/msg00091.html). (The skript is supposed to work around a bug in MSYS bash)
But it is not working.
After reading the manpage (http://www.die.net/doc/linux/man/man1/pkg-config.1.html), I think i have to type pkg-config followed by the package name, without the extension .pc. The .pc file has to be stored in a directory that is listed in the variable PKG_CONFIG_PATH.
Stefan@SAGARA ~
$ echo $PKG_CONFIG_PATH
/mingw/lib/pkgconfig

Stefan@SAGARA ~
$ ls /mingw/lib/pkgconfig/
dirac.pc

Stefan@SAGARA ~
$ pkg-config.exe dirac
Must specify package names on the command line

Stefan@SAGARA ~
$ pkg-config.sh dirac
Must specify package names on the command line

Stefan@SAGARA ~
$ cat $PKG_CONFIG_PATH/dirac.pc
prefix=/mingw
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: dirac
Description: The BBC Dirac Video Codec
Version: 0.5.4
Libs: -L${libdir} -ldirac_encoder -ldirac_decoder
Cflags: -I${includedir}/dirac


Stefan@SAGARA ~
$

I am lost at the moment and appreciate any helpful comments.
Really annoying:
Stefan@SAGARA /bin
$ pkg-config.exe --help
Must specify package names on the command line

Stefan@SAGARA /bin
$ pkg-config.sh --help
Must specify package names on the command line
Even parameters like --help are not recognized.:mad:

Hellfred

[Yong]

@hellfred:
How to install pkg-config on win32
I think u mean mingw,
try put the pkg-config.exe into the /mingw/bin folder.
How to use pkg-config
the dirac.pc file u posted look fine.
u no need to run pkg-config.exe manually, beacuse mplayer ./configure will run it silently. :)
Checking for Dirac support (version 5.2!) ... Must specify package names on the command line
wired... havent seen this message before...
usually i always get message like this: (if dont have the neccesary libs installed)
Checking for Dirac support (version 5.2!) ... Package dirac was not found in the pkg-config search path.
Perhaps you should add the directory containing `dirac.pc'
to the PKG_CONFIG_PATH environment variable
No package 'dirac' found
Package dirac was not found in the pkg-config search path.
Perhaps you should add the directory containing `dirac.pc'
to the PKG_CONFIG_PATH environment variable
No package 'dirac' found

did u use lasted dirac cvs version?

[hellfred]

Finally pkg-config starts working. I had to move pkg-config.exe from msys/1.0/bin to /mingw/bin. Now pkg-config --help prints a help message. Why placing the file into msys bin directory renders pkg-config.exe useless, I do not know. :confused:
And I have spend approximately 4 houres rebuilding dirac and reconfiguring mplayer over and over :mad:

Thanks for your help anyway. Enought offtopic in this thread.

Hellfred

Checking for Dirac support (version 5.2!) ... yes

Just for the records:
To be able to build MPlayer with dirac support, I had to edit those two lines in config.mak:DIRAC_LIB = -Lc:/Programme/MinGW/lib -ldirac_encoder -ldirac_decoder
-lstdc++
DIRAC_INC = -Ic:/Programme/MinGW/include/diractoDIRAC_LIB = -L/mingw/lib -ldirac_encoder -ldirac_decoder -lstdc++
DIRAC_INC = -I/mingw/include/dirac as gcc.exe does not like colons in the comandlines.

[AlexeyS]

Could somebody place link to .exe or something to play dirac files please? Are there some kind of GUI for Dirac encoder?

[Tommy Carrot]

Could somebody place link to .exe or something to play dirac files please? Are there some kind of GUI for Dirac encoder?For playback, you can find compiled directshow filter here (http://forum.doom9.org/showthread.php?p=748669#post748669) (or if you have athlon 64, you can use mplayer too). For encoding, there is a gui directory in the cvs, but i don't know if it actually works. If you want to test dirac, ffmpeg is relatively easy to use, but don't expect too much, the motion estimation is very instable, it simply cannot cope with fast motion (believe me, it's really bad). As doom9 said in his pre-test, dirac still needs a lot of work to become a serious contender in the video-encoding scene.

[AlexeyS]

For playback, you can find compiled directshow filter here (http://forum.doom9.org/showthread.php?p=748669#post748669) (or if you have athlon 64, you can use mplayer too).
There is only .ax file and no .dll file...

[Tommy Carrot]

Umm, directshow filters usually have .ax extentions.

[PatchWorKs]

Any chance to use dirac (both for encoding and decoding) under ffdshow ???

[celtic_druid]

http://sourceforge.net/tracker/?group_id=53761&atid=471492

[AlexeyS]

Umm, directshow filters usually have .ax extentions.
I've read about it needs some DLL. When I run RegSRV32 DiracSplitter.ax, I get error message "Error loading LoadLibrary "DiracSplitter.ax""

[celtic_druid]

Well the dependancies are:
ADVAPI32.DLL
COMCTL32.DLL
COMDLG32.DLL
GDI32.DLL
KERNEL32.DLL
MPR.DLL
MSVCRT.DLL
NTDLL.DLL
OLE32.DLL
OLEAUT32.DLL
RPCRT4.DLL
SHELL32.DLL
SHLWAPI.DLL
USER32.DLL
WINSPOOL.DRV

[Tommy Carrot]

I've read about it needs some DLL. When I run RegSRV32 DiracSplitter.ax, I get error message "Error loading LoadLibrary "DiracSplitter.ax""
If you can't get it work, and you don't have athlon 64, just use ffplay for playback, or you can check the quality of your dirac video by transcoding it into a lossless format, like this:
ffmpeg -i input.drc -vcodec ffv1 -strict -2 output.avi

[celtic_druid]

I could do other dirac enabled mplayer builds or just one with cpu runtime detection. Sirber was the one who asked though and he has an AMD 64, as do I so that is what I built.

Can't think of any reason why it shouldn't register though.

[AlexeyS]

If you can't get it work, and you don't have athlon 64, just use ffplay for playback, or you can check the quality of your dirac video by transcoding it into a lossless format, like this:
ffmpeg -i input.drc -vcodec ffv1 -strict -2 output.avi
I have Athlon 64 FX-55. How can I play files (I've downloaded few videos from Dirac website)?

[Doom9]

AlexeyS: Are you sure you're following the instructions for registering the splitter? The splitter depends on the decoder which also has to be present. Here are the instructions I followed (well, almost, I copied DiracDecoder.dll and DiracSplitter.ax to c:\windows\system32 and ran regsvr32 diracsplitter.ax). It won't work if DiracDecoder.dll can't be found in the patch.

These are the instructions for installing the Dirac DirectShow filter on
MS Windows 2000/XP platform.

1. Copy DiracSplitter.ax to C:\Program Files\Dirac.

2. Download and unpack the Dirac distribution and build the Release target.
The instructions on how to build on an MS Windows platform are availble in
section 3 of the README file in the main directory.

3. Copy the Dirac Decoder dll (win32\VS2003\release\DiracDecoder.dll) to
C:\Program Files\Dirac.

4. Register the Dirac directshow filter. You will need Admin privileges to
do this.

cd C:\Program Files\Dirac
regsvr32 DiracSplitter.ax

If the installation is OK, a success message pops up. If an error is
reported, include the install dir (C:\Program Files\Dirac) in the PATH
environment variable and try registering again.

5. Include C:\Program Files\Dirac in the PATH environment variable.

6. If step 4 is successful, double-clicking on a file with an extension .drc
should play back the Dirac encoded video sequences.

In addition, depending on which version of Dirac was used, you have to disable both Dirac filters in MPC if you're using MPC.

If anybody is willing to host an 11MB archive I also have a dirac enabled VLC build (0.8.4). I also have a dirac enabled mplayer.

[celtic_druid]

DiracDecoder.dll is required? Shouldn't be for my compile at least since it was linked against the static lib.

[Doom9]

well.. that's the instructions I was given for the filters I got from the Dirac team, I followed them and it worked out just fine.

[celtic_druid]

Then I guess they did a non static release. Makes some sense I guess since you can just update the dll. Anyway, I did a static release and I assume that is what they are using since it was the link given.

Works fine here.

[AlexeyS]

Then I guess they did a non static release. Makes some sense I guess since you can just update the dll. Anyway, I did a static release and I assume that is what they are using since it was the link given.

Works fine here.
I don't have this \win32\VS2003\release\DiracDecoder.dll.

Can someone just give .exe to all people who don't understand anything in programming? ;) I really want to see how the Dirac compress video (people say it's much better than AVC).

[IgorC]

(people say it's much better than AVC).

Who said that? Nowdays it´s impossible to find something much better.
Dirac is still on early development and it isn't even little better than AVC.

[celtic_druid]

The filter is for playback only anyway. If you want to see how it compresses, then you need an encoder.

[Doom9]

(people say it's much better than AVC).They obviously never encoded what I did for the codec comparison.. I looked at the results alright, and since I don't trample codecs when they're down, I didn't put up any screenshots. But I wouldn't write a codec isn't ready if I didn't truly believe that.

Have you tried those samples in MPC? It comes with all the filters you need.. they're just not that up-to-date and since the bitstream is still changing, depending on which version you have, you need different filters.

I'm adding the filters to play content encoded using the 0.5.4 version to this post. But as I said, they may not play content encoded with a previous version.

[FireArse]

Doom9 - Did you run a few 0.54 encodes and decide for yourself visually whether Dirac was suitable for the test? I agree encode times are HUGE but the quality is up there with AVC. They can now decode realtime SD upto 4Mbps.

For those that are interested, the schrodinger project has been setup to implement portable libraries for Dirac. It's being ported to C now:

http://schrodinger.sourceforge.net/

The Dirac team are working overtime to reach the 1.0 specification. We had one of the core developers in uni to give presentations on the BEng and PHd projects my uni is involved with. They are also putting Dirac into the .ogg container. Hope this isn't a repost - I did search.

Thanks,

F

[bratao]

hi !
Can anyonwe post a small sample of video, of te new codec version(0.54) ??

Thanks !

[Doom9]

Doom9 - Did you run a few 0.54 encodes and decide for yourself visually whether Dirac was suitable for the test?Of course and I reported back to the developers with samples and screenshots..

[FireArse]

Of course and I reported back to the developers with samples and screenshots..

Do you have a copy of the screenshots still - I'd really like to see the type of video you encoded - I encode normally slow and little activity related HD material - did you encode The Matrix?

Thanks

F

[Doom9]

did you encode The Matrix?Of course. Screenshots are abysmal, discoloration all over the place.. I don't discard codecs if it weren't for serious problems.

[bratao]

So, what the state of this encoder ??
I see in first pages that this encoder had a good pontencial , and see some screens show a good quality.
So i get the 0.54 and do a encode, but so many blocks and discoloration .
and too big file !
What happen, it regressed ? it a decoder error ?

[FireArse]

Which bitrates are you trying?

[unmei]

From the very few tests i did, it looked to me like it has two problems (apart from some the decoded yuv having an invalid frame sooner or later):

1) motion trails, while they are not nice, imo they are less of a disturbance at the moment
2) L2 frames (i assume) are severely broken

http://homepage.hispeed.ch/mieru/doom9/gunbuster2_dirac_Q9_L1num10_sep40_frame298.png
Q 9 and num L1 10, L1 seperation 40, ~1.9 mbit/s

http://homepage.hispeed.ch/mieru/doom9/gunbuster2_dirac_Q7_L1num10_sep40_frame298.png
Q 7 and num L1 10, L1 seperation 40, ~0.75 mbit/s

http://homepage.hispeed.ch/mieru/doom9/gunbuster2_dirac_Q7_L1num10_sep2_frame298.png
Q 7 and num L1 10, L1 seperation 2, ~0.75 mbit/s

I don't know the types of the sample frames (and whether they are even the same) but they represent the overall impression in that scene with objects moving at medium speed. IMO the Q7 with low L1 seperation is way better than the Q 9 one with almost triple the bitrate but many L2 frames. Note that the L2 problem is not visible on low motion.

I am unsure about the meaning of the L1 parameters. Therefore i will explain how i interpreted them - if this is wrong, probably my conclusions (problems 1 and 2) are also wrong - please correct me in this case.
My interpretation is that "num L1" defines how many L1 frames seperate two Intra frames and "L1 seperation" defines how many L2 frames seperate two L1 frames. Example: i22122122122122122122122122122122 = num 10, sep 2

[PatchWorKs]

up !

Any news about Dirac ??? :confused:

[Kopernikus]

The specification is currently being revised.

There is a project called schrodinger, that tries to do a fast, clean and portable implementation of dirac, once the specs are final.

A new release of the dirac software should be ready very soon. (one or two weeks).

Work on a ogg muxing scheme is in progress, too.

[siddharthagandhi]

These two "independent" codecs--Snow and Dirac. Are there any available comparisons like Doom9's to show how they compare to x264 and xvid and nd avc?

[Doom9]

Are there any available comparisons like Doom9's to show how they compare to x264 and xvid and nd avc?They both are in my 2005 codec comparison...

[siddharthagandhi]

"Therefore, both Dirac and QuickTime are at this point disqualified. "

But it was disqualified....

[Doom9]

which should be a very strong indicator as to whether you should be using this particular codec or not. Quite frankly Dirac is some galaxies away from becoming a serious contender. Not only is it dog slow (and I have one of the fastest boxes you find in today's homes) it's quality problems clearly disqualify it from any use.

[siddharthagandhi]

Is the video codec Snow in the same boat?

[Caroliano]

Is the video codec Snow in the same boat?
See Doom9 comparison AGAIN... Snow is there too. You can see the pictures and read Doom9's coments about it. In my opinion, it is a better than Xvid but worse than x264, plus bugs. And is slow. But it cannot be put in the "patent free" class, as only Dirac and Theora do. Our only hopes!

An interesting comparision envolving x264, RV10, VP7, Snow, Dirac, Xvid, Theora: http://www.minkymomo.info/~meroko_deathnote/tmp/codec_test/glider/comparison.html

At an first glance, you can think that Dirac performed VERY well. But look at the file sizes: Dirac is oversized by far. And also look at the whole picture (click to enlarge): there are many yellow blotchs that are motion trails. A serious quality issue that don't disapear even with this high bitrate. Sum it whith it's speed (you can decode DVD resolution videos in real time on an P4 3.5GHz!) and the conclusion is: not usable yet.

EDIT: Also, Snow bitstream isn't freezed yet, so what you encode today may not be decoded by tomorrow decoder. The Dirac specs are complete, but the encoder is still being adapted to it. In that case, what you encode now certanly cannot be decoded in the future.

[PatchWorKs]

...still waiting for an usable dirac encoder... :(

[Yong]

...still waiting for an usable dirac encoder... :(

currently an usable dirac encoder= mencoder/ffmpeg, of course they must be patched.
and the result file can be played with ffplay/mplayer without problem.
imho cli encoder isnt hard to use(just learn how to write batch file:p)
You might wanna check out the celtic druid build,
but im not sure now he still compile mplayer/ffmpeg with dirac.

[celtic_druid]

I stopped awhile back. Increased file sizes for something no one was interested in and the patch needed updating.

[PatchWorKs]

Already posted in the news:

[add] Dirac encoder (BBC's open source wavelet video encoder) support

Enjoy !

MediaCoder website (http://mediacoder.sourceforge.net/)

[phrentec]

where can I get the dirac enabled mplayer or dirac enabled vlc, I still can't find where to download DiracDecoder.dll in order to register the direct show filter? are there any comparisons with 0.8 compared to xvid or x264? Thanks.!

[phrentec]

ok I was able to compile and get the DiracDecoder.dll. now I need some sample dirac 0.8 video. Anyone have a link to any?

[Caroliano]

Give a look in MediaCoder version 0.6.0.3902 or newer. They have update to Dirac 0.8. You should be able to make yours own samples of dirac, xvid and x264 and compare them. If you do it, please share with us! :)

Another thing is Schrodinger. It will be the main encoder for dirac format, and dirac codec will be only the reference one. If you can compare it too... it should at least be faster than dirac.

[klinika]

ok I was able to compile and get the DiracDecoder.dll.

Great! But I get "DiracDecoder.dll was loaded, but the DllRegisterServer entry point was not found. This file can not be registered."

[clsid]

That is because you are not supposed to register it. It is a library that the DirectShow filter needs. Get the DirectShow filter from the sourceforge project page. Put the files in the same folder.

[klinika]

Thanks, sorry for jumping the gun. For some reason I get roughly 0.3 fps sd playback with the above dll so ended up compiling it myself. Now I get 9-10 fps with the same b&w clip using sd480 preset. That's with c2d. Still a long way to go.

Edit: There is gpu acceleration forthcoming. That should get things going!

[guada2]

Just a little question:
Where could i download QtCore4.dll please ?

[Koti]

http://www.highend3d.com/maya/downloads/tools/render_managers/3707.html

there is a link in this thread :)

[guada2]

Thank you very much K O T I :) :)