Slashdot Mirror
FFmpeg Announces High-Performance VP8 Decoder
An anonymous reader writes "Three FFmpeg developers — Ronald Bultje, David Conrad, and x264 developer Jason Garrett-Glaser — have written the first independent, free implementation of a VP8 video decoder. Benchmarks show that it's as much as 65% faster than Google's official libvpx. The announcement also gives a taste of what went into the development process, as well as the optimization techniques used. Currently it's only fully optimized on x86, but ARM and PowerPC optimizations are next in line for development."
As someone who spends most of their work day implementing someone else's specifications I know exactly where they are coming from. I honestly cannot tell if people are bad at writing spec's because they're simply lazy or if they need to be trained to document their file formats completely.
When I think back to my University days we never really learned how to write a specification and wonder if that wouldn't be a course worth teaching. Perhaps you get the students to write a program that outputs a set of complex information into a format, and then get them to write an end to end specification to both read and write that format.
My favourite moments are when you realise that the current implementation not only doesn't follow the spec' but directly contracts it (e.g. A "bool" that can be TRUE, FALSE, "", "null", or "nan").
Abolishing software patents will take years. Most of the short-term goals are a waste of time, or a distraction by companies that don't really want to end the problem, but WebM is a project that would have a big impact, and has a good chance of succeeding. Great to hear that Xiph continues to support it!
File formats and compatibility are the biggest problem caused by software patents. They're how monopolies get too powerful, and they're how companies with people-friendly terms get locked out of commercial software development. (Commerce isn't the only valid form of software development, but it's important for the sustainability of a project.)
Expert in software patents or patent law? Contribute to the ESP wiki!
I usually rip my DVDs to ~1.2GiB Xvid avi files at native res using mencoder (not reencoding the audio), and have been doing this for many years. Does anyone know what combination of muxer and audio/video codecs is preferred nowadays? I'm thinking of using Matroska with Vorbis for audio but I'm completely lost as to what video codec to use. As for which tools to use, I find most of what I need in the Debian repositories but I'm open to suggestions.
Also, I prefer quality over size but over 1.2GiB for a 90 minutes DVD is too much IMHO.
"ill rip my dvds to x264 that are a bit smaller and better quality then your xvids"
True enough. Not automatically preferable though because they require more than double the cpu to decode.
"if vp8 can give me as good a quality viewing in less space it wins"
Probably not. x264 has a number of innate visual advantages to compressing video that were previously mpeg compressed. VP8 generally seems to win on raw uncompressed video in the races I've seen.
As for cpu, it does count, especially if you are streaming to a set top box or old pc for playback). I don't know what kind of cpu power is required to play back VP8.
Probably not. x264 has a number of innate visual advantages to compressing video that were previously mpeg compressed. VP8 generally seems to win on raw uncompressed video in the races I've seen.
And the problem is, where do you find raw, uncompressed video? About the only place you will find it is if you are transferring an analog source to a dedicated internal capture card. Virtually everything else uses some form of MPEG or H.264 compression.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
> Probably not. x264 has a number of innate visual advantages to compressing video that were previously mpeg compressed. VP8 generally seems to win on raw uncompressed video in the races I've seen.
You are right and wrong at the same time. x264 has many psycho-visual optimizations (these lower PSNR) that make it look better, while VP8 is optimized for PSNR, which doesn't necessarily look good. If you compare x264 in baseline profile (not what you'd use for a DVD rip) and VP8 at best settings, VP8 might beat x264 at PSNR, but it'll still look worse.
Now, for recompression: This is basically misinformation, based on a comment made by the VP8 devs in the MSU test, where VP8 did relatively better on the only uncompressed source. Of course this source (moving calendar) also has very peculiar properties with regards to motion compensation, which is more likely the reason for different performance. MPEG compressed content doesn't actually bias against VP8 more than against H.264, since VP8's block transform is actually more similar to MPEG2's than that of H.264.
Long story short: Until VP8 gets psycho-visual optimizations, it'll always look worse than x264 at the same bitrate. Once it does get them, it might be possible for VP8 to reach x264 quality in baseline profile. Baseline is only used for phones and the like, though.
One of the best ways I have seen to avoid that kind of ambiguities is in the PNG specification. (rfc2083)
By not only explaining how something should be done but also expressing the reasoning to why this method has been chosen the person implementing the specification can follow the same reasoning and in the cases where the "how" not is specific enough the "why" will make it evident.
One of the worst ways is probably rfc1034 with it's many "I think it should be done this way but I refuse to say if it is important or why I have chosen this method. Here is some pseudocode in a language that I just invented."
Agreed. The fact that VP8 generally does hold its own side by side with x264 is a pretty impressive testament to the codec.
But who cares if VP8 is technically a better codec if it doesn't actually produce superior results with the source video we work with? If it cuts CPU for decoding while offering on par quality that would be a solid advantage.
If it produces adequate results, then I for one will use it simply because of the stance it takes with regards to patent encumbrance. To me that is perfectly sufficient, because I'm not trying to create any HD video... yet? I don't want to get into building disk farms. Anyway, I shouldn't have to worry about things like whether the camera that says pro on it has a professional H.264 license associated with it, or whether the video editing software whose name ends in pro has a professional H.264 license... but last I heard, there were rather high-profile examples of each indeed not having same. This is not something that I want to have to worry about. Indeed, I would say that an intellectual property law system which permits this to become something you have to worry about is broken as designed.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I rip h.264(libx264 level 4.1 high profile), with ACC 5.1 and 2.0(muxed properly combine left front/rear, split center) sound in a mpeg4 container. because that is what my ps3 will play back. i use ffmpeg's -cfq setting.
# ffmpeg -i ${INFILE_THAT_FFMPEG_CAN_DECODE} -map 0:0 -map 0:1 -deinterlace -vcodec libx264 -vpre hq -crf 22 -threads 0 -level 41 -acodec libfaac -ac 6 -ab 256kb -r 24000/1001 ${INFILE_THAT_FFMPEG_CAN_DECODE%.*}.mp4 -map 0:1 -acodec libfaac -ab 256kb -newaudio
The above gets generated with a lengthy python script that i'm till slowly working bugs out of.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
By not only explaining how something should be done but also expressing the reasoning to why this method has been chosen
Yes - a truly excellent thing to do. They should do the same thing with laws - define the law as they currently do but also provide a justification for the law. That way the law can be challenged in the future when the justification no longer holds. In addition, no one will ever misinterpret the meaning of a law and use it for purposes for which it was not designed.
Now back to format specifications - code makes for a very poor specification. While code can implement a specification, it generally does so in an unorganized fashion. Specifications should be clear - having no ambiguities or vagueness. Code is not so clear. And as the parent mentioned, generally does not communicate reasoning to the reader.
Mathematically based definitions are great - they are both clear and organized. Tools such as lex/flex/yacc/bison combine code with mathematical definitions to implement such specifications. The ideal format specification would include a mathematical definition along with reasoning explaining the design decisions.