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

← Back to Stories (view on slashdot.org)

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

Posted by timothy on Thursday September 5, 2013 @03:31AM from the fewer-bits-more-pixels dept.

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

85 of 141 comments (clear)

Min score:

Reason:

Sort:

Codec? by Hatta · 2013-09-05 03:37 · Score: 5, Funny

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

--
Give me Classic Slashdot or give me death!
1. Re:Codec? by elfprince13 · 2013-09-05 03:51 · Score: 1, Troll
  
  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.
2. Re:Codec? by Sulik · 2013-09-05 04:33 · Score: 5, Informative
  
  Since it's intra-frame only, it's not even a 'dec' -> maybe just a 'duh'
  
  --
  Help! I am a self-aware entity trapped in an abstract function!
3. Re:Codec? by adisakp · 2013-09-05 04:33 · Score: 3, Informative
  
  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.
4. Re:Codec? by UnknownSoldier · 2013-09-05 04:54 · Score: 2
  
  > codec is an abbreviation coder/decoder
  Or alt. compression/decompression.
  http://oxforddictionaries.com/us/definition/american_english/codec
  Agreed that the mods are ignorant.
5. Re:Codec? by Alsee · 2013-09-05 05:00 · Score: 5, Informative
  
  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.
  -
  
  --
  - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
6. Re:Codec? by Anonymous Coward · 2013-09-05 06:28 · Score: 3, Informative
  
  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.
7. Re:Codec? by wagnerrp · 2013-09-05 12:41 · Score: 1
  
  It's true, and that just makes it that much funnier. Can't you take a joke? Fucking troll...
8. Re:Codec? by mattack2 · 2013-09-05 13:09 · Score: 1
  
  I'm admittedly totally nitpicking.
  Is it really as little as every second or two? I thought typically it was at least 2/second, at least for MPEG 2. (The wikipedia page mentions every 15th frame, then shows a shorter sequence in its IBP example.)
  Also, is it really "how the current frame is different than the last key-frame"? Isn't it "how the current frame is different than the PREVIOUS frame"? (and the previous frame of course would require decoding from the previous I-frame up through that frame). Basically I-frame, diff1, diff-from-1, diff-from-diff-from-1, etc..?
9. Re:Codec? by Alsee · 2013-09-05 15:21 · Score: 1
  
  Is it really as little as every second or two?
  That is configurable, and typically ranges between about a half second and ten seconds. In fact I've been seeing about ten seconds between key-frames in some of the movies on my cable TV. It's visible as a faint fog that creeps up in very dark scenes, and abruptly vanishes to black at the next key-frame. The sudden jump is distracting, but it's even more distracting consciously realizing I'm "watching a CODEC" rather than "watching a movie. Chuckle.
  
  Isn't it "how the current frame is different than the PREVIOUS frame"?
  Yeah, my description was a little sloppy.
  -
  
  --
  - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
10. Re:Codec? by dave420 · 2013-09-05 19:51 · Score: 1
  
  You also forgot to mention an intra-frame can describe its difference against future frames, too.
11. Re:Codec? by MachineShedFred · 2013-09-06 00:22 · Score: 1
  
  Maybe because it is funny?
  It is possible to be correct and humorous at the same time, you know.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
12. Re:Codec? by adisakp · 2013-09-09 07:40 · Score: 1
  
  In the case of FFMPEG, it's not idiots... it's the EXPERTS that are using the term in this way.
Re:chicken and the egg problem? by MetalliQaZ · 2013-09-05 03:37 · Score: 2, Informative

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.

--
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Re:chicken and the egg problem? by slaker · 2013-09-05 03:37 · Score: 5, Insightful

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

--
-- I wanna decide who lives and who dies - Crow T. Robot, MST3K
Hardware acceleration? by timeOday · 2013-09-05 03:38 · Score: 1

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?
1. Re:Hardware acceleration? by MetalliQaZ · 2013-09-05 03:41 · Score: 1
  
  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.
  
  --
  "Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
