Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Next-Next Generation Video: Introducing Daala

Soulskill posted about a year ago | from the you-can-tell-by-the-pixels dept.

Graphics 86

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!"

cancel ×

86 comments

Sorry! There are no comments related to the filter you selected.

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

Anonymous Coward | about a year ago | (#44069621)

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

Re:There really aren't any marketing people in OSS (1)

Anonymous Coward | about a year ago | (#44069661)

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.

Re:There really aren't any marketing people in OSS (2)

LourensV (856614) | about a year ago | (#44070693)

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.

Re:There really aren't any marketing people in OSS (2)

bzipitidoo (647217) | about a year ago | (#44070883)

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:There really aren't any marketing people in OSS (1)

Anonymous Coward | about a year ago | (#44072785)

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:There really aren't any marketing people in OSS (-1)

Anonymous Coward | about a year ago | (#44069793)

Sure they didn't name it after some veneral disease from India?

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

Anonymous Coward | about a year ago | (#44070051)

Compared to... x.264?

Re:There really aren't any marketing people in OSS (0)

Anonymous Coward | about a year ago | (#44070211)

Pardon me - that was meant to be an h, not an x.

Re:There really aren't any marketing people in OSS (0)

Anonymous Coward | about a year ago | (#44072389)

Sorry, I meant x264.
Also, the s03e10 version is much more popular than the s03e11 version, which yields no search results on a uh... certain research data collaboration website, at least for a particularly popular um... test... data series.

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

serviscope_minor (664417) | about a year ago | (#44070185)

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:There really aren't any marketing people in OSS (1)

stdarg (456557) | about a year ago | (#44070397)

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).

So make one for them. (0)

Anonymous Coward | about a year ago | (#44070467)

Because the codecs he listed are precisely the sort of names that the AC was whining about.

No, much easier to bitch about it and hope like hell that everyone stays on h.264/5 because you lambasted the fucking NAME.

Ferfecksake, grow up.

Re:So make one for them. (-1)

Anonymous Coward | about a year ago | (#44070587)

Because the codecs he listed are precisely the sort of names that the AC was whining about.

No, incorrect, wrong. The name "Daala" sounds gay, as many OSS names do. (GIMP, Amarok, Crunchbang, Ubuntu, Trisquel, Choqok, Blogilo, Kwooty, LibreOffice, Banshee, the list goes on....) Names like MPEG-4v3, H.264, HuffyYUV, Cinepak, Lagarith sound rather technical. Which is pretty far from gay.

Only because you're gay. (0)

Anonymous Coward | about a year ago | (#44070879)

Sorry, you have a defective brain?

If you make up a name for it, then it doesn't matter what name it has, it'll have the one you've offered to them.

Which you would not be calling gay, would you.

Re:So make one for them. (0)

Anonymous Coward | about a year ago | (#44070907)

Because the codecs he listed are precisely the sort of names that the AC was whining about.

No, incorrect, wrong. The name "Daala" sounds gay, as many OSS names do. (GIMP, Amarok, Crunchbang, Ubuntu, Trisquel, Choqok, Blogilo, Kwooty, LibreOffice, Banshee, the list goes on....) Names like MPEG-4v3, H.264, HuffyYUV, Cinepak, Lagarith sound rather technical. Which is pretty far from gay.

right, throw Huffy onto the name of something and claim that it sounds technical instead of gay? Really? Lagarith maybe could sound technical if it is supposed to be be like logarithm, but then again it also sounds like it could just be some extra elf from lord of the rings. Cinepak, ok I guess so, taking pieces of a couple of words maybe like Cinema and pack, and string them together (but how is that different than Libre and Office)

Re:So make one for them. (-1)

Anonymous Coward | about a year ago | (#44071325)

right, throw Huffy onto the name of something and claim that it sounds technical instead of gay?

Yeah, HuffyYUV employs Huffman coding and Huffy is also the name of a pretty cool bicycle company back in the day. That's not gay, it's sporty.

taking pieces of a couple of words maybe like Cinema and pack, and string them together (but how is that different than Libre and Office)

Because Libre is a gay word. As if that wasn't bad enough, it's also heavily endorsed by Richard Stallman has his Libre-loving followers. I challenge you to find ANY woman who claims to have had consensual sex with him sans a direct monetary translation prior to or immediately following intercourse.

Re:So make one for them. (0)

Anonymous Coward | about a year ago | (#44072649)

How you resisted an Alan Cox joke I'll never know. Anyhow, Libre is French-sounding, which was all the argument you needed.

Re:So make one for them. (-1)

Anonymous Coward | about a year ago | (#44074789)

Do you know what sounds gay?

Longhorn.

Longhorn is a gay unprofessional name.

Re:There really aren't any marketing people in OSS (1)

gnupun (752725) | about a year ago | (#44073507)

Give me a dalla

Re:There really aren't any marketing people in OSS (1)

Hognoxious (631665) | about a year ago | (#44073567)

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:There really aren't any marketing people in OSS (0)

Anonymous Coward | about a year ago | (#44070675)

Well, we know where you're coming from. When you're not trolling Wayland discussions, you're known as a die-hard Linux zealot. Thus, the faggotry that inspires the name of many OSS projects is not only acceptable to you, it's appealing on a level the rest of us would find very uncomfortable. Furthermore, anyone who denigrates an OSS project in even the smallest, microscopic degree is going to get flack from extremists like yourself. So, you like the name "Daala." BIG SURPRISE! No doubt you're in the minority and no doubt you're very proud [slashdot.org] being there.

Re:There really aren't any marketing people in OSS (0)

Anonymous Coward | about a year ago | (#44071217)

Thus, the faggotry that inspires the name of many OSS projects

Do you realize that you use of the term 'faggotry', particularly in relation to totally irrelevant matters like OSS, is a sure sign that you are gay, but repressed? You really need to work with suitable professionals toward being 'out and proud' instead of 'repressed and bigoted'.

Re:There really aren't any marketing people in OSS (1)

Em Adespoton (792954) | about a year ago | (#44071505)

Thus, the faggotry that inspires the name of many OSS projects

Do you realize that you use of the term 'faggotry', particularly in relation to totally irrelevant matters like OSS, is a sure sign that you are gay, but repressed? You really need to work with suitable professionals toward being 'out and proud' instead of 'repressed and bigoted'.

Well, it's also possible that he's inferring the GGP spent too much time on smoke breaks and not enough applying himself.

Which brings me to another point: it seems like the original poster in this thread (and the "name sounds gay" commenters) like names that sound American or are acronyms. If the name sounds Indian or African (and most of the OSS names mentioned are one or the other) then it sounds "gay".

These are the same people who groused about Nintendo for the Wii. My guess is that to most of the computer-using world, software names like "Windows" sound significantly odder (and are more unpronouncable) than names like Daala.

That said, I doubt most people will ever see this name, just as most never see Theora anywhere, but (might) know what an MKV is.

Re:There really aren't any marketing people in OSS (2)

tlhIngan (30335) | about a year ago | (#44070973)

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 of standards, including the use of a subset of the QuickTime MOV format (Part 14) for the containers, various video codecs (including h.263-based ones like DivX and the like, h.264), audio codecs (preferred AAC) and many other standards, including stuff like DRM, bitstream formats, subtitles, integration testing, reference software, hardware implementations, etc.

Effectively, MPEG4 is a "meta standard" of standards - it really is just an accumulation of standards others have written.

Re:There really aren't any marketing people in OSS (1)

ArcadeMan (2766669) | about a year ago | (#44070649)

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.

Re:There really aren't any marketing people in OSS (0)

Anonymous Coward | about a year ago | (#44074641)

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

It's simple. It was named after the Lamai Daala.

Terminology (-1)

Anonymous Coward | about a year ago | (#44069687)

I was getting tired of our next gen consoles such as the xbox360. Stoked for the gen-after-next console like the ps4

Patent Tolls heading your way (0)

Anonymous Coward | about a year ago | (#44069711)

That I'm sure of. If they can go after Google and VP8 I am sure that you will be an easier target.

Sad for things to get like this but if IV can go after people who embed URL's in HTML emails the world is quickly going bonkers.

Re:Patent Tolls heading your way (5, Interesting)

bill_mcgonigle (4333) | about a year ago | (#44069771)

It's the submarine patents that are the bigger worry. Since this codec is based on work that's come from some academic research papers, one can imagine a sufficiently wealthy litigation-mad megalocorp paying developers to stay on top of research and file patent applications citing obvious implementation details and then keeping them under the surface until it's sufficiently advantageous to allow them to surface. This process is 100% the opposite of the intention of the Constitutional provision for IP.

BTW, the posted whitepaper is really nicely done - good job Xiph team. In a free world everybody would rejoice and be happy for your efforts.

Re:Patent Tolls heading your way (0)

Anonymous Coward | about a year ago | (#44070273)

Where I work we've already been sued for using lapped transforms, even though we don't use any yet. There are already broadly interpretable patents that attempt to capture the concept of 'using lapped transforms for video'. Nobody skilled in the art could have POSSIBLY thought of using overlapping matrices in a matrix based compression system. Go USPTO...

Re:Patent Tolls heading your way (0)

Anonymous Coward | about a year ago | (#44070953)

If it's based on published academic papers, then those academic papers are prior art to any patents...

Re:Patent Tolls heading your way (0)

Anonymous Coward | about a year ago | (#44073495)

Or those academic research papers were corporate funded and though published, the author likely wrote a corporate patent with the sponsor.

Essential Features.. alpha support, lossless. (5, Insightful)

thesupraman (179040) | about a year ago | (#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.

Re:Essential Features.. alpha support, lossless. (4, Informative)

qbwiz (87077) | about a year ago | (#44069937)

Wikipedia claims that VP9 does/will support alpha channel

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

thesupraman (179040) | about a year ago | (#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:Essential Features.. alpha support, lossless. (0)

Anonymous Coward | about a year ago | (#44071431)

lossy alpha seems like a bit of a lose

Re:Essential Features.. alpha support, lossless. (1)

Anonymous Coward | about a year ago | (#44070241)

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

Re:Essential Features.. alpha support, lossless. (1)

thesupraman (179040) | about a year ago | (#44070853)

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.

Re:Essential Features.. alpha support, lossless. (1)

Mr Thinly Sliced (73041) | about a year ago | (#44071253)

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!

Re:Essential Features.. alpha support, lossless. (2)

mikechant (729173) | about a year ago | (#44071293)

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'.

Re:Essential Features.. alpha support, lossless. (1)

ArcadeMan (2766669) | about a year ago | (#44070663)

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?

Re:Essential Features.. alpha support, lossless. (1)

DreadPiratePizz (803402) | about a year ago | (#44071227)

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).

Re:Essential Features.. alpha support, lossless. (1)

BaronAaron (658646) | about a year ago | (#44071829)

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 referencing structure will be flexible enough to enable this even if it's not an intentional feature.

Another day, another codec. (1, Insightful)

Viol8 (599362) | about a year ago | (#44069885)

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. (5, Interesting)

LourensV (856614) | about a year ago | (#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:Another day, another codec. (1)

Sloppy (14984) | about a year ago | (#44070557)

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

Re:Another day, another codec. (1)

bzipitidoo (647217) | about a year ago | (#44070933)

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.

Re:Another day, another codec. (0)

Anonymous Coward | about a year ago | (#44071047)

I think you meant VP3.

Re:Another day, another codec. (5, Informative)

Monty Montgomery (2853719) | about a year ago | (#44072003)

We abandoned Tarkin, but not because of VP3. It was an interesting crazy idea that simply wasn't workable.

Tarkin was an attempt to replace motion compensation with a directional 3D wavelets that could predict across time. It had... disturbing... encoding artifacts.

Re:Another day, another codec. (1)

lgw (121541) | about a year ago | (#44072715)

I bet! Sounds like a very cool visual effect, however.

Re:Another day, another codec. (2)

evilviper (135110) | about a year ago | (#44071803)

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 to die on the vine, and make a depressing reappearance a decade later...

Re:Another day, another codec. (0)

Anonymous Coward | about a year ago | (#44073149)

STFU. VP3 was bad because it's from On2.

Re:Another day, another codec. (1)

evilviper (135110) | about a year ago | (#44073421)

STFU. VP3 was bad because it's from On2.

VP3 was great when it was released in 2000. It was still damn impressive when On2 open sourced it in 2001. Nothing else out there did in-loop deblocking like VP3, which made it perform incredibly well for low-bitrate encoding. Numerous companies like AOL, Adobe/Macromedia licensed it.

But a DECADE LATER, when Xiph finally released a stable version of Theora, quality was really NO BETTER, and now it had to compete with much better, and entrenched players like H.264, which obviously took off, while VP3 and Theora never did.

At the rate Xiph.org moves, you can just sit around and WAIT for patents to expire.

If Xiph.org had just ported VP3 over to Linux, and integrated it into MPlayer, ffmpeg, and anything else around at the time, I fully expect it would have easily overtaken Divx, and H.264 wouldn't have had a chance. There wouldn't have been any debate over using the codec with the video tag, or WebRTC.

I've been saying this for years. Low and behold, Google did exactly what Xiph should have done, when releasing VP8. Sadly, they dropped the ball pretty early, and didn't follow through on their promises to reencode all of YouTube, and removing H.264 from Chrome. But they did a hell of a lot better, and only a short while after Theora finally struggled into the world.

Re:Another day, another codec. (1)

fsterman (519061) | about a year ago | (#44103255)

Agreed, Xiph wanted to create a clean codec (which is still the problem with VP8) but you are right: they just didn't balance the engineering and comp-sci effectively. They could have shot for incremental progress, releasing something new every couple of years. Instead, they had a few underpaid open-source enthusiasts working on it for a decade.

That being said, when it came to negotiations, it was REALLY important that Vorbis was around to give everyone an idea that open source codecs were at least viable. Had Google just seen a standard proposal, they wouldn't have invested $100m in buying up On2!

Re:Another day, another codec. (1)

evilviper (135110) | about a year ago | (#44103725)

it was REALLY important that Vorbis was around to give everyone an idea that open source codecs were at least viable.

I do believe Musepack was around earlier, outperforming Vorbis (and *everything else*) and is still being developed.

Re:Another day, another codec. (1)

fsterman (519061) | about a year ago | (#44127837)

I was talking about video, not audio.

Re:Another day, another codec. (1)

evilviper (135110) | about a year ago | (#44128613)

I was talking about video, not audio.

You specifically said "Vorbis" which is audio.

I'll assume, now, that was a typo.

Re:Another day, another codec. (1)

Dr.Dubious DDQ (11968) | about a year ago | (#44073891)

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 quality is incredibly important for short video clips while the internet is still being choked by clips being distributed as crappy animated GIFs...) it would probably at least be something with wide enough support for regular use even now.

Re:Another day, another codec. (1)

evilviper (135110) | about a year ago | (#44073943)

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.

Re:Another day, another codec. (1)

should_be_linear (779431) | about a year ago | (#44070527)

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? (3, Interesting)

pipatron (966506) | about a year ago | (#44069947)

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.

Re:Why still use blocks? (2)

Overzeetop (214511) | about a year ago | (#44070009)

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? (4, Informative)

cbcbcb (567490) | about a year ago | (#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.

Re:Why still use blocks? (0)

Anonymous Coward | about a year ago | (#44070049)

We're talking about incremental improvements to existing techniques. We're talking about minimal changes to the existing hardware and software implementations. You're talking about throwing all that out and starting fresh. Go ahead, but so far no one has succeeded with a non-block-based video codec.

Re:Why still use blocks? (1)

pipatron (966506) | about a year ago | (#44075239)

Yeah, but starting fresh is what this codec is supposed to be all about, hence my "worries" about the block-thought.

Re:Why still use blocks? (2)

TeknoHog (164938) | about a year ago | (#44070087)

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 probably mentioned before, and isn't exactly new anyway) is to treat the video as a 3D voxel blob, with time as the third dimension. Split this into cubical blocks (if only for streaming) and use a 3D Fourier (wavelet, cosine etc.) transform and keep the most significant elements. This way you'll get a natural tradeoff between spatial and temporal accuracy, depending on the block content.

Re:Why still use blocks? (1)

lgw (121541) | about a year ago | (#44072769)

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

Re:Why still use blocks? (1)

TeknoHog (164938) | about a year ago | (#44073371)

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 :-/

Re:Why still use blocks? (0)

Anonymous Coward | about a year ago | (#44073107)

>It would be great if the blocks were independent, so you could parallelize the work by a huge factor

They are, to an extent. The filtering can be done in parallel and afterwards, DCT can be done in parallel.

>Another interesting idea (which I've probably mentioned before, and isn't exactly new anyway) is to treat the video as a 3D voxel blob, with time as the third dimension. Split this into cubical blocks (if only for streaming) and use a 3D Fourier (wavelet, cosine etc.) transform and keep the most significant elements. This way you'll get a natural tradeoff between spatial and temporal accuracy, depending on the block content.

This approach was tried in Tarkin (the first Xiph's video codec attempt). It failed. 'Nuff said.

Re:Why still use blocks? (1)

pipatron (966506) | about a year ago | (#44075229)

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. :/

Re:Why still use blocks? (1)

serviscope_minor (664417) | about a year ago | (#44070097)

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.

Re:Why still use blocks? (1)

evilviper (135110) | about a year ago | (#44071719)

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 all practical, mostly because of that decision. The next codec built on that, corrected that mistake, and became the first practical codec: H.261, which MPEG-1 was later based on.

I also don't see how JPEG could benefit from elimination of macroblocks... The DPCM encoding of one block to the next reduces size significantly.

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

You'll need a source for that... I can tell you that block-based codecs with in-loop deblocking (like H.264 I-frames) outperform non-block based codecs such as JPEG2000:

http://etill.net/papers/jvt-d039.pdf [etill.net]

This codec will never run on hardware that can't handle more than 16 x 16 pixels at once

Except modern video codecs benefit from going THE OTHER WAY. 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.

Re:Why still use blocks? (1)

pipatron (966506) | about a year ago | (#44075173)

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 further improved if they weren't stuck with those sizes.

I simply don't agree that the quantizer/decimator must be limited to a given block size just because the motion estimator algorithm wants to use blocks to predict motion.

Re:Why still use blocks? (1)

evilviper (135110) | about a year ago | (#44085909)

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.

Re:Why still use blocks? (0)

Anonymous Coward | about a year ago | (#44074895)

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

Do you have a source for this? I don't see how JPEG quantization tables would work for full-image transforms.

The codecs that do full-image transforms, like Dirac, tend to be wavelet based.

Re:Why still use blocks? (1)

pipatron (966506) | about a year ago | (#44075135)

No other source than having tried it myself for a project that didn't have the memory restrictions or hardware, but severe code space restrictions, and simply running the DCT on the whole image and quantizing and encoding the results with huffman/arithmetics gave a visually more pleasant result with a resulting smaller filesize. Original research I guess.

I wonder who their focus group is (0)

Anonymous Coward | about a year ago | (#44070173)

I can see the new lapped transform improving the video quality in all kinds of situations -- particularly in cartoon animation, which has historically suffered through one codec after another.

I'm holding out hope that this codec supports subtitles as filters, so we can bake them in without actually baking them in, if you catch my drift. One of the biggest challenges I've faced when working with video encoding is that container formats are notoriously unsupported across the entire spectrum of video players.

Re:I wonder who their focus group is (2)

Junta (36770) | about a year ago | (#44070347)

I'm holding out hope that this codec supports subtitles as filters, so we can bake them in without actually baking them in, if you catch my drift. One of the biggest challenges I've faced when working with video encoding is that container formats are notoriously unsupported across the entire spectrum of video players.

The issue being that whatever inconsistencies you are hitting won't be addressed by shuffling the subtitle track awkwardly into the video stream somehow. A player not being able to interpret an SSA/ASS stream won't suddenly be able to render them because it comes in the video part of the container. This just moves the problem form one part to another, and does so in a way without technical benefit.

If the meat of your gripe is that a lot of things do not understand matroska and you are really thinking that such a trick will make .mp4 servicable, that would be incorrect too. Already you can put SSA or vobsub into mp4, but because it isn't part of the mp4 spec, many .mp4 players ignore the track. The same exact thing would happen if Daala somehowe hypothetically had subtitles in it, Daala in .mp4 would be something that those players would just fail to play.

Re:I wonder who their focus group is (1)

lgw (121541) | about a year ago | (#44072829)

I think ACs point was that by moving subtitles from a container thing to a stream thing (but still a distinct layer you can enable or disable) the world would be a better place, because codec support is far more common than container support. There are plenty of players that support h.264, but only in an mp4 container, not an mkv container, and not I suspect for any technical reason, just marketing requirements written that way.

If you had to support subtitles to claim to support the codec, it would be a win - not because of technical benefit but marketing benefit. Having the video "just fail to play" if the player couldn't do it right would be a huge win.

Re:I wonder who their focus group is (1)

sjames (1099) | about a year ago | (#44072859)

That just creates another layer of container.

Re:I wonder who their focus group is (0)

Anonymous Coward | about a year ago | (#44077889)

Yo dawg...

Exciting! (1)

Tighe_L (642122) | about a year ago | (#44070403)

Wow, were do I get my drive?

Not quite next-gen (1)

Sulik (1849922) | about a year ago | (#44070929)

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:Not quite next-gen (1)

l3v1 (787564) | about a year ago | (#44071259)

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.

Re:Not quite next-gen (0)

Anonymous Coward | about a year ago | (#44071281)

If you would RTFA you would see that it's not the usage of lapped transform that gives this a next-gen quality, since the article well mentions previous decades papers on such algorithms, but the target size/bitrate they want to get out of it.

Again a new codec? (1)

manu0601 (2221348) | about a year ago | (#44076229)

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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>