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

141 comments

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 Anonymous Coward · 2013-09-05 12:17 · Score: 0
  
  Too bad there is no "-1 Obvious". So guess what...
8. 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...
9. 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..?
10. 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.
11. Re:Codec? by Anonymous Coward · 2013-09-05 17:52 · Score: 0
  
  Accepting idiots vernacular just leads to more idiots. No thanks. That's how we ended up calling photograms photographs because idiots couldn't realise photograph is the technique for producing photograms.
12. 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.
13. 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.
14. 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.
15. Re:Codec? by Anonymous Coward · 2013-09-10 07:29 · Score: 0
  
  You also forgot to mention an intra-frame can describe its difference against future frames, too.
  I don't think so, that would still it an inter-predicted frame.
  Intraframe prediction is exactly that, "intra-frame" - the frame is decodeable on its own, all the information is coded in it.
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"
x265? by Anonymous Coward · 2013-09-05 03:37 · Score: 0

How is the x265 project doing these days?
1. Re:x265? by Anonymous Coward · 2013-09-05 03:50 · Score: 0
  
  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.
2. 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).
3. 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.
4. Re:x265? by Anonymous Coward · 2013-09-05 10:26 · Score: 0
  
  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.
5. 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.
6. Re:x265? by Anonymous Coward · 2013-09-05 17:09 · Score: 0
  
  You are checking in the wrong place.
  https://bitbucket.org/multicoreware/x265/commits/all
  http://x265.org/
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 Anonymous Coward · 2013-09-05 03:43 · Score: 0
  
  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.
3. 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.
4. 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!
5. 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
6. 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.
7. 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.
8. 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.
9. 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.
10. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 05:37 · Score: 0
  
  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.
11. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 05:44 · Score: 0
  
  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.
12. 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.
13. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 05:49 · Score: 0
  
  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.
14. 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.
15. 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
16. 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.
17. Re:Hardware acceleration? by timeOday · 2013-09-05 06:55 · Score: 2
  
  I think you're just not looking closely enough.
18. 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.
19. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 07:12 · Score: 0
  
  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.
20. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 07:51 · Score: 0
  
  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...
21. 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!
22. 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.
23. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 08:58 · Score: 0
  
  good news, your Nexus can play 10bit. MX player works. THe only limit is in the OEM video player app.
24. 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 ;-)
25. 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.
26. Re:Hardware acceleration? by Anonymous Coward · 2013-09-05 17:38 · Score: 0
  
  Gradfun actually does degrade image quite a bit. It act's as a blur filter in flat areas, and it kills detail in low contrast parts. It can also harm (or in extreme cases, erase) lineart.
  Same problem sadly happens when you need to sue it when encoding...
27. 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?
28. 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.
29. 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.
30. Re:Hardware acceleration? by Anonymous Coward · 2013-09-06 04:03 · Score: 0
  
  You probably aren't checking that deeply (frame-frame comparisons with interleave() ). I don't use it for watching, but for encoding, so I have to inspect the results really thoroughly... At least with some footage, debanding without harm is an ordeal of tweaking/hacks to limit the effect of gradfun (but nowadays, the original grafun2db has been replaced by more advanced variants). Very often, you just have to accept to lose some things.
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.
Ladies and Gentlemen, let me present by Anonymous Coward · 2013-09-05 03:51 · Score: 0

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 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 Anonymous Coward · 2013-09-05 04:56 · Score: 0
  
  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.
2. 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.
3. 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.
4. 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!
5. 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: 0
  
  Yeah, whenever I think about XviD or x264 I think to myself, "aren't they so darn meaningless"........
2. 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.
3. Re:Patents. by Anonymous Coward · 2013-09-05 04:13 · Score: 0
  
  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.
4. Re:Patents. by Anonymous Coward · 2013-09-05 04:15 · Score: 0
  
  this hasn't prevented ffmpeg from being fairly successful!
5. Re:Patents. by Anonymous Coward · 2013-09-05 04:19 · Score: 0
  
  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.
6. Re:Patents. by Anonymous Coward · 2013-09-05 04:33 · Score: 0
  
  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.
7. Re:Patents. by Anonymous Coward · 2013-09-05 04:34 · Score: 0
  
  What country would that be?
8. Re:Patents. by Anonymous Coward · 2013-09-05 04:43 · Score: 0
  
  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.
9. 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.
10. Re:Patents. by Anonymous Coward · 2013-09-05 04:59 · Score: 0
  
  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.
