On the road to a Dirac standard (Son of Id) [LWN.net]

On the road to a Dirac standard (Son of Id)

Posted Jan 30, 2008 6:24 UTC (Wed) by ikm (subscriber, #493) [Link]

It'd be quite ironic if 'the only decent royalty-free video codec to be out there' required a
GeForce8-series card with proprietary drivers in order to playback HD content at realtime
(i.e. utilizing CUDA). My point is, performance is an issue here too, and it should not be,
well, overlooked.

On the road to a Dirac standard (Son of Id)

Posted Jan 30, 2008 13:50 UTC (Wed) by pointwood (guest, #2814) [Link]

Doesn't ATI/AMD have something similar? And with AMD releasing the documentation for their
cards, making it possible to create open source drivers, my guess is that something similar
will be made for those eventually.

On the road to a Dirac standard (Son of Id)

Posted Jan 31, 2008 8:03 UTC (Thu) by drag (subscriber, #31333) [Link]

I don't think they are overlooking anything. Performance is certainly a issue, hence making it
work with CUDA.

The issue with this isn't so much that they are using a proprietary software layer to interact
with the GPU.. it's that there isn't a open source version avialable for them to use.

Nowadays, and it's only going to get more true into the future, the GPU is a integral part of
your PC. It's a _very_ fast processor with a huge amount of memory bandwidth that is heavily
optimized for the sort of things that general purpose CPU is bad at. (like doing media
encoding/decoding) IT's no longer a 3D-engine. The 'Hardware accelerated' OpenGL stack
provided by Nvidia is more software then hardware. No longer is a video card a '3D
accelerator' it's a general purpose device used more and more heavily as the platform
matures... and it's almost entirely proprietary.

But...

I am sure that in the future when Dirac is finalized people will work on hand-tuned assembly
to get it to work fairly fast on a normal PC desktop without any fancy graphics acceleration.
But I would expect that to be happenning after Dirac matures a bit more as a codec. C (or
whatever they are using) is a lot easier to work in then assembly.

> Doesn't ATI/AMD have something similar? And with AMD releasing the documentation for their
cards, making it possible to create open source drivers, my guess is that something similar
will be made for those eventually.

Hopefully.

CUDA, seems to me, provides a sort of software-based ISA. Similar to how Intel and AMD use
hardware to provide a x86 ISA to make their processors, heavily risc-like in their true
nature, x86-compatable. Well instead of doing it in hardware they are using a layer
proprietary software to hide the differences between their GPU variations and block/hide use
of portions of the video card they don't want to let programmers use.

With AMD/ATI they had a competiting thing called 'CTM' (for Close-To-Metal). I don't know much
about it, this GPU stuff is realy over my head. You can get a PDF describing it and
hardware/software interfaces at:
http://ati.amd.com/companyinfo/researcher/documents/ATI_C...

AMD/ATI appears to be updating it's stuff with CTM. I don't know what is going on with it.
They originally released a open source project used to create a virtual machine interface for
programmers to gain access to the GPU.

It's sourceforge page was at:
http://sourceforge.net/projects/amdctm/

But now they have this message:
> 2007/09/01: The AMD engineering team is currently working on the next major release of AMD's
Stream Computing Software stack. AMD is not giving out the old release of CTM anymore to
developers. We will update this page with more information. Stay tuned!

With Intel they are working on the Larrabee project. Due out on 2010 or so. This is suppose to
be a GPU-like item has _lots_ of processor cores (on the order of 16-24) and large amounts of
floating point performance. It's supposadly 'x86-like' to make it easy to program for,
something like that. It is more general purpose and people keep saying how even though it will
be fast they have doubts because the way it looks now it will have relatively poor DirectX 10
performance... which doesn't bother me at all.
http://arstechnica.com/news.ars/post/20080117-larrabee-be...

On the road to a Dirac standard (Son of Id)

Posted Jan 30, 2008 10:02 UTC (Wed) by coriordan (guest, #7544) [Link]

From Sean Daly's interview of the BBC's Ashley Highfield:

Ashley Highfield: Well, I mean, I think Dirac is a great product, and I am directly funding it, and supporting it, and wish to see it grow in its usage. It is a service, as you said, to enable more efficient transmission of video files. It isn't an encryption solution. It's an encoding solution, and it wasn't mature at the time of the rollout of iPlayer. It's predominantly aimed at moving video around inside the organization. But absolutely, if we can find an application for Dirac within our video services to our audiences, we will. But it's not the solution, I think, to that which you're talking about, but we do have a separate workstream looking at open DRM. But even that, as I think you'd agree, is not the solution. The solution is actually to find a solution to DRM, to move beyond DRM in the long run.

On the road to a Dirac standard (Son of Id)

Posted Jan 30, 2008 14:04 UTC (Wed) by kirkengaard (subscriber, #15022) [Link]

Ah, the confusion surrounding what a video coding standard is for.  enCODing and DECoding raw
data into conveniently usable formats is the job of a codec, if I remember the 90s properly.
But you will notice that "customers"/"audiences" seem to require an inconvenience layer, "an
encryption solution".  Dirac is a perfectly good codec, it's just not a perfectly good
business model prop.

I'm not trying to troll -- it's the basic software design confusion that has me here.  This
has been done pseudo-correctly with the encapsulation of MPEG-4 inside encryption solutions,
although it doesn't seem as easy to get the MPEG-4 out of the DRM once you're an authorized
user.  Would it not be wise, as far as it goes, to adopt Dirac and a "DRM" standard, and
encapsulate the perfectly good, standard video inside a perfectly good, standard
encryption/decryption mechanism -- a crydec, as it were?

Of course, you would then have to trust the recipient of the encrypted, encoded file with the
contents, the codec and the crydec.

On the road to a Dirac standard (Son of Id)

Posted Jan 30, 2008 18:19 UTC (Wed) by jd (guest, #26381) [Link]

You're always going to have to trust the recipient, to a degree, as anything that is transmissable to one device or set of devices (monitor and speakers, for example) can be sent to any other device or set of devices (say, a disk file), because the data has to be decrypted and unprotected at some point and that point isn't in the brain. Yet. At the very least, it's copyable in analogue form.

The question is not whether you trust (you must) but rather how much you trust, return on DRM investment and what the ratio is between the profit to be gained from deterrence through difficulty versus the cost of implementing that deterrence is. Ultimately, studios want to maximize profits, so any DRM that costs more than it makes (even if it is otherwise perfect) is worse than useless. I seriously doubt DRM has shown any return on investment, so far, which leads me to believe that there is no business case for it.