Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Graphics Media

Next-Next Generation Video: Introducing Daala 86

Posted by Soulskill from the you-can-tell-by-the-pixels dept.
An anonymous reader sends this excerpt from a post by Xiph.org's Monty Montgomery: "Xiph.Org has been working on Daala, a new video codec for some time now, though Opus work had overshadowed it until just recently. With Opus finalized and much of the mop-up work well in hand, Daala development has taken center stage. I've started work on 'demo' pages for Daala, just like I've done demos of other Xiph development projects. Daala aims to be rather different from other video codecs (and it's the first from-scratch design attempt in a while), so the first few demo pages are going to be mostly concerned with what's new and different in Daala. I've finished the first 'demo' page (about Daala's lapped transforms), so if you're interested in video coding technology, go have a look!"
This discussion has been archived. No new comments can be posted.

Next-Next Generation Video: Introducing Daala More

Next-Next Generation Video: Introducing Daala

Comments Filter:

  • There really aren't any marketing people in OSS (Score:2, Insightful)

    by Anonymous Coward

    Daala? That will play well in test/focus groups - I'm certain of it.

    • Re: (Score:1)

      by Anonymous Coward

      As far as google is concerned, the only two meaningful meanings for Daala are: Xiph's new codec(!) and a Star Wars cutie.

      Looks like the marketing people did just fine, they already own the word for all meaningful intents and purposes related to TI, and they managed it really fast.

      • Also, in the Star Wars universe, Daala is the protégé of Grand Moff Tarkin, who gave his name to Xiph.org's earlier experimental wavelet-based video codec effort [theora.org], so the name makes perfect sense from a historical perspective as well.

        • Star Wars is hardly original. Lucas evidently liked to double up vowels to give clones a slightly different name, ie. Luke Skywalker's clone is Luuke Skywalker. Daala might come from Dala, which according to a quick search is a board game from Sudan.

          • Re: (Score:1)

            by Anonymous Coward

            None of those characters came from George Lucas. Admiral Daala first appeared in a book written by Kevin J. Anderson, "Jedi Search". Luuke Skywalker and Joruus C'Baoth were characters in Timothy Zahn's Thrawn trilogy.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Compared to... x.264?

    • Re:There really aren't any marketing people in OSS (Score:5, Informative)

      by serviscope_minor ( 664417 ) on Friday June 21, 2013 @09:45AM (#44070185) Journal

      Daala? That will play well in test/focus groups - I'm certain of it.

      Hmm, yeah, because the input of "focus" groups are well known for their role in chosing video codecs. So, let's look at the real commercial codecs out there:

      ISO/IEC 11172 aka MPEG-1
      Dirac Pro aka SMPTE 2042-1-2009 VC-2
      H.222 aka H.262 aka MPEG-2 Part 2 aka ISO/IEC 13818-2
      MPEG-4 er, which was that, Part 2 aka H.263 aka ISO/IEC 14496-2 or Part 10 AVC aka h.264 aka ISO/IEC 14496-10
      MS MPEG-4v3 aka (unofficially) Divx ;-)

      etc.

      So yeah, Daala is terrible by those standards

      So, basically you're randomly grousing about OSS is nonsensical and in complete contrast to reality and apparently this has caused your post to be upmodded.

      I expect I'll be downmodded by whoever modded you up, but I have karma to burn so what the hell.

      • Re: (Score:2)

        by stdarg ( 456557 )

        The codecs you listed have nice technical sounding names, except Dirac. Daala is like Dirac but more "dull." It's subjective obviously but I agree with OP, it's a terrible sounding name.

        However, many end users will end up only knowing the container format. If it's packaged as mp4 or mkv, they won't know the difference. If it has its own container format, who knows -- hopefully it'll have a better name, though I doubt it (Ogg instantly springs to mind).

        • Re: (Score:1)

          by gnupun ( 752725 )
          Give me a dalla

        • If it has its own container format, who knows -- hopefully it'll have a better name

          Well let's hope it does, because you can never have too many.

          There's an xkcd cartoon, but I can't be arsed to find it and it's not my turn to do the obligatory.

      • Re: (Score:3)

        by tlhIngan ( 30335 )

        MPEG-4 er, which was that, Part 2 aka H.263 aka ISO/IEC 14496-2 or Part 10 AVC aka h.264 aka ISO/IEC 14496-10
        MS MPEG-4v3 aka (unofficially) Divx ;-)

        Actually, MS MPEG4 is a form of h.263. In fact, MPEG4 Part 2 is also known as DivX/Xvid/etc, and to be more correct still, they fall under MPEG4 Part 2 Advanced Simple Profile (ASP).

        MPEG4 Part 10 (h.264) is Advanced Video Codec (AVC).

        Of course, one needs to realize that MPEG4 is a comprehensive standard and nothing "implements" MPEG4 - it's just a related group

    • It's the same "nerds can't think of good names" shit all over again. See the "Oh Brother, Where Art Thou?" Simpsons episode for reference.

  • Essential Features.. alpha support, lossless. (Score:5, Insightful)

    by thesupraman ( 179040 ) on Friday June 21, 2013 @08:55AM (#44069777)

    If you want to have a good solid niche for this (always helps) then.
    1 - support a reasonably efficient lossless mode (several others have this, but it is alsways useful)
    2 - support ALPHA channels (32bit, RGBA, YUVA) - this is not trivial but very worthwhile, basically ZERO of the modern codec support this.

    alpha channels are a requirement for many composition/editing/video production workflows, and yet the supporting codecs are old, clunky,
    and painful to use.

    good alpha channel support is not trivial, but is usually not major also.

    For extra points support lossless on alpha, and lossy on the other channels, that is a VERY good option for many workflows.

    Gives alpha and lossless, you are pretty much guaranteed professional users.

    • Wikipedia claims that VP9 does/will support alpha channel

      • Re:Essential Features.. alpha support, lossless. (Score:5, Informative)

        by thesupraman ( 179040 ) on Friday June 21, 2013 @09:23AM (#44069991)

        Yes, as far as I can tell thats a pretty solid 'will', closer to a 'may', but alpha there as far as I can tell is just another
        channel with no special consideration, unfortunately.

        But of course, the more the merrier, its just a very under supported requirement, and one that is heavily used in content creation circles.

        Most end up having to use png or target image sequences, or quicktime/animation codec for support, which are somewhat poor workflows.

    • Re: (Score:1)

      by Anonymous Coward

      Apple Prores 4444 is YUVA 0 it's not lossless but its close enough for most applications.

      • Great!
        Now can I please have a source implementation so I can use it directly?
        Can i have a free codec for all my machines (windows edit stations, linux render clusters?)

        I'm not saything they dont exist, there are several, they all have issues of one form or another, though.

        • Have you tried contacting the Xiph guys at all?

          If email isn't working try IRC - they probably have a channel the devs hang out in, or their mailing list.

          You have a nice suggestion and good grounds for it being a feature - do a little lobbying and see if you can get one of the devs to champion the feature for you!

      • Apple Prores 4444 is YUVA 0 it's not lossless but its close enough for most applications.

        The whole point of lossless formats is that you can move back and forth between them *as many times as you like* without ever losing *any* information. No non-lossless codec is 'close enough' to lossless for this purpose. It's like the difference between 'not pregnant' and 'only a bit pregnant'.

    • We've never even been able to get a lossy image/lossless alpha for the Web, what makes you think it's going to appear for video first?

    • We already have good codecs for professional use, lossy and lossless, that support alpha channels. For lossless there's Animation or DPX, for lossy Prores or DNxHD, etc. These codecs are standardized and supported by a wide variety of hardware and software. I think anybody doing this type of work professionally is going to be using already proven established codecs. There's nothing old, clunky, or painful about these (maybe animation).

    • From the Daala wiki:

      Basic features
      YUV 4:4:4, 4:2:2 , 4:2:0 subsamplings, 8-bit, 10bit.
      Alpha channel — need testing material!
      8-bit RGB compatible mode? (e.g. YCoCg, internally or at least flagging for it)
      Efficient 3D? — need testing material!
      Lossless?
      The value of this is disputable. If nothing else it's arguable that stuffing lossless into a lossy format may be the only way to get lossless into many people's hands. Also, see below
      Good support for decode side droppable frames?
      Hopefully the referen

  • I'm sure its a worthy project and no doubt based on very solid maths and engineering. However I'm also sure it'll be forgotten about this time next week. There are too many codecs fighting it out already - yet another one is just a bit more noise in the background. Sorry, but thats just the way it is.

    • Re:Another day, another codec. (Score:5, Interesting)

      by LourensV ( 856614 ) on Friday June 21, 2013 @10:10AM (#44070409)

      Those existing codecs are all very similar technically, and riddled with patents. If Monty can make something new (and he can, see CELT) and work around those patents (and he can, see Vorbis, Theora), then it's definitely a welcome addition. And a codec doesn't have to dominate to be useful; Vorbis is widely used (Wikipedia, all sorts of software that plays sound and music including a lot of if not most video games) and supported on a lot of platforms (including hardware players and set-top boxes) even if it never did completely replace MP3 and AAC. If nothing else, having a free and unencumbered option will keep the licensors of the proprietary codecs at least somewhat honest.

      Incidentally, isn't it about time for Monty to get an EFF Pioneer award? He's been very successfully working on freely usable audio and video codecs for well over a decade now, starting at a time when many people didn't believe that a non-encumbered audio or video codec was even possible. Someone with his skills could probably make a very good living in proprietary codec development, but he chose to start Xiph.org and fight the good fight (and now works for Red Hat). He belongs in that list [eff.org] IMHO.

      • Re: (Score:2)

        by Sloppy ( 14984 )

        I agree. Monty's a hero, and the real deal. We love you, Monty!

      • Long ago, Xiph had a video code project they called Tarkin. When On2 gave out VP8, they abandoned Tarkin to focus on their own implementation of VP8 with a few tweaks, which they called Theora.

        Here's hoping Daala makes it.

      • He's been very successfully working on freely usable audio and video codecs for well over a decade now, starting at a time when many people didn't believe that a non-encumbered audio or video codec was even possible.

        Monty and Xiph have done pretty well with audio codecs, but they need to stay the HELL away from video codecs.

        Theora/VP3 was a nightmarish debacle that we're still suffering from. Thank god Google took the reins by releasing VP8, and developing it themselves, rather than handing it over to Xiph

        • I think the only "debacle" about Theora/VP3 was that it ended up languishing for half a decade with an "alpha" label after it was actually done (in the "1.0" sense). It wasn't bad at all for the time it was initially created, and if it had gotten formally finalized so people didn't think it "still wasn't ready" it would have had a much better chance of catching on.

          It would still be a "second rate" video codec by TODAY's standards, but being plenty good enough for most purposes (you can't tell me top qualit

          • it ended up languishing for half a decade with an "alpha" label after it was actually done

            It was bitstream stable (which would have been very nice to know at the time, rather than years later), but the software wasn't done. The alphas performed horribly, and turned out video that looked like crap. This may have simply been a few features turned off in #IFDEFs for development, but either way, the public couldn't have used the alphas for real work, even if they wanted to.

    • I agree, except if it ends up using smaller bitrate and less computation for same quality video then HEVC, which is their goal. In that case, it would instantly change from boring to magic.

  • Why still use blocks? (Score:4, Interesting)

    by pipatron ( 966506 ) <pipatron@gmail.com> on Friday June 21, 2013 @09:16AM (#44069947) Homepage

    I'm a bit worried about the big focus on "blocks" for such a video codec. Originally, the blocks used in the JPEG image coder was put there to make sure that you could stream-encode images using reasonably cheap silicon back in the eighties. No one really wants the blocks, they were a necessary limitation. Using the same algorithm as JPEG but removing the blocks gives a serious quality boost.

    This codec will never run on hardware that can't handle more than 16 x 16 pixels at once. The lowest specs that will encode these frames will be hand-held cameras, which will have more than enough ram to buffer at least two full frames, and use a small FPGA for encoding/decoding. Everything else will be decoded by a GPU directly to the framebuffer, and likely encoded by the same GPU. Even server farms have these for processing media.

    There's also no issue with streaming as far as I know. Both DCT and Wavelet based coders can packetize the important bits in a frame first, and the less important bit later, so that a slow connection can still decode a degraded image even if not all bits are received. This without splitting the image into blocks.

    • I thought the blocks were used to provide a reasonable limit on the number of terms necessary to effectively describe the function in the "time" space using a DCT. The large the block, the more terms are necessary. I don't know enough about DCT to know how the number of terms scales with individual accuracy required and block size, but I would think a move away from that kind of a transform would be necessary to encode entire frames in one go with any hope at a highly efficient compression ratio.

    • Re:Why still use blocks? (Score:5, Informative)

      by cbcbcb ( 567490 ) on Friday June 21, 2013 @09:28AM (#44070031)
      You still need to subdivide the image for motion estimation, as some parts of a moving image move at different rates to others. Subdividing into blocks gives you O(N) complexity in the size of the input image, whereas doing a DCT transformation has O(N log N) complexity.

    • It would be great if the blocks were independent, so you could parallelize the work by a huge factor. I guess block boundary effects are the problem, but they don't exactly constitute all the work. A great deal of scientific computing (e.g. fluid dynamics) is done by splitting the problem space into blocks which can be run on different nodes of a cluster, and while a lot of communication is needed between nodes, there are certainly benefits from such parallelism.

      Another interesting idea (which I've proba

      • Re: (Score:2)

        by lgw ( 121541 )

        I think that was pretty much the basic idea behind tarkin. It didn't end well. Seems temporal artifacts are very jarring.

        • Wow, thanks for the info. I remember reading about Tarkin back in the day, but somehow this idea was never advertised. I worked in image processing around 2002 and later came up with this idea, so I guess it wasn't particularly original :-/

      • But video can easily be made to run in parallel simply by encoding several frames at once.

        That idea with the 3D voxel blob is something I've been thinking about for doing simultaneous frame rate and resolution conversion between interlaced source and destination video formats. Sadly I still haven't managed to start coding on that. Maybe it will fail for the same reason that the video encoder failed. :/

    • Using the same algorithm as JPEG but removing the blocks gives a serious quality boost.

      So doing DCT on the entire image in one go will improve things? Otherwise, there's not much of the JPEG algorithm left.

      People have been fiddling round with increasing block sizes for ages, and going arbitrarily large does not necessarily improve things. 16x16 seems good, but that's not removing the blocks, merely doing a minor tweak.

    • Originally, the blocks used in the JPEG image coder was put there to make sure that you could stream-encode images using reasonably cheap silicon back in the eighties.

      Your idea is nonsense. Whatever the reason for blocks in JPEG, video codecs NEED blocks. Full stop. Motion prediction/estimation/compensation/vectors works on the block level. The frame level isn't granular enough, and pixel-level has far too much overhead.

      H.120 was the first standard video codec, and it didn't use blocks. It was not at a

      • Originally, the blocks used in the JPEG image coder was put there to make sure that you could stream-encode images using reasonably cheap silicon back in the eighties.

        Your idea is nonsense. Whatever the reason for blocks in JPEG, video codecs NEED blocks. Full stop. Motion prediction/estimation/compensation/vectors works on the block level. [...] H.264 introduced 8x8 and 4x4 macroblocks, in addition to the standard 16x16 macroblock, because the motion vectors on smaller blocks allows it to eliminate more temporal redundancy. VP9 is adopting larger macroblock sizes as well, but that really only helps on a small amount of HD content.

        You're sort of contradicting yourself here. You're saying that blocks are necessary. Then you're saying that fixed-size blocks are bad, because you get a better result when you discard the actual encoder block size and impose a motion vector granularity that is better tailored to the data in question. So why not simply decouple the encoder and motion estimators and let the motion estimator run with a dynamic size, maybe even without a square/rectangle restriction. Maybe the motion estimators could then be f

        • You're sort of contradicting yourself here.

          Don't blame me, just because you don't understand the subject.

          Besides all that, you're ignoring most of my post. I don't concede that non-block based encoding of JPEG or I-frames is more efficient... Unless you've got a source, I'm going to assume your original point is you making crap up, just like your reply here.

  • Wow, were do I get my drive?
  • Huh, the lapped transform is not quite "beyond" next-gen codecs like HEVC. In fact, the [over]lapped transform is already part of the WMV9/VC-1 codec, and it didn't really have a significant impact on coding efficiency (it does tend to look more blurry than blocky at very high quantization, but both cases look like crap at these levels)

    • Re: (Score:2)

      by l3v1 ( 787564 )
      Agreed, it doesn't seem or look like to be anything next-gen in it, I read it through and through and I couldn't find anything revolutionary in it. That in itself shouldn't be a big issue, one of the most important points being to develop on free non-patent-encumbered ideas. So I'm OK with it, depending on how far they'll get with it implementation-wise. But I still don't see why would it be next or next-next gen. We'll have to wait for the "Coming Soon" to arrive.
  • I already have to serve 2 versions of a video to make sure everyone can see it on the web. It was not obvious to me that we needed another codec.

Slashdot Top Deals

"Your stupidity, Allen, is simply not up to par." -- Dave Mack (mack@inco.UUCP) "Yours is." -- Allen Gwinn (allen@sulaco.sigma.com), in alt.flame

Close