11. 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).
12. 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.
13. 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.
14. 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
15. 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
16. 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.
17. 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.
18. Re:Patents. by Anonymous Coward · 2013-09-05 08:01 · Score: 0
  
  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.
19. 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
20. Re:Patents. by Anonymous Coward · 2013-09-05 09:47 · Score: 0
  
  In NZ it is legal to buy and sell region free players, and to mod players to make them region free.
21. 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!
22. Re:Patents. by Anonymous Coward · 2013-09-05 10:38 · Score: 0
  
  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"
  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. Ofc. it is just a single point, but it is consistent with previous results. And after all, VP9 is almost a strict subset of H.265 coding tools, while it lacks several substantial ones (b-frames, weighted prediction being examples). That also gives you a fairly good hint that the theoretical performance of the format as such is going to be lower.
  Moreover - there are several H.265 encoders in work by various players. VP9 has a single implementation by Google, and it doesn't look like anybody is motivated to write a better one. That basically means the situation will repeat as with H.264 and VP8. On 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, and with no competition forces, it will be using the format's potential less effectively. Ergo, visual quality of VP9 videos will be subpar in comparison to state-of-the-art H.265 encoders, and at the same time, encoding might even use more CPU relatively, too...
23. 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!"
24. 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.
25. Re: Patents. by Anonymous Coward · 2013-09-05 17:56 · Score: 0
  
  Not in australia...
26. 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
27. Re:Patents. by Anonymous Coward · 2013-09-07 06:02 · Score: 0
  
  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.
  Did you see that happen with VP8? Because what you describe did not happen with it, despite its situation being same as of VP9. Facts show that Google/On2 doesn't really push encoding quality much, despite them being in control of VP8 for years.
  Look at H.264 - not only is there the industry-best x264, there are other decent encoders (Mainconcept isn't as good, but definitely beats what Google has to offer). The competition in H.264 space indeed yields countless simple or crap encoders (Apple?), but hey, that's why it is competition. The point is that same as there are tens of crap ones, there are few decent and some outstanding ones. And one that is best thing available. With Google's VPx, you get one that isn't yet decent.
  It didn't help VP8 that there was no duplication of efforts (and so far it seems it isn't helping VP9). That isn't enough to make a proper encoder, when the producer and employees apparently aren't motivated enough to try hard. The competition between MPEG implementers will probably force at least some developers to try hard. /x265 being able to reuse some x264 code and approaches will help too, no doubt./ ... as for "previous results", you need to search, dear friend. I am not paid for debunking on /. Etc... dunno about logic, but mine seems to doing fine and matching the experimental results :D
28. 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
29. Re:Patents. by Anonymous Coward · 2013-09-08 10:29 · Score: 0
  
  Doesn't change the fact that VP8 encoding in libvpx made little progress and still offers subpar quality. Likewise, no othe and, perhaps better VP8 encoder appeared. People tried to make a x264 mod that would encode to VP8 (it is quite feasible to do so), but nobody was interested in it (Mozilla lost interest, Google didn't support it either), so the devs lost interest too.
  Why do you think Google will suddenly change the course it followed for three years and become interested in improving the quality of the encoder software? It would be welcome thing but it just doesn't look so, so you need to give some examples/facts as to why/how would that happen.
  The format is also still less effective compared to HEVC and you can tell that it will also be an also ran, despite being rushed out +- at the same time. Of course, Google will still push it in its services, free stuff advocates will use it, many businesses might too, due to the costs. (It will be in the wild, but on technical merits, HEVC will be the way to go.)
  But that won't change that the encoding will be lower quality for all these reasons I stated here. They are not baseless at all. Are you following what happens in this space really? (Not just reading about it on sites like this - using that software, compressing video, looking at the quality/compression performance of those encoders.) Because I do.
Is there a deadline? by Anonymous Coward · 2013-09-05 04:03 · Score: 0

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 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
1. Re:open source H.265 (HEVC) encoder by Anonymous Coward · 2013-09-05 07:54 · Score: 0
  
  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...
2. Re:open source H.265 (HEVC) encoder by Anonymous Coward · 2013-09-05 10:33 · Score: 0
  
  It's available:
  https://shared.com/pwb6xve8kg
  But like others it's not really usable yet, last but not least because it is incredibly slow.
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.
There is no chicken and the egg problem by Anonymous Coward · 2013-09-05 04:33 · Score: 0

