Dirac - BBC will rule future codecs [Archive]

lexor

1st May 2004, 00:23

BBC's R&D is hard at work developing The Dirac Project (http://www.bbc.co.uk/rd/projects/dirac/overview.shtml)

taken from their site:

Dirac is a general-purpose video codec aimed at resolutions from QCIF (180x144) to HDTV (1920x1080) progressive or interlaced. It uses wavelets, motion compensation and arithmetic coding and aims to be competitive with other state of the art codecs.

Sirber

1st May 2004, 02:18

Hi

Many project say that they will be the best. None so far. Stop dreaming and use xvid or realvideo :D

P0l1m0rph1c

1st May 2004, 03:46

It's amazing what slashdot can do to an unknown video codec....[/useless_post]

stephanV

1st May 2004, 09:26

Originally posted by Sirber
Hi

Many project say that they will be the best. None so far. Stop dreaming and use xvid or realvideo :D

They are saying they're competative, not the best. Anyway, there's no point in wrting off a codec before you've seen what it can do. Or do you believe XviD and RealVideo are the best we'll ever get? (if they are the best anyway)

kilg0r3

1st May 2004, 10:16

Hey, come on. A company like the BBC has done preliminary resaerch and now offers it to the opensource community. I think this is great, eventhough they might be a bit late, taking into account the number of existing codecs.

jimmy basushi

1st May 2004, 10:22

stephenv i believe sirber is replying to the topic.

i also would love to see this compared to our current greats rv10 and xvid (check codec test) when the devels believe it can compete.

dragongodz

2nd May 2004, 02:44

also they say
It has been developed as a research tool, not a product, as a basis for further developments.
and
An experimental version of the code, written in C++, was released under an Open Source licence agreement on 11th March at http://sourceforge.net/projects/dirac.

so no it wasnt developed to strictly try and take on other codecs or be a product. simply dismissing it is not right either as it may be of interest to other codec developers in some way(or not as they choose).

SeeMoreDigital

2nd May 2004, 10:44

A friend of mine, from time to time, does some sub-contract work for the BBC and has spoken to a few people in their R&D department about this!

It all started when he asked one of these R&D guys what digital format the BBC was intending to use to store their massive library of 'live' broadcast material.

Back in 2002 (when DVD and Mpeg2 was still taking off) he was told that the R&D department was working on something 'way better' than Mpeg2. "Was it Mpeg4"? my friend asked. "Absolutely not"! came back the reply. "What is it then"? It's a secret at the moment... but follow me and I'll show you some examples.

Out came a shiny CD-R with approx 60 mins of broadcast quality audio and video on it... some soccer match I think it was...

Anyway, apparently it was "the dogs bollocks"!

Cheers

chilledoutuk

2nd May 2004, 13:29

any chance of anyone compiling this and posting it on here?
would be much apeciated:D

Latexxx

2nd May 2004, 13:50

It doesn't have an encoding app. Somebody needs to do program which utilises the encoding system provided by the BBC's library.

Nic

3rd May 2004, 12:53

Woah...this makes h264 seem fast.

I've thrown a bit of code together to go from AVS File to Dirac, and doing my first 50 frame encode as I type this. It's gonna take some time. I'll report back on quality and maybe screen shots if it encodes ok.

Cheers,
-Nic

kilg0r3

3rd May 2004, 13:02

Originally posted by Nic
[B]doing my first 50 frame encode as I type this. It's gonna take some time.:scared:

:sly: Ah, now come on Nic, you're not using your pocket calc again, are you?

Nic

3rd May 2004, 13:15

@kilg0r3: I could have drawn the pictures quicker ;) Now im writing app to view the YUV files it decodes to. I think I did it at too higher a bitrate, 50 frames at 352x288 came out at 845,671 bytes. I'll let you know what it looks like soon :)

-Nic

ac-chan123

3rd May 2004, 14:06

For .yuv(single file with muliple Frames) you can use Avisynth with rawsource filter/plugin(http://www.avisynth.org/warpenterprises/).

AC-Chan(Robert Vincenz)

Nic

3rd May 2004, 14:12

It uses a .hdr and .yuv file for the yuv format. I've just written a little mfc app for viewing, which will suffice for now. But thanks for the tip.

Dirac definitely encodes ok. Slow but everythings working. Doing more tests at FD1 res. ill post pics :)

Cheers
-Nic

