Talk:Dirac (video compression format)

Who was the silly fellow who said "[Dirac] uses Wavelet transforms unlike standard codecs which [...] use Wavelet transforms"? Or rather, who were the silly readers who didn't fix that? Anyways, it's been remedied. --Scotto 06:58, 20 October 2005 (UTC)[reply]

Bitstream fixed or not

One thing the article doesn't mention is whether the bitstream is fixed or not. If it is, then theoretically anything you encode now should be decodable in the future (which doesn't mean you should use a highly experimental coded) whereas if it isn't like snow things could change and what works now may not work in the future Nil Einne 17:11, 27 October 2006 (UTC)[reply]

Pointless comparison?

For example, H.264/MPEG-4 AVC is often as good or better in compression capability for still images, despite the wavelet-based design of JPEG-2000.[1][2][3][4][5] The primary benefits of JPEG-2000 relative to other codecs are functionality aspects, such as scalability features, rather than compression capability.

Is it really fair to compare a codec who's fnal draft was AFAIK sometime in 2000 or 2001 to a codec who's final draft according to our article is 2003? 2 years can be a long time in research I guess. Plus MPEG4, or at least the MP part has IMHO had a lot more work then JPEG2000 despite being finished later. Seems to me we should at least compare the cutting edge rather then two standards not really intended to compete with different timeframes Nil Einne 15:20, 11 January 2007 (UTC)[reply]

Does the comparison belong in this article at all? In the context of this article, the implication seems to be that because H.264 beats JPEG2000, it will also beat Dirac since JPEG2000 and Dirac both use wavelets. Just as there are a wide variety of block based codecs, there is no reason to believe that two wavelet based codecs will have similar performance characteristics.

Furthermore, compression ratios and quality are not the only relevant measure for video codecs. Compression or decompression complexity is also important: being able to process the video data in real time and/or with low latency is a must for a number of applications. This isn't going to be such a big issue when comparing still image codecs. I realise that this is quite a difficult thing to measure since it depends on the hardware/software used for the tests --James (talk) 02:22, 11 March 2008 (UTC)[reply]

There are rarely, if ever, huge improvements in video encoding. That's been the case with block-based codecs, and I don't see any reason to believe wavelets will develop significantly differently. 2 years isn't a very long time anyhow. Perhaps that statement could be replaced in the future when real comparisons are available, but for now I think it's a very useful bit of info to have. Despite the potential of wavelets, it doesn't necessarily exceed block-based encoding; the drawbacks of which can be mitigated. It would be a shame to see it get deleted just because it isn't ideal.

And computational complexity is rarely used anymore. Performance depends much more on how much optimization the code has received, than the inherent complexity of the methods. Computers are fast enough these days that the latter doesn't often become an issue. Dirac also happens to be well behind H.264 in performance, anyhow. Rcooley (talk) 05:35, 11 March 2008 (UTC)[reply]

I'm not saying that the data should be deleted. Merely that it might be more appropriate for the JPEG2000 article. For this article it would make sense to include comparisons between Dirac and H.264 doing what they were designed for: encoding video.

As far as computational complexity goes, it is still an issue today when working with HD video. --James (talk) 02:36, 12 March 2008 (UTC)[reply]

There doesn't need to be huge improvements just improvements. h264/MPEG4 AVC is clearly better then MPEG4 ASP for example even though there is only about 5 years between them, and also I think the time between h264/AVC and JPEG2000 may be about 3 years not 2 (JPEG2000 in 2000, AVC in 2003). Also James is right complexity is a problem nowadays especially when it comes to AVC and HD. There is a reason why Nvidia and ATI added hardware decompression to their graphics chipsets. When it comes to encoding it gets even worse (I don't think even a quad core is capable of realtime encoding of a HD source for AVC for many codecs operating at high quality settings). Nil Einne (talk) 09:09, 1 May 2008 (UTC)[reply]

I removed the comparison because as James said, it's irrelevant to the article. This is a Dirac article. It's not a wavelet vs block based article nor the JPEG2000 article. If there were comparisons between Dirac and AVC or Dirac and something else then fine. But comparisons between AVC and JPEG2000 have absolutely no relevance to the Dirac article especially without a source suggesting there is any relevance for Dirac. I suspect there isn't since this article (I changed it), and indeed as far as I'm aware even the developers don't claim that they expect wavelet to be significantly better then block based coding from an effiency perspective. Note in the FAQ, they don't say anything like that [1] the closest thing is 'They perform very well in still image compression, and can be said to be state of the art there' but note they don't say they 'perform better then block based'. Personally, even though they don't really say it, I expect patents (or the lack of them) to be just as important in why they choose wavelets Nil Einne (talk) 09:29, 1 May 2008 (UTC)[reply]

Unsourced statement about patent search

"In addition, the BBC have checked (by extensive patent search) that Dirac does not infringe any third party patents, enabling the public to use Dirac for any imaginable purpose." This statement contradicts the Dirac FAQ. Hsivonen (talk) 15:53, 12 December 2007 (UTC)[reply]

You're right. I've adjusted the article accordingly Nil Einne (talk) 09:15, 1 May 2008 (UTC)[reply]

Also I removed the bit about the BBC having patents as they now say they let them lapse. Nil Einne (talk) 09:35, 1 May 2008 (UTC)[reply]

Comparison

I removed the suggestion the reason they were going to perform well was because of wavelets [2] doesn't say anything about that. While they did say something like they want to be better then existing codecs, this should really be true for any codec and it doesn't mean they are saying they expect to be better because they are using wavelets Nil Einne (talk) 09:31, 1 May 2008 (UTC)[reply]

Update (2008-11-13)

I've updated the entry to more accurately reflect the current state of Dirac, given that it's no longer quite as new or experimental as the article previously suggested. If I've screwed up, please go ahead and fix it -- I'm a Wikipedia newbie and don't really know what I'm doing! —Preceding unsigned comment added by 86.24.226.239 (talk) 02:25, 13 November 2008 (UTC)[reply]

FPGA Hardware

I recall that there were a couple of guys from BBC Research working on an open FPGA implementation which was documented at opencores.org. It seemed like a serious effort with regular updates, and one of the guys had a blog discussing progress. I can't find the blog any longer, but I vaguely recall the last entry talking about no more blog entries, but saying that the development effort would continue (it all seemed slightly mysterious). Anyone know what's happening with this? —Preceding unsigned comment added by 68.164.175.201 (talk) 17:31, 15 February 2009 (UTC)[reply]

UPDATE TAG New version of schroedinger-1.0.9

It is really out http://diracvideo.org/2010/03/schroedinger-1-0-9-released/ and it merges the performance of both implementations.

Better Comparison

I think I found a better and more up-to-date codec comparison than the one currently listed under the Performance section: http://keyj.s2000.ws/?p=356. What do you all think? Unfortunatly, Dirac performs very poorly in this one too.

Why is that unfortunate? Is there more motive to include a comparison showing Dirac in a positive light? 67.161.175.54 (talk)