At least not for people who understand evolution, then the answer is obvious.
1. 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?
like taxes, open source is theft by Anonymous Coward · 2013-09-05 04:39 · Score: 0, Troll

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.
1. Re:like taxes, open source is theft by jedidiah · 2013-09-05 05:55 · Score: 0
  
  > 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.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
2. Re:like taxes, open source is theft by jedidiah · 2013-09-05 06:04 · Score: 0
  
  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.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
3. 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.
4. 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.
5. Re:like taxes, open source is theft by Anonymous Coward · 2013-09-05 12:16 · Score: 0
  
  By your argument then anything anyone "owns" is a "goverment handout". Do you even realize that you are in full agreement with fucking communists on that? FFS, is this what passes for libertarians on slashdot these days? Have not a single one of you people read a god damned economics textbook?
6. Re:like taxes, open source is theft by Anonymous Coward · 2013-09-05 14:23 · Score: 0
  
  Intellectual property is still a misnomer. The so called protections over IP are in fact government enforced institutions and not free market capitalism. In an unrestricted free market, people could copy ideas freely and place products on the market. Patents are granted to people and public freedom is restricted as a result, the patent holders have claim to restrict infringing products on the marketplace. The idea is that technical progress is published into the public rather than hidden away as a trade secret.
7. Re:like taxes, open source is theft by Anonymous Coward · 2013-09-05 15:31 · Score: 0
  
  You're really cute. Let me characterize the debate thus far:
  You: "Ideas are something that I can assert an exclusive right to."
  Us: "Good luck with that."
  You: "All y'all are a bunch of dumb statists."
  From a practical standpoint, trying to insist that a given set of digital data should not be copied is impossible*. From an economic standpoint, you're trying to insist that something is a scarce good when it is not, and that's not the kind of market distortion that sustainable businesses are built on -- hence the government involvement. From a philosophical standpoint, you've yet to establish any basis for exclusive exploitation of an idea. Obviously there's a lot of money involved in exploiting government monopolies, but owning a license to print money is not equivalent to having a moral right to do so. I'd drag out that letter of Jefferson's, but TBH you're just an idiot and nothing will ever fix that, so I may as well save the effort.
  * Assuming that the end-user controls the hardware.
8. Re:like taxes, open source is theft by Anonymous Coward · 2013-09-06 02:39 · Score: 0
  
  "From a philosophical standpoint, you've yet to establish any basis for exclusive exploitation of an idea."
  It's my property, I have the right to use it as I see fit and you have yet to establish any basis for your right to steal it from me.
  "but owning a license to print money"
  I don't own a "license to print money", I own an invention that I worked fucking hard to create and open source collectivists are stealing from me and I own it by the same right that I own the house I live in and the car I drive. It is YOU who are using force to hurt me by taking my property and using it without reimbursing me. In a rational pro-makret society this is called THEFT.
9. Re:like taxes, open source is theft by Anonymous Coward · 2013-09-06 02:49 · Score: 0
  
  "Patents are granted to people and public freedom is restricted as a result"
  Disingenuous calls of "freedom" are not a license to do anything you want to anyone at any time. Your freedom ends at the tip of my nose. You cannot murder people, you cannot sell children off as slaves, you cannot set fire to your neighbors house and you cannot steal other people's property under the guise of "public" freedom. That last one is in fact a key feature of collectivist ideologies and is orthogonal to an actual free market.
  How much more simply can I put this so you can understand it?
10. Re:like taxes, open source is theft by Anonymous Coward · 2013-09-06 03:32 · Score: 0
  
  We have different concepts about the ownership of ideas. Individuals cannot own a public idea. If you make an idea public, that idea can no longer be stolen or owned. If you want to keep an idea secret, you do not let the secret go to the public. If you run a business selling some physical product, people can learn ideas from that product and try to copy it in some way. If you don't want people to do that, you keep the product private do not sell it to anybody.
11. Re:like taxes, open source is theft by Anonymous Coward · 2013-09-07 07:27 · Score: 0
  
  "ownership of ideas"
  You are still missing the point. As a patent holder I don't own an "idea" I own something that I put a lot of my capital into it. Just because you can copy it easily doesn't make that right.
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.
Basically, a JPEG decompressor by Anonymous Coward · 2013-09-05 06:45 · Score: 0

Only I-frames...
1. Re:Basically, a JPEG decompressor by Anonymous Coward · 2013-09-05 10:35 · Score: 0
  
  No, already does P and B, too.
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