ps
Ok FD1 is too slow to even try. I had a shower and lunch and came back it had only done 2 frames. When I tried 352x288, the I Frames are fine but intermediate ones have weird artefacts on them. Also seeing I set the streaming preset the bitrate was extremely high. This codec needs a lot of work, but nice to see a opensource wavelet codec being developed...

slavickas

5th May 2004, 18:13

Originally posted by Nic
It uses a .hdr and .yuv file for the yuv format. I've just written a little mfc app for viewing, which will suffice for now. But thanks for the tip.

http://www.ee.columbia.edu/~ywang/Research/YUVGenius.html
maybe suits your needs?

LigH

22nd October 2004, 23:35

Now that guliverkli made a DS splitter filter, and the source is at version 0.4.3, IMHO it's about time to have a Win32 binaries distributor with regular builds; anyone volunteering?!...

SeeMoreDigital

22nd October 2004, 23:42

Agreed... a compile would be nice.

Cheers

Sharktooth

23rd October 2004, 15:02

Here's my build (0.4.3 sources): http://ebola.gamersrevolt.it/dirac/dirac-0.4.3.rar
I did not check it coz i'm a bit busy but it should work.

Sharktooth

23rd October 2004, 16:32

Sorry i couldnt edit the prev. message however i tested the build and it works.

LigH

23rd October 2004, 20:30

Thank you, Sharktooth. Now I hope more people will be able to test the current version.

the Mad Duke

24th October 2004, 06:32

So, this is their own algorithm that doesn't infringe on other patents so they can avoid paying royalties? I'm just curious how far they have advanced since using VP6.

BC Television Journalists Being Equipped with QuickLink Technology Powered by On2's VP6 Video Codec.

http://www.on2.com/pressreleases.php3?qs1=bbctv_quicklink_vp6

Sharktooth

24th October 2004, 14:43

Uhm, i dont think there will be major interests in Dirac until it gets stable, the bitstream will be definitive and Gabest or Illiminable will produce a directshow encoder filter (commandline is ugly for most users!).

damrod

24th October 2004, 17:30

maybe i will update my gui for dirac since encoding seems to works ;)

Sharktooth

25th October 2004, 01:55

great:)
I could produce a build including your GUI and the actual DS filters (splitter and decoder).

EDIT: I'm also thinking about different builds with specific CPU optimizations. However the source code is a bit "uhm" (that means a lot of mess and unoptimized) and there's a lot of room for speed improvements.

Atamido

25th October 2004, 03:00

I'm having trouble getting the command line encoder to work. I had 10 bitmaps that I used the BMPtoRGB.exe to make "testrgb" with. It appears to have worked as the total size of testrgb is slightly larger than the total size of all of the bitmaps. However, when I try to use dirac_encoder.exe I must be getting the syntax incorrect because it either lists the options, gives an error about missing files, or appears to work but produces files that are only 0-1KB in size.

C> dirac_encoder testrgb testdirac

I can't seem to get any of the switches to work either. What am I missing?

Sirber

25th October 2004, 03:19

Originally posted by Sharktooth
Uhm, i dont think there will be major interests in Dirac until it gets stable, the bitstream will be definitive and Gabest or Illiminable will produce a directshow encoder filter (commandline is ugly for most users!). cmdlienencoders are great and fast. You just need a little GUI :)

RadicalEd

25th October 2004, 03:20

Originally posted by Pamel
I'm having trouble getting the command line encoder to work. I had 10 bitmaps that I used the BMPtoRGB.exe to make "testrgb" with. It appears to have worked as the total size of testrgb is slightly larger than the total size of all of the bitmaps. However, when I try to use dirac_encoder.exe I must be getting the syntax incorrect because it either lists the options, gives an error about missing files, or appears to work but produces files that are only 0-1KB in size.

C> dirac_encoder testrgb testdirac

I can't seem to get any of the switches to work either. What am I missing?

My commandline looks like this: "dirac_encoder.exe -SD576 -verbose sub sub2"
-SD576 is the preset (as you can tell by the list given at the encoder) -verbose, because you'll definitely want to see frame numbers with the speed of the encoder being what it is

You may want to use more flags to customize the encoder, I just haven't gotten around to doing so myself yet.