2. Re:Hardware acceleration? by Khyber · 2013-09-05 03:50 · Score: 4, Interesting
  
  "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.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
3. Re:Hardware acceleration? by chmod+a+x+mojo · 2013-09-05 04:23 · Score: 3, Informative
  
  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....
  
  --
  To err is human; effective mayhem requires the root password!
4. Re:Hardware acceleration? by AvitarX · 2013-09-05 04:39 · Score: 1
  
  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.
  
  --
  Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
5. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 05:24 · Score: 1
  
  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.
6. Re:Hardware acceleration? by chuckinator · 2013-09-05 05:26 · Score: 1
  
  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.
7. Re:Hardware acceleration? by Khyber · 2013-09-05 05:28 · Score: 3, Interesting
  
  "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.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
8. Re:Hardware acceleration? by Khyber · 2013-09-05 05:29 · Score: 1
  
  You probably got a crappy encode with a bitrate far higher than it needed to be or you're using a crappy codec.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
9. Re:Hardware acceleration? by jedidiah · 2013-09-05 05:47 · Score: 1
  
  > I have never seen really stable frame-rates in video replay without hardware acceleration
  Then you're not trying hard enough.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
10. Re:Hardware acceleration? by jedidiah · 2013-09-05 05:50 · Score: 1, Redundant
  
  > 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.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
11. Re:Hardware acceleration? by AvitarX · 2013-09-05 06:09 · Score: 2
  
  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)
  
  --
  Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
12. Re:Hardware acceleration? by king+neckbeard · 2013-09-05 06:33 · Score: 1
  
  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.
  
  --
  This is my signature. There are many like it, but this one is mine.
13. Re:Hardware acceleration? by timeOday · 2013-09-05 06:55 · Score: 2
  
  I think you're just not looking closely enough.
14. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 07:10 · Score: 3, Insightful
  
  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.
15. Re:Hardware acceleration? by chmod+a+x+mojo · 2013-09-05 08:19 · Score: 1
  
  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.
  
  --
  To err is human; effective mayhem requires the root password!
16. Re:Hardware acceleration? by Guspaz · 2013-09-05 08:40 · Score: 1
  
  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.
17. Re:Hardware acceleration? by dinfinity · 2013-09-05 10:12 · Score: 1
  
  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
  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/
  - MadVR smooth motion - http://www.svp-team.com/forum/viewtopic.php?id=1287 (MadVR smooth motion is discussed)
  - ReClock - http://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 ;-)
18. Re:Hardware acceleration? by Khyber · 2013-09-05 11:28 · Score: 1
  
  "VDPAU (Video Decode and Presentation API for Unix) is an open source library (libvdpau) and API originally designed by Nvidia for its GeForce 8 series and later GPU hardware"
  Note, my rig had a GeForce 2 MX, so no to VDPAU and VAAPI. XvMC only available on a GeForce 2 card (if possible) using the proprietary linux blob (which only supports up to the 7000 series GPUs) and would not be available in Windows 2000 due to the locked down DMA for video memory.
  Actually, checking the wikis on all three of what you mention, there is essentially no way that I was running any hardware-accelerated bits.
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
19. Re:Hardware acceleration? by Guspaz · 2013-09-05 19:39 · Score: 1
  
  At the default threshold of 1.2, I've never seen it do any of those things (have any negative impact on low-contrast areas or lineart). Even on very low-contrast textures. And yet at those same settings it significantly reduces the appearance of banding. Perhaps you're applying it at a much much higher threshold than I am?
20. Re:Hardware acceleration? by MachineShedFred · 2013-09-06 00:41 · Score: 1
  
  And before you say anything about 1366x768 and down-scaling the N10 at least has a higher resolution than 1080P.
  So instead we're talking about upscaling any video you might be trying to play, since nobody publishes video in anything higher than 1080p for wide distribution.
  Still CPU intensive.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
