×

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!

LGPL H.265 Codec Implementation Available; Encoding To Come Later

timothy posted about 8 months ago | from the fewer-bits-more-pixels dept.

Software 141

New submitter Zyrill writes "The German company Stuttgarter Struktur AG has released a free and open source implementation of the H.265 codec, also termed 'High Efficiency Video Coding (HEVC)' which is now available on Github. At the same video quality, H.265 promises roughly half the bitrate as compared to H.264. Also, resolutions up to 8K UHD (7680 × 4320 px) are supported. The software is licensed under LGPL. Quoting from the homepage where the software is also available for download: '[This software] is written from scratch in plain C for simplicity and efficiency. Its simple API makes it easy to integrate it into other software. Currently, libde265 only decodes intra frames, inter-frame decoding is under construction. Encoding is planned to be added afterwards.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

141 comments

chicken and the egg problem? (-1)

Anonymous Coward | about 8 months ago | (#44766167)

So, the created the decoder to decode what? If you can't encode something why release the decoder?

Re:chicken and the egg problem? (2, Informative)

MetalliQaZ (539913) | about 8 months ago | (#44766189)

The decoder is open source, with the open source encoder to follow afterwards. That doesn't mean that there isn't a proprietary encoder already available.

Re:chicken and the egg problem? (5, Insightful)

slaker (53818) | about 8 months ago | (#44766197)

Presumably somebody out in the world currently has a non-open H.265 encoder. You're being obtuse even by AC standards.

There is no chicken and the egg problem (0)

Anonymous Coward | about 8 months ago | (#44766717)

At least not for people who understand evolution, then the answer is obvious.

Codec? (5, Funny)

Hatta (162192) | about 8 months ago | (#44766183)

If there's no encoding, isn't it just a dec?

Re:Codec? (1, Troll)

elfprince13 (1521333) | about 8 months ago | (#44766375)

Dunno why this is moderated funny. Apparently today's batch of mods don't actually know that the word codec is an abbreviation for coder/decoder.

Re:Codec? (3, Informative)

Anonymous Coward | about 8 months ago | (#44767749)

Mods often have to work with the limited options they have at their disposal. For example, you were moderated "-1, Troll", whereas "-1, No sense of humor" would be more appropriate.

Re:Codec? (3, Informative)

adisakp (705706) | about 8 months ago | (#44766721)

If there's no encoding, isn't it just a dec?

Nice joke. Although in the current vernacular of media encoding and playback, codec is commonly used to describe modules or libraries that provide EITHER encoding or decoding (or both). For example, if you get a "codec" pack to play media formats, it's often just the decoders. And when you list codecs in FFMPEG, it tells you whether it supports encoding or decoding as separate flags.

Re:Codec? (5, Informative)

Alsee (515537) | about 8 months ago | (#44766973)

It's not even that. The current version is basically just a glorified slideshow viewer.

The way most video codecs work is they start by storing a full picture once every second or two. These are called key-frames, or intra-frames. The frames in between key-frames are called inter-frames, and this is where 90+% of the real work of a codec happens. These frames are stored as a short description of how the current frame is different than the last key-frame. Instead of storing the full picture you just describe what parts of the picture are moving, or if part of the picture is getting brighter or darker, or if colors are shifting.

Currently, libde265 only decodes intra frames, inter-frame decoding is under construction.

It's essentially a slideshow viewer, showing something akin to a series of JPEG pictures. Basically the entire CODEC is missing, the part that compresses and decompresses all the video frames in between.

-

x265? (0)

Anonymous Coward | about 8 months ago | (#44766195)

How is the x265 project doing these days?

Re:x265? (0)

Anonymous Coward | about 8 months ago | (#44766351)

Seems to be in a similar state to this one, although it's not clear if it can also decode P-frames.

I don't know why Yet Another H265 Implementation deserves special mention, to be honest.

Re:x265? (5, Interesting)

Anonymous Coward | about 8 months ago | (#44767355)

Erm... you should have done more research (or know more about the field).

x265 is an encoder (open source one, even!), and it *does* support encoding the full way - intraframes + interframes (p,b). It's frame-threading is currently in the works along with lookahead - at the end of that, rate control should be there, hopefully. The development is pretty active - well, MCW has employees doing it actually, so duh :D

As fir decoding, naturally there is a libav/ffmpeg code for that, and it is also reasonably feature-complete. It should basically decode standard streams (intra+inter) pretty well. It however hasn't been merged - in august, there was a first call for that on the ML (http://lists.libav.org/pipermail/libav-devel/2013-August/049750.html), but as you can see, it was promptly ignored by the rest of the developers, who mostly prefer to indulge in rewriting some existing code, polishing cosmetics, and implementing 1-purpose game codecs from early 1990s that nobody really cares about :) (Okay, that was a troll - hello elenril o/ - but the factual parts of my posts were meant seriously).

Re:x265? (1)

Anonymous Coward | about 8 months ago | (#44768641)

Erm... you should have done more research

I tried, but the x265 site is undeniably devoid of any useful information.

Re:x265? (0)

Anonymous Coward | about 8 months ago | (#44769949)

Hmm, I guess. There are doom9 discussions, and some documents about the current state and command line usage in the repository. First of all tho, I'm pretty sure it is obvious that x265 is encoder only :D

Basically, my gripe is that people shouldn't comment on stuff they don't have grounded knowledge about. It is tempting, but if you happen to post wrong information, other people without understanding of the field will take it over from you, the misinformation spreads... and look, suddenly 50+ % of stuff that is said on internet is bogus. Comments under this story are painfully wrong in many many cases in this way.

And when it is completely normal that people without understanding state their views as facts, how can you know who talks out of his ass and who not? One cannot, and the result is that people will only start to trust the comments that correspond to their beliefs... which makes it all even worse.

But don't take that personally, that is my gripe at (internet) people at large.

Hardware acceleration? (1)

timeOday (582209) | about 8 months ago | (#44766207)

I have never seen really stable frame-rates in video replay without hardware acceleration, even if CPU load is only a few percent. And this is only more true with higher resolution and tighter compression. Is H.265 basically similar enough to H.264 that the hardware acceleration in our GPUs can be applied to it?

Re:Hardware acceleration? (1)

MetalliQaZ (539913) | about 8 months ago | (#44766247)

I think the problem is drivers. Not until the standard gets more use will the GPU makers add support for the new format.

Other than that, I'm sure the actual decoding work could be implemented on their hardware. Really, as long as the work is massively parallel, they can get the job done with a quickness.

Re:Hardware acceleration? (0)

Anonymous Coward | about 8 months ago | (#44766277)

Is H.265 basically similar enough to H.264 that the hardware acceleration in our GPUs can be applied to it?

that's a clear no.

Re:Hardware acceleration? (4, Interesting)

Khyber (864651) | about 8 months ago | (#44766361)

"I have never seen really stable frame-rates in video replay without hardware acceleration"

My only recommendation is to stop using substandard hardware or switch to a better software player.. I've been doing 1080p video rendering in software just fine using VLC since the days of my 2.4GHz P4 with a 64MB GeForce 2 and 2GB PC2700 DDR1.

Re:Hardware acceleration? (3, Informative)

chmod a+x mojo (965286) | about 8 months ago | (#44766635)

Let me know when I can slap a desktop class processor in my Nexus10 / netbook / other portable device that doesn't chug down battery like my i5 laptop ( that lasts maybe 5 hours doing light work @ 50% brightness ). And before you say anything about 1366x768 and down-scaling the N10 at least has a higher resolution than 1080P.

There are tons of devices out there that need to be able to hardware decode anything above 720P H.264. That is the same reason I absolutely hate that more an more video is being released in the 10bit H.264 format, supposedly for smaller file sizes without visual distortions. Especially by the idiots who way over bitrate their encodes, not only can very few devices hardware decode 10bit, but I can transcode to "shitty" xvid with smaller file sizes ( literally shaving off GBs of 1080P encodes) and no visual quality loss.

If you are going to encode with huge bitrate overages you might as well use 8bit that pretty much anyone and everyone nowadays can easily decode....

Re:Hardware acceleration? (1)

Anonymous Coward | about 8 months ago | (#44767225)

Let me know when I can slap a desktop class processor in my Nexus10 / netbook / other portable device that doesn't chug down battery like my i5 laptop ( that lasts maybe 5 hours doing light work @ 50% brightness ). And before you say anything about 1366x768 and down-scaling the N10 at least has a higher resolution than 1080P.

There are tons of devices out there that need to be able to hardware decode anything above 720P H.264. That is the same reason I absolutely hate that more an more video is being released in the 10bit H.264 format, supposedly for smaller file sizes without visual distortions. Especially by the idiots who way over bitrate their encodes, not only can very few devices hardware decode 10bit, but I can transcode to "shitty" xvid with smaller file sizes ( literally shaving off GBs of 1080P encodes) and no visual quality loss.

If you are going to encode with huge bitrate overages you might as well use 8bit that pretty much anyone and everyone nowadays can easily decode....

I suppose you're an anime fan ? Well you can always reencode the 10bit to 8bit and use that.
But I agree, it's pretty shitty that most fansubbers have gone with a format that can't be decoded entirely in hardware. Even on the desktop, only professional cards like Nvidia Quadro have hardware decoding for 10 bit. Everyone else has to rely on software.
On the other hand most HD rips of films are done in 8bit so no worry there.

Re:Hardware acceleration? (0)

Anonymous Coward | about 8 months ago | (#44767431)

Even on the desktop, only professional cards like Nvidia Quadro have hardware decoding for 10 bit.

You are mistaken, they don't. They might support 10-bit colours for video output, which probably confused you.

Re:Hardware acceleration? (1)

chmod a+x mojo (965286) | about 8 months ago | (#44768561)

Actually it's not only anime groups, some BlueRay rip groups are starting release more and more 10bit, I ran across a few rips that are 10bit so couldn't watch them on the netbook or nexus. And I do transcode to either 8bit or as I said xvid. Either that or I have to watch it on a more powerful but less battery efficient ( portable ) machine or a desktop.

Re:Hardware acceleration? (0)

Anonymous Coward | about 8 months ago | (#44769007)

good news, your Nexus can play 10bit. MX player works. THe only limit is in the OEM video player app.

Re:Hardware acceleration? (3, Interesting)

Khyber (864651) | about 8 months ago | (#44767269)

"Let me know when I can slap a desktop class processor in my Nexus10 / netbook / other portable device that doesn't chug down battery like my i5 laptop"

The processor in your Nexus 10 and netbook are likely already far more powerful than my old P4. The Atom D510 smashes the shit out of a 3.2GHz HT-Enabled P4 in 3DMark CPU Bench, and totally dominates in Sandra (excepting memory bandwidth test.)

Which means you should've been able to do 1080p stutter-free for AGES on CPU alone. Your software is the issue here, not your hardware.

Re:Hardware acceleration? (0)

Anonymous Coward | about 8 months ago | (#44767401)

my Nexus10

I'm sorry to be a dick - if you were complaining that say a weak laptop CPU can't deal with those files, I would feel for you.
But I don't really care that you can't play my encodes on a consumer electronics contraption that serves little purpose. If you have enough money to buy useless things, you can probably afford a normal PC :P

Signed, unconcerned encoder.

Re:Hardware acceleration? (3, Insightful)

Anonymous Coward | about 8 months ago | (#44768051)

My Galaxy Tab 7.7 is MUCH more convenient to use on a train/bus than a desktop/"normal PC" (and it plays regular 1080p H.264 files perfectly, thank you very much). More convenient than any laptop as well. Just because YOU have the time to sit in front of a desktop to watch a video doesn't mean that everyone has to do the same.

My media consumption is made either on my tablet or on my TV's internal H.264 player. I'll probably get a media player to replace the TV's player when its capabilities no longer suit me. Since 99% of all HD videos play perfectly there, I see no reason to waste money on a media player now to play that extra 1%; and there is no way I'll get a full PC on my living room. And most of the people I know are in a similar situation.

If you encode files in a way that nobody will care to decode, your work is useless.

Signed, a more experienced encoder than you.

Re:Hardware acceleration? (0)

Anonymous Coward | about 8 months ago | (#44768301)

You mean, you are entitled to consume on the go? Well, I don't care. I'm not going to adapt my encoding and possibly compromise the quality for your watching manners... figure something yourself, more experienced one.

If you are talking about encoding anime, care you reveal your group/tag, so that we can *compare*? [Mine is OnDeed?] I'm not really a type that would brag about "being experienced", but fact is that I has been encoding anime for years. It sounds like bragging, but I'm quite confident I actually know my field better than most and belong to the better sort of encoders. Well, not that anybody cares about that much...

Re:Hardware acceleration? (1, Redundant)

jedidiah (1196) | about 8 months ago | (#44767437)

> Let me know when I can slap a desktop class processor in my Nexus10

Well that's what you get for using lame hardware and trying to pretend that it's anything but a bad joke.

ARM hardware sucks. Plenty of us will happily point out this fact given any opportunity. You don't even need to use the most extreme examples to demonstrate this either.

"Mobile" devices are like a blast from the past (90s) when it comes to performance.

Re:Hardware acceleration? (1)

king neckbeard (1801738) | about 8 months ago | (#44767777)

The only video that is using Hi10p to any real extent is anime. If you are watching HD anime on a netbook, or really anything other than a desktop, then you will probably be derided by the encoders for using your 'shitbox', and they will probably suggest you stick with crunchyroll.

Re:Hardware acceleration? (1)

Guspaz (556486) | about 8 months ago | (#44768801)

To be fair to them, animated content with its frequent use of simple gradients does get a bigger advantage out of 10-bit encoding (avoiding banding) than film content does. Then again, the ffdshow deband filter (GradFun2DB) does a fantastic job at sorting out banding issues on playback without degrading image quality regardless of content type, so that certainly limits the utility of 10-big encoding.

Re:Hardware acceleration? (1)

AvitarX (172628) | about 8 months ago | (#44766769)

Really?

I've always had obvious stutter (apperent when credits are rolling), and never was able to get mildly acceptable playback at blueray level bitrates without hardware that was dramatically more powerful.

Re:Hardware acceleration? (1)

Khyber (864651) | about 8 months ago | (#44767279)

You probably got a crappy encode with a bitrate far higher than it needed to be or you're using a crappy codec.

Re:Hardware acceleration? (0)

Anonymous Coward | about 8 months ago | (#44767349)

You probably got a crappy encode with a bitrate far higher than it needed to be or you're using a crappy codec.

Well if you want to encode a film eliminating all the fine detail and film grain then yeah you can have HD 1080p rips at 9000 kbps. But you'll see a lot of artifacting in dark scenes and you loose that "film like" quality.
A good HD rip should be around 20 GB for a 2 hour film at 18-20Mbps.

Re:Hardware acceleration? (0)

Anonymous Coward | about 8 months ago | (#44768077)

Personally, I remove the film grain whenever I can. I hate it. But I keep my bitrates high enough that I typically can't see the difference.

Re:Hardware acceleration? (2)

AvitarX (172628) | about 8 months ago | (#44767595)

It was a Blue Ray Rip that I tested for high bitrate.

The quality of the encoding may be low, but commercial movies (purchased legally) are part of what I want to view.

Short of DVD or Blue Ray players I am yet to see smooth scrolling text or credits (netflix on my PS3 is the worse for this, software rendered VLC on older hardware coming next, even on an SD H.264 conversion off of a blue ray rip).

I've found that sub 10 Mbps leads to pretty bad artifacting at 1080P during high-contrast (lightning strikes, HBO's bump being the obvious examples)

Re:Hardware acceleration? (1)

dinfinity (2300094) | about 8 months ago | (#44769835)

If you observed it during a credits sequence it is almost certainly due to the refresh rate of your display/video card not being matched to the refresh rate of the source. (Credits sequences are very easy to encode and decode and shouldn't run into a bottleneck anywhere).

The best way to start analysing this issue is to use MediaPlayer Classic Home Cinema or Black Editon (a fork of MPC-HC), and check the stats with CTRL+J (using Custom EVR as renderer):
https://trac.mpc-hc.org/attachment/ticket/2682/screenshot3.gif [mpc-hc.org]
The green and red lines should be perfectly straight if refresh rate and frame rate are perfectly matched.

Other tools if your display/video card do not support a 23.976 Hz refresh rate:
- SmoothVideo Project - http://www.svp-team.com/ [svp-team.com]
- MadVR smooth motion - http://www.svp-team.com/forum/viewtopic.php?id=1287 [svp-team.com] (MadVR smooth motion is discussed)
- ReClock - http://reclock.free.fr/ [reclock.free.fr] (last time I checked, it is not an option if you want to do audio bitstreaming)

Warning: once you get used to buttery smooth video playback, you will be ruined forever and unable to enjoy video that is not displayed properly ;-)

Re:Hardware acceleration? (-1)

Anonymous Coward | about 8 months ago | (#44767229)

shut the fuck up before you get knocked out, little bitch

Re:Hardware acceleration? (1)

chuckinator (2409512) | about 8 months ago | (#44767247)

I believe that VLC has been using vdpau, vaapi, and xvmc for hardware offloading since that rig could have been classified as state of the art, so you most likely have been using hardware acceleration the whole time.

Re:Hardware acceleration? (1)

jedidiah (1196) | about 8 months ago | (#44767419)

> I have never seen really stable frame-rates in video replay without hardware acceleration

Then you're not trying hard enough.

Soon new hardware will be necessary... (2)

Camembert (2891457) | about 8 months ago | (#44766253)

Don't get me wrong, I find these technical improvements interesting: same quality as h.264 at half the bitrate, that is impressive. However, I also think about the flip of the coin when (if?) this format gets popular: currently I have several devices with hardware support to decode h.264. Think iPhone, iPad, Apple TV, a Western Digital Streamer, a Raspberry Pi. With this new codec they'll need to decode in software, which esp. for the portable idevices (and I assume current Android devices as well) will have a terrible impact on the battery consumption.

Re:Soon new hardware will be necessary... (4, Informative)

unixisc (2429386) | about 8 months ago | (#44766381)

So far, the FSF promoted Ogg-Theora as the standard that they wanted to push as the liberated standard for video encoding & decoding. Since h.264 is more standardized, it's good that they have at least an FOSS equivalent of it - if it can decode existing h.264 encoded videos out there, it's off to a good start.

What I wonder is - if it's LGPL, how different is LGPL3 from GPL3? The FSF made radical changes in version 3, and made GPL3 almost unusable for anyone who wants to lock things in hardware. Is LGPL3 any looser in terms of allowing hardware locking of the code than GPL3? Also, Ogg Theora itself - is it GPL3?

Also, would the new standard be supportable under HTML5?

Re:Soon new hardware will be necessary... (2)

steveha (103154) | about 8 months ago | (#44768027)

Theora uses a BSD-style license.

http://www.theora.org/faq/#14 [theora.org]

WebM also uses a BSD-style license.

http://www.webmproject.org/about/faq/#licensing [webmproject.org]

IMHO, if you are trying to make a standard for media encoding, it just makes sense for the reference code to be BSD-licensed. The point of GPL is to make sure that people can't lock users in to a proprietary code base, with no way to make changes; with a media format, the users can always grab their own copy of the reference code. (And a proprietary version that is incompatible with the reference code will be incompatible with the media standard. Users will shun it.)

Re:Soon new hardware will be necessary... (4, Informative)

slaker (53818) | about 8 months ago | (#44766389)

As long as you have an intermediary to transcode to a supported format, why is that a problem? Plex does a perfectly fine job right now delivering h.264 with AAC audio to less capable mobile devices that I own, as do a number of DLNA servers that are scattered around my apartment. Presumably if you're watching on a device with sub-optimal functionality, you're going to be less concerned about overall source fidelity in the first place; it's not like you care that you aren't getting the full bit rate and eight channel audio from your blu-ray sources when you're watching them on a 4" iThing screen with a $10 pair of headphones.

Re:Soon new hardware will be necessary... (1)

Camembert (2891457) | about 8 months ago | (#44766999)

Thanks for your comment. Yes it is true, transcoding could be an acceptable workaround. I guess that I am overly lazy as I try to transcode as little as possible - in fact I only did it 2 or 3 times in the last few years.

Re:Soon new hardware will be necessary... (1)

omnichad (1198475) | about 8 months ago | (#44767403)

The point is that Plex does it on-demand and doesn't store the resulting transcode.

Re:Soon new hardware will be necessary... (-1)

Anonymous Coward | about 8 months ago | (#44766409)

Stop buying shitty devices that can't be flashed with upgrades.

Re:Soon new hardware will be necessary... (1)

steveha (103154) | about 8 months ago | (#44768135)

currently I have several devices with hardware support to decode h.264... With this new codec they'll need to decode in software

Maybe not.

The hardware support for H.264 is probably in the form of general-purpose DSP (Digital Signal Processing) combined with some code. Basically, your devices have some sort of DSP capability, and someone wrote DSP code to offload much of the decoding work from the general-purpose CPU to the DSP core(s) [wikipedia.org] .

So, it is probably possible to write additional code for H.265 and offer it as an update. This additional code will offload decoding work to the DSP, just as with H.264, and problem solved.

Likewise, it should be possible to offload Theora and WebM to a DSP. The question there is whether anyone will bother. I would expect that Google would DSP-accelerate WebM and ship that standard for at least Nexus devices, but I haven't heard anything about it.

For that matter, I would expect that Google should make a general-purpose DSP library that abstracts the details of the DSP hardware, so that it would be easier to accelerate applications. I know that almost all Android devices run on ARM cores, but how standardized are the various DSP coprocessor cores? As far as I know, right now if you want to write DSP code for Android, you need to write it for a specific processor.

Anyway, I think H.265 will be much like H.264 and much of the DSP code can be reused. It would be much harder to write the DSP support for a codec that uses a completely different technology such as wavelets.

The 2002 Barrack Obama - Updated (-1, Troll)

Anonymous Coward | about 8 months ago | (#44766283)

The 2002 Barrack Obama - Updated

                What I am opposed to is a dumb war. What I am opposed to is a rash war. What I am opposed to is the cynical attempt by Richard Perle and Paul Wolfowitz Samantha Power and Susan Rice and other armchair, weekend warriors in this administration to shove their own ideological agendas down our throats, irrespective of the costs in lives lost and in hardships borne.

                What I am opposed to is the attempt by political hacks like Karl Rove David Axelrod to distract us from a rise in the uninsured, a rise in the poverty rate, a drop in the median income - to distract us from corporate scandals and a stock market that has just gone through the worst month since the Great Depression. That's what I'm opposed to. A dumb war. A rash war. A war based not on reason but on passion, not on principle but on politics. Now let me be clear - I suffer no illusions about Saddam Hussein Bashar Assad. He is a brutal man. A ruthless man. A man who butchers his own people to secure his own power. He has repeatedly defied UN resolutions, thwarted UN inspection teams, developed chemical and biological weapons, and coveted nuclear capacity. He's a bad guy. The world, and the Iraqi Syrian people, would be better off without him.
                But I also know that Saddam Assad poses no imminent and direct threat to the United States or to his neighbors, that the Iraqi Syrian economy is in shambles, that the Iraqi Syrian military a fraction of its former strength, and that in concert with the international community he can be contained until, in the way of all petty dictators, he falls away into the dustbin of history.

only decodes intra frames (-1)

Anonymous Coward | about 8 months ago | (#44766295)

Hot Digity Dog Shit! That is crap! Death pending or was ist los baby?

Ladies and Gentlemen, let me present (0)

Anonymous Coward | about 8 months ago | (#44766377)

Let's welcome this new bull into the shark tank.

May you all flash your patents please? Biggest portfolio gets the first bite.

Decoding is simple (3, Informative)

Anonymous Coward | about 8 months ago | (#44766391)

Decoding is simple, just implement the spec. Encoding is much more difficult, there is no spec - only a requirement that your encoded output can be decoded by a spec compliant decoder.

Re:Decoding is simple (0)

Anonymous Coward | about 8 months ago | (#44766921)

Decoding requires implementing the whole spec. Encoding can be done incrementally as many parts of the spec aren't required to create a legal HEVC stream. How you figure out how to compress the content is the real challenge.

Re:Decoding is simple (1)

Sulik (1849922) | about 8 months ago | (#44769297)

How to compress the content *with good quality within a limited computation time* is the real challenge (otherwise, yes, you can just take a MPEG-2 encoder and stick a HEVC CABAC syntax at the end and you have a valid HEVC bitstream with good perf but crappy compression efficiency compared to H.264)

Re:Decoding is simple (3, Informative)

omnichad (1198475) | about 8 months ago | (#44767413)

You've got that entirely backwards. Encoding requires you only to handle your own implementation - with as little or as many of the features as you decide to implement. Decoding means you have to handle the quirks of the entire spec and possibly the bugs of other encoders.

Re:Decoding is simple (2)

serviscope_minor (664417) | about 8 months ago | (#44768931)

You've got that entirely backwards.

Only pedantically speaking.

Pedantically speaking you could just encode a bunch of I frames and have done with it.

In practice, making an encoder that is remotely worth making is far harder.

Only intra frames? (1)

Anonymous Coward | about 8 months ago | (#44766393)

Currently, libde265 only decodes intra frames, inter-frame decoding is under construction.

Wait... so basicaly they have implemented an h265 decoder which only works if the supposedly existing encoder is configured to use only I-frames.
How is this news? It is like saying you implemented something but actualy only 25% of it works...

Re:Only intra frames? (1)

Pieroxy (222434) | about 8 months ago | (#44766467)

They implemented MJPEG decoding in 2013... Not worthy of much to be honest. Shitty bitrate!

Patents. (5, Interesting)

brunes69 (86786) | about 8 months ago | (#44766425)

An open source library in the codec world is meaningless if the codec itself is covered by patents, because this means that no one can use the library in any country that enforces software patents. Last I saw H.265 is blanketed by over 500 patents. And in this case it's even worse than H.264 because they're not all held by one group, but by all kinds of different groups who all say they want royalties.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766541)

Yeah, whenever I think about XviD or x264 I think to myself, "aren't they so darn meaningless"........

Re:Patents. (5, Insightful)

Anonymous Coward | about 8 months ago | (#44766543)

You are wrong. It's not meaningless, because in the country where I live we don't have software patents. I understand how you may feel it's meaningless for you though but that doesn't mean that it's meaningless in general. Also, I believe that this is distributed in source form and thus is not violating any patents. This makes it even less meaningless.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766731)

What country would that be?

Re:Patents. (1)

Anonymous Coward | about 8 months ago | (#44766919)

What country would that be?

New Zealand is now one of those countries.

Re:Patents. (4, Informative)

Alsee (515537) | about 8 months ago | (#44767415)

New Zealand is now one of those countries.

No. The New Zealand bill was a scam, and all the news coverage screwed up and fell for the scam. The main body of the bill directly stated that software was not patentenable, but Supplementary Order Paper No 237 [legislation.govt.nz] provided "clarification" that only software-as-such was not patentable, and further "clarified" that software-as-such ONLY included patent claims which merely added on-a-computer to something old. In legalese, they excluded patent claims who's sole contribution was that it was a program.

10A Computer programs
(1) A computer program is not an invention and not a manner of manufacture for the purposes of this Act.
  (2) Subsection (1) prevents anything from being an invention or a manner of manufacture for the purposes of this Act only to the extent that a claim in a patent or an application relates to a computer program as such.
(3) A claim in a patent or an application relates to a computer program as such if the actual contribution made by the alleged invention lies solely in it being a computer program.

This means the bill actually MANDATED pure software patents, so long as the patent claim described some new math or something.

For example the classic pure-software patent catastrophe was the GIF patent... that patent claimed some new mathematics for converting one series of numbers (representing a picture) into a shorter series of numbers (a GIF compressed picture). The patent described (contributed) new mathematics, therefore the it's patentable. The RSA public-key crypto software patent is also still patentable, it claims new math for encrypting stuff. All audio and video codec patents, all patentable in New Zealand.

The only patents they excluded was the stupidest level stuff like "fill out your tax form exactly the same way you filled it out last year, but I want a patent on doing it with software".

-

Re:Patents. (3, Interesting)

tlambert (566799) | about 8 months ago | (#44768269)

You are wrong. It's not meaningless, because in the country where I live we don't have software patents. I understand how you may feel it's meaningless for you though but that doesn't mean that it's meaningless in general. Also, I believe that this is distributed in source form and thus is not violating any patents. This makes it even less meaningless.

This is why New Zealand is region code 4, but pretty much all the content is region code 1. You've been sent to "we can't enforce software patents on you so you don't get content until after everyone else has paid for it" Coventry. It's also why the same content costs more there: out of spite, by the content production companies.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44769587)

In NZ it is legal to buy and sell region free players, and to mod players to make them region free.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766551)

Decoding patented formats is allowed even in the US.

And software patents are not enforceable in the Free World. So while some software might be meaningless for you, there are a lot of us who can put it into good use.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766579)

this hasn't prevented ffmpeg from being fairly successful!

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766611)

An open source library in the codec world is meaningless if the codec itself is covered by patents, because this means that no one can use the library in any country that enforces software patents.

False
You can obtain a license for said patents.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766719)

Even in countries with software patents there is no reason you can't use this on a personal basis (obtaining it from a country with no software patents).
If you say 'I won't run software on my PC which may be covered by patents I am not licensed to use', then you *can't run any software at all*. All software 'infringes' at the least some (totally bogus but legally valid) patent held by some troll - e.g. all uses of scanners, all use of WiFi. You are *already* infringing, massively and constantly, so you might as well infringe some more.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766811)

This has always baffled me: what prevents software firms from making software where you can add external codecs as plugins? That way, the open-source h.265 implementation would be unrelated to the software that is sold.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44766957)

An open source library in the codec world is meaningless if the codec itself is covered by patents, because this means that no one can use the library in any country that enforces software patents. Last I saw H.265 is blanketed by over 500 patents. And in this case it's even worse than H.264 because they're not all held by one group, but by all kinds of different groups who all say they want royalties.

H.264 is also patented and that hasn't stopped the usefulness of open source coders in that instance. I'd hazard to guess that most (all?) of these patents are only valid in the US, and so the rest of the world can use the software without worry. (IANAL; please correct me if I'm wrong.)

Even if the patents were valid in other countries, or you're someone who lives in the US, I doubt that most people will be sued for using the software for private use. These codecs will also be used for publicly distributed files, and where the files are copyrighted and distributed illegally, you're already breaking the law via copyright so I don't think said infringers would care much patent law either.

Besides, there's nothing stopping a commercial venture from using the LGPL code and actually paying the patent license fees.

Re:Patents. (1)

cyberthanasis12 (926691) | about 8 months ago | (#44767025)

The thing is that if Struktur AG has all the patents involved, then under GPL (and LGPL) the authors automatically give all recipients a license to all the patents (if I understand the legalese of GPL correctly).

Re:Patents. (1)

PhrostyMcByte (589271) | about 8 months ago | (#44767545)

Yes, meaningless. Tell that to XVID, x264, and LAME. All very successful Open Source projects implementing patent minefields. Sometimes it's more about the fun of coding than pushing an ideology.

Re:Patents. (1)

denis-The-menace (471988) | about 8 months ago | (#44767719)

IOW: we have another JPEG2000: A great idea destroyed by greed.

In this case, the math and numbers are owned by a bunch of different entities.

Re:Patents. (2)

Goaway (82658) | about 8 months ago | (#44768185)

h.264 is massively patented, and it is huge success. JPEG2000 was a failure because it wasn't actually good enough to be worth dealing with the patents for, unlike h.264.

Re:Patents. (1)

evilviper (135110) | about 8 months ago | (#44768039)

It's certainly NOT "meaningless" to have an open source codec for a patented standard. They still get the benefits of multiple vendors focusiing all their efforts on a common code base. And let's not forget that not every country enforces software patents like the US.

That said, it's sad that here on /. We've had a couple of stories about H.265 with NO mention of VP9 which Google has frozen the bitstream on, claims matches or slightly exceeds H.265 across the board, and has a working decoder in Chrome... For the first time, EVER, the patent-free, open source codec is being released at the same time as the proprietary standard version, so it really has a good chance of upstaging the MPEG standard. Yet /. Of all places can't be bothered to mention it... With WebM adoption Opus for audio as well, the patent-free multimedia codecs may actually be superior.

Re:Patents. (0)

Anonymous Coward | about 8 months ago | (#44768397)

That "matches or slightly exceeds H.265" claim is bogus you know. It's hard to put all the proper evidence into a post and I am busy (you could look for comparisons made on doom9 forum though, like this one: http://forum.doom9.org/showpost.php?p=1642355&postcount=335 ). More importantly, in future it will become obvious I think.

Re:Patents. (1)

evilviper (135110) | about 8 months ago | (#44768667)

That test doesn't include H.265 at all...

"x265's development is currently too rapid for reliable testing, so I didn't want to focus on it"

Is there a deadline? (0)

Anonymous Coward | about 8 months ago | (#44766471)

As h.264 has a 2016 timeframe for which the MPEG-LA has to make a decision on, does h.265 have an equivalent timeframe?

Are we being locked in perpetuity with proprietary encoding for at least the next decade?

I'd like to, at some point, make some money off videos I create, and NOT have to pay the MPEG-LA, VCEG, or someone else first and foremost.

open source H.265 (HEVC) encoder (5, Interesting)

WestonFire22 (2736813) | about 8 months ago | (#44766623)

The other day Telestream announced the availability of an open source H.265 encoder via the x265.org site. Guess we don't have to wait for "Encoding to come later". See here: http://www.telestream.net/company/press/2013-09-03.htm [telestream.net]

Re:open source H.265 (HEVC) encoder (0)

Anonymous Coward | about 8 months ago | (#44768335)

If I'm reading that release right it's saying that they are starting a project to make the encoder, not that it's already available...

WebM / VP9 (1)

Anonymous Coward | about 8 months ago | (#44766713)

libvpx contains BSD-licensed VP9 codec (here [webmproject.org] ) which is not infected by patents. VP9 is the VP8 (the current WebM) successor, HEVC level competitor. But Google has not paid for slashvertisement so no article about VP9 here.

like taxes, open source is theft (0, Troll)

Anonymous Coward | about 8 months ago | (#44766771)

This whole project is just more proof that open source is a lot like goverment taxation in that it is all about stealing from those who work hard in order to give to those who don't.

Re:like taxes, open source is theft (-1)

UnknownSoldier (67820) | about 8 months ago | (#44766849)

Governments *force* you under duress to pay taxes. The *only* way to get out of them is NULL and VOID every CONTRACT you made.
Open Source creators voluntarily give their code freely(1) away for the benefit of everyone.

(1) As in Free Speech, but may also be As in Free Beer.

Now quite trolling.

Re:like taxes, open source is theft (-1)

Anonymous Coward | about 8 months ago | (#44767189)

If the goverment was made up of volunteers, that wouldn't stop making taxation theft and thus both immoral and illegal. Similarly just because open source developers are volunteers doesn't make their theft of the intellectual PROPERTY of others suddenly okay.

Sad to see people spouting statist nonsense on slashdot.

Re:like taxes, open source is theft (0)

jedidiah (1196) | about 8 months ago | (#44767549)

There is no "property" here.

The relevant patents are part of an industry standard.

Taxes may be government theft, but patents are corporate theft. They allow scum like you to try to claim ownership of the work of others without even the pretense of trying to work for the greater good.

You're an idiot. You are the statist here. Without a state monopoly on coercive force, a patent cannot exist at all.

They say that possession is 9/10th of the law. There is a certain logic to that. To hold something is to own it since you can exclude others from it even without a government. Can't do that with an invention.

Re:like taxes, open source is theft (1)

Anonymous Coward | about 8 months ago | (#44767881)

So people who invent stuff for a living are not entitled to the fruits of their labor just because some hippie retards on slashdot think everyone should be free to steal it based on their own NOT libertarian definition of what is and isn't property?

WTF?

This is why modern libertarianism has failed, when the most outspoken adherents are not able to understand BASIC economics and instead keep changing their ideas just to try to appeal to statists.

Re:like taxes, open source is theft (3, Informative)

king neckbeard (1801738) | about 8 months ago | (#44767619)

That's because 'intellectual property' is a misnomer. Patents are a government handout, and entirely a creation BY THE STATE. They are taxing the public in the form of freedom instead of money in hopes that we get a decent ROI in technological progress.

Re:like taxes, open source is theft (0)

jedidiah (1196) | about 8 months ago | (#44767489)

> it is all about stealing from those who work hard

Who would that be exactly?

This is an implementation of a standard. In some cases, this will be embedded in national standards that are dictated by national governments.

Ultimately, this will allow you to use those things that you have PAID for like services you've subscribed to or creative media you have PAID for or home grown content that you created yourself.

This is something that will allow you to use your own property.

You have to be a real moron to equate it with taxes.

Basically, a JPEG decompressor (0)

Anonymous Coward | about 8 months ago | (#44767875)

Only I-frames...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...