Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Software Graphics

LGPL H.265 Codec Implementation Available; Encoding To Come Later 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.'"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by MetalliQaZ ( 539913 ) on Thursday September 05, 2013 @11:37AM (#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.

  • by unixisc ( 2429386 ) on Thursday September 05, 2013 @11:52AM (#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?

  • by slaker ( 53818 ) on Thursday September 05, 2013 @11:52AM (#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.

  • Decoding is simple (Score:3, Informative)

    by Anonymous Coward on Thursday September 05, 2013 @11:53AM (#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.

  • by chmod a+x mojo ( 965286 ) on Thursday September 05, 2013 @12:23PM (#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:Codec? (Score:5, Informative)

    by Sulik ( 1849922 ) on Thursday September 05, 2013 @12:33PM (#44766715)
    Since it's intra-frame only, it's not even a 'dec' -> maybe just a 'duh'
  • Re:Codec? (Score:4, Informative)

    by adisakp ( 705706 ) on Thursday September 05, 2013 @12:33PM (#44766721) Journal

    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? (Score:5, Informative)

    by Alsee ( 515537 ) on Thursday September 05, 2013 @01:00PM (#44766973) Homepage

    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.

    -

  • by omnichad ( 1198475 ) on Thursday September 05, 2013 @01:46PM (#44767413) Homepage

    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:Patents. (Score:5, Informative)

    by Alsee ( 515537 ) on Thursday September 05, 2013 @01:46PM (#44767415) Homepage

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

    -

  • by king neckbeard ( 1801738 ) on Thursday September 05, 2013 @02:12PM (#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:Codec? (Score:3, Informative)

    by Anonymous Coward on Thursday September 05, 2013 @02:28PM (#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.

UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker

Working...