21. Re:Hardware acceleration? by MachineShedFred · 2013-09-06 00:49 · Score: 1
  
  Well shit, we better just stop the advance of all video tech, because nobody is going to ever upgrade anything, ever again.
  People said the same thing about H.264 once - "Why use that when we already have MPEG-1 and Sorenson?!"
  Who uses MPEG-1 now?
  Signed, someone with a view of a horizon that is farther than 6 months ahead.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Soon new hardware will be necessary... by Camembert · 2013-09-05 03:42 · Score: 2

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.
1. Re:Soon new hardware will be necessary... by unixisc · 2013-09-05 03:52 · Score: 4, Informative
  
  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?
2. Re:Soon new hardware will be necessary... by slaker · 2013-09-05 03:52 · Score: 4, Informative
  
  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.
  
  --
  -- I wanna decide who lives and who dies - Crow T. Robot, MST3K
3. Re:Soon new hardware will be necessary... by blueg3 · 2013-09-05 04:18 · Score: 2
  
  Can't flash in hardware support. Gotta change the hardware for that.
4. Re:Soon new hardware will be necessary... by chill · 2013-09-05 04:27 · Score: 1
  
  The very definition of FPGA. See Xilinx.
  
  --
  Learning HOW to think is more important than learning WHAT to think.
5. Re:Soon new hardware will be necessary... by Camembert · 2013-09-05 05:03 · Score: 1
  
  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.
6. Re:Soon new hardware will be necessary... by omnichad · 2013-09-05 05:44 · Score: 1
  
  The point is that Plex does it on-demand and doesn't store the resulting transcode.
7. Re:Soon new hardware will be necessary... by blueg3 · 2013-09-05 06:15 · Score: 1
  
  So, all consumer devices that aren't based on FPGAs are shitty?
8. Re:Soon new hardware will be necessary... by steveha · 2013-09-05 07:07 · Score: 2
  
  Theora uses a BSD-style license.
  http://www.theora.org/faq/#14
  WebM also uses a BSD-style license.
  http://www.webmproject.org/about/faq/#licensing
  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.)
  
  --
  lf(1): it's like ls(1) but sorts filenames by extension, tersely
9. Re:Soon new hardware will be necessary... by steveha · 2013-09-05 07:21 · Score: 1
  
  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).
  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.
  
  --
  lf(1): it's like ls(1) but sorts filenames by extension, tersely
10. Re:Soon new hardware will be necessary... by timeOday · 2013-09-05 11:03 · Score: 1
  
  When the device makers can't even be bothered to offer the latest version of their own OS for devices they sold 6 months ago?
11. Re:Soon new hardware will be necessary... by slaker · 2013-09-05 17:03 · Score: 2
  
  Plex is a literal Swiss Army knife for this stuff. As long as you have a reasonably powerful back end like a retired Core i or even a Core 2 Quad, you're probably good to go on arbitrary amounts of real time transcoding for a typical home setup. If your Plex Media Server is on some kind of ARM or Atom-powered NAS, you have work to do, but even then there are pretty straightforward tools (e.g. Format Factory on Windows or Handbrake on whatever) that can whip a media collection in to shape if you absolutely need to do it.
  Plex is damned near perfect for video but I will say that I have some oddball HD audio formats that it can't handle. Also, not all clients are created equal. It will work as a DLNA server as long as its on the same LAN with client devices, but DLNA-only clients really miss out on the presentation and of course some of the cool online integration stuff.
  
  --
  -- I wanna decide who lives and who dies - Crow T. Robot, MST3K
12. Re:Soon new hardware will be necessary... by Camembert · 2013-09-05 22:01 · Score: 1
  
  Thanks, that is interesting, I didn't know that.
Decoding is simple by Anonymous Coward · 2013-09-05 03:53 · Score: 3, Informative

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.
1. Re:Decoding is simple by omnichad · 2013-09-05 05:46 · Score: 3, Informative
  
  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.
2. Re:Decoding is simple by serviscope_minor · 2013-09-05 08:52 · Score: 2
  
  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.
  
  --
  SJW n. One who posts facts.
3. Re:Decoding is simple by Sulik · 2013-09-05 09:20 · Score: 1
  
  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)
  
  --
  Help! I am a self-aware entity trapped in an abstract function!