sub is the input and sub2 is the output. Input looks for two files, sub.yuv and sub.hdr. Output will output sub2.drc (the actual compressed file -- playable in directshow with gabest's new splitter/decoder), sub2.hdr, sub2.imt, and sub2.yuv.

You probably need to create the hdr file with make_header.exe, though double-check the .hdr file created by it in notepad -- it produced the wrong values for me and I had to edit it manually.

*.mp4 guy

25th October 2004, 06:05

ahh this is very interesting, anyway if anyone makes a gui for it that would be great, seeing as im a bit of an idiot when it comes to commandline stuff and switches(it took me practically a year to learn how to use xvid). Anyway it would be fun to torture my computer with a test encode at dvd res:devil: ... a short one of course

Atamido

25th October 2004, 08:03

Okay, I produced the header as you said and it seemed to work hard on encoding. But when I went to play it back, it just showed a green screen with some noise. I then tried to convert the RGB file to YUV420 and tried again but the result was identical.

Files viewable here (http://commo.de/dirac-0.4.3/bin/).

RadicalEd

25th October 2004, 08:06

That sounds similar to what I got with the unedited header. Are you sure the resolution and fps in the .hdr file are the same as your video?

edit: here, from testyuv420.hdr:
320
240
10

10 is the fps and 320x240 obviously is the resolution. These values need to be edited to reflect the actual file being fed. Dunno why make_header doesn't work the way it's supposed to.

LigH

25th October 2004, 08:42

:devil: Dirac tools come from hell! :devil:

1) How to compress an AVI?

- AVI => BMP's
- BMP's => RGB stream
- RGB stream => YUV-4:2:0 stream
- make header (oh, so cute...)
- encode

I don't think it would be too hard to make a small tool "AVS to YUV+HDR". If I knew how to handle VfW input, I would probably write it. ;)

2) Speed? What's that? :eek: 2000 frames on a Duron 800 - already running throug the last night, may be finished this evening.

:( Not yet really useful. And I do not even know the playback quality yet...

RadicalEd

25th October 2004, 08:48

Quality for my initial test wasn't stellar. A bit under XviD and about on par with snow (http://forum.doom9.org/showthread.php?s=&postid=561512#post561512). However, that's only with the -SD576 setting and no other tweaks due to the length of time it takes to encode even 82 frames.

Also, you can cut out those first three steps if you just use ffdshow/ffmpeg/mencoder to encode to uncompressed YV12 and output raw data.

LigH

25th October 2004, 08:59

:cool: Of course, ff* supports raw YUV streams.

ac-chan123

25th October 2004, 13:35

For avisynth it give a filter/plugin called rawsource. it support RGB and YUV in different versions(Like YV12, ABGR, ...). You can find this filter on warpenterprise´s site.

Atamido

25th October 2004, 16:22

Originally posted by RadicalEd
edit: here, from testyuv420.hdr:
320
240
10

10 is the fps and 320x240 obviously is the resolution. These values need to be edited to reflect the actual file being fed. Dunno why make_header doesn't work the way it's supposed to. I thought the 10 was the total number for frames. Is that not stored in there? I edited it to what it is now, but I don't understand what any of the other numbers are for. Are one of these other numbers messing it up?

Sharktooth

29th October 2004, 00:26

@damrod: any news for the GUI?

Ogig

1st December 2004, 21:36

New version of dirac 0.5 is released.

Changes:

This ia a major release with new features and algorithmic improvements. The major changes are a new encoder "C" interface, several algorithmic improvements, several bugfixes, support for building under Windows using MS VC++ .NET 2003, and static and shared library builds using libtool under Unix and GNU/Linux. The libraries have been restructured so that only two libraries are created, one for the encoder and one for the decoder.

damrod

1st December 2004, 22:38

@Sharktooth

not for the moment sorry

i will try to work on it this week end.. too much work at work this week...i'm going to sleep now ;)

PS: it must be easy to complete/update the gui...i need to check the parameters i think ;-)

johnslion

2nd December 2004, 10:41

Originally posted by Sharktooth
Sorry i couldnt edit the prev. message however i tested the build and it works.

I download codes from the Dirac project website, but I can not build with VC6.0, there are too much errors, can anyone tell me the steps of building this project with VC6.0.

Nic

2nd December 2004, 11:29

They don't really support VC6, so it's a little work to get it to compile correctly. Try using the Intel Compiler as a plugin for VC6 or upgrade to MS VC 2003 are the easiest options, otherwise you'll probably have to update the STL code (AFAIK that's the part it fails on the most)

-Nic