4. Re:Decoding is simple by omnichad · 2013-09-05 09:25 · Score: 1
  
  Even if you implement a relatively complete encoder, what I said still applies.
Only intra frames? by Anonymous Coward · 2013-09-05 03:53 · Score: 1

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...
1. Re:Only intra frames? by Pieroxy · 2013-09-05 04:03 · Score: 1
  
  They implemented MJPEG decoding in 2013... Not worthy of much to be honest. Shitty bitrate!
  
  --
  Write boring code, not shiny code!
Patents. by brunes69 · 2013-09-05 03:56 · Score: 5, Interesting

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.
1. Re:Patents. by Anonymous Coward · 2013-09-05 04:11 · Score: 5, Insightful
  
  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.
2. Re:Patents. by Anonymous Coward · 2013-09-05 04:55 · Score: 1
  
  What country would that be?
  New Zealand is now one of those countries.
3. Re:Patents. by cyberthanasis12 · 2013-09-05 05:05 · Score: 1
  
  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).
4. Re:Patents. by Alsee · 2013-09-05 05:46 · Score: 4, Informative
  
  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 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".
  -
  
  --
  - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
5. Re:Patents. by PhrostyMcByte · 2013-09-05 06:03 · Score: 1
  
  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.
6. Re:Patents. by denis-The-menace · 2013-09-05 06:25 · Score: 1
  
  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.
  
  --
  Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
7. Re:Patents. by evilviper · 2013-09-05 07:09 · Score: 1
  
  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.
  
  --
  Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
8. Re:Patents. by Goaway · 2013-09-05 07:33 · Score: 2
  
  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.
9. Re:Patents. by tlambert · 2013-09-05 07:49 · Score: 3, Interesting
  
  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.
10. Re:Patents. by evilviper · 2013-09-05 08:28 · Score: 1
  
  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"
  
  --
  Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
11. Re:Patents. by dinfinity · 2013-09-05 10:32 · Score: 1
  
  True, but the AC is still right. I've looked at the comparisons and like it has been said elsewhere: VP9 is better than VP8, but that's about it.
  See for yourself:
  http://forum.doom9.org/showthread.php?p=1620230#post1620230
  The third line in that posts links to this image, showing snapshots from the comparison between VP8, VP9, AVC (x264) and HEVC (HM10): http://i3.minus.com/i5vzrESbfwCmX.png
  HEVC is just an absolute beast in (perceptual) video compression. If you look at the bitrates here, you assume that the videos must be crap, but they look ridiculously good. And that is with an early days reference encoder!
12. Re:Patents. by ghost_templar · 2013-09-05 13:26 · Score: 1
  
  No. The New Zealand bill was a scam, and all the news coverage screwed up and fell for the scam.
  It's gotten to the stage where I've become so cynical about the tech industry, that if I hear what sounds like good news, it's probably not, or is more upbeat than it actually is. I don't even need to do any in-depth research - it's probably going to be an accurate assumption, and generally is. As end-users (I hate the term consumers, as if that's all anyone does anymore) we have very few genuine victories for our rights anymore.
  
  --
  "Holy crap! A weapon just floating in space!"
13. Re:Patents. by jrumney · 2013-09-05 16:28 · Score: 1
  
  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.
  I don't see how that makes it meaningless in the other 90% of the world that has sane IP laws.
14. Re:Patents. by evilviper · 2013-09-06 07:52 · Score: 1
  
  There is a single data point (blue cross), and it tells you that the quality curve of the encoder is probably going to be significantly better than VP9.
  The author correctly called it: "a single (admittedly non-useful) data point."
  
  it is consistent with previous results
  I see no "previous results"...
  
  That basically means the situation will repeat as with H.264 and VP8.
  That's nonsense. VP8 was only released to the public MANY, MANY YEARS after H.264. Now VP9 is there right from the start, on equal-footing with H.265. This is a very different situation that EVER before, which was the point of my original post you apparently dismissed out of hand.
  
  n the MPEG side, the competition will cause the actual practical quality of encoding to use much more of the theoretical potential of the format; whereas on the VP* side, there will be just one not very progressing encoder library,
  This is utter nonsense. The development of MPEG encoders always follows the same path... There's innumerable proprietary ones, with absolute CRAP quality, and then ONE open source codec which gets all the development effort and blows the rest away. With MPEG-1/2 this would have been mjpegtools, with MPEG-4 ASP this was Xvid, with AVC this was x264, and with HEVC this looks to be x265, though that could change.
  The fact that there's a single open source VP9 standard means there will almost certainly be less duplication of effort, and the single central open source standard will get all the high-quality coding improvements.
  And you're basing your whole opinion on this completely flawed logic that flies in the face of reality?
  
  --
  Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
15. Re:Patents. by evilviper · 2013-09-07 07:12 · Score: 1
  
  Did you see that happen with VP8? Because what you describe did not happen with it, despite its situation being same as of VP9.
  The situation wasn't REMOTELY the same...
  As I KEEP FUCKING SAYING to you:
  "That's nonsense. VP8 was only released to the public MANY, MANY YEARS after H.264. Now VP9 is there right from the start, on equal-footing with H.265. This is a very different situation that EVER before, which was the point of my original post you apparently dismissed out of hand."
  You seem to be so far biased that actual facts and information just don't penetrate your thick skull, so I'll stop wasting my time with your spouting baseless nonsense. Goodbye.
  
  --
  Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
open source H.265 (HEVC) encoder by WestonFire22 · 2013-09-05 04:21 · Score: 5, Interesting

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
WebM / VP9 by Anonymous Coward · 2013-09-05 04:32 · Score: 1

libvpx contains BSD-licensed VP9 codec (here) 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.
OSS (+Commercial) Encoder by realinvalidname · 2013-09-05 05:27 · Score: 1

Guess this is different from yesterday's story in Streaming Media, Telestream Helps Launch Open Source x265/HEVC Project, which offers a H.265 encoder, available under either GPL or commerical license.
Re:x265? by Anonymous Coward · 2013-09-05 05:38 · Score: 5, Interesting

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:like taxes, open source is theft by king+neckbeard · 2013-09-05 06:12 · Score: 3, Informative

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.

--
This is my signature. There are many like it, but this one is mine.
Re:like taxes, open source is theft by Anonymous Coward · 2013-09-05 06:46 · Score: 1

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:x265? by Anonymous Coward · 2013-09-05 08:26 · Score: 1

Erm... you should have done more research
I tried, but the x265 site is undeniably devoid of any useful information.
Re:There is no chicken and the egg problem by jamiesan · 2013-09-05 08:54 · Score: 1

There is no egg. It is you who is a chicken?
Re:x265? by plonk420 · 2013-09-05 14:13 · Score: 1

last i checked, x265 was not associated with x264 in any way. and development hadn't moved forward in months.
HEVC/H.265 BSD-licensed reference implementation by tempmpi · 2013-09-05 18:15 · Score: 1

A BSD-licensed C++ reference implementation of both HEVC/H.265 encoding and decoding is available. This implementation is focused on research and features and not on speed. Especially the encoder is very slow, a few frames per minute is completely normal, even on good machines.
But many people have optimized the reference implementation by adding SIMD and parallelizing the decoder and have reached 4K real time decoding and >100fps for 1080p decoding, even on low end machines.
A C-based reimplementation is not really needed to get good speed, nor it is needed to have a open source implementation and they are not even saying anything about the speed of their decoder.

--
Jan
Re:HEVC/H.265 BSD-licensed reference implementatio by Zyrill · 2013-09-05 20:38 · Score: 1

Where is it available and where are those optimized implementations you mentioned? I'd really like to have a go at the standard...
Re:HEVC/H.265 BSD-licensed reference implementatio by tempmpi · 2013-09-05 23:44 · Score: 1

Somehow the link was removed: http://hevc.hhi.fraunhofer.de/

--
Jan