Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Google Graphics Media Open Source News Technology

FFmpeg Announces High-Performance VP8 Decoder 80

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."
This discussion has been archived. No new comments can be posted.

FFmpeg Announces High-Performance VP8 Decoder

Comments Filter:
  • We need WebM (Score:5, Informative)

    by ciaran_o_riordan ( 662132 ) on Saturday July 24, 2010 @09:35AM (#33013004) Homepage

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

  • by Anonymous Coward on Saturday July 24, 2010 @09:47AM (#33013064)

    e.g. A "bool" that can be TRUE, FALSE, "", "null", or "nan"

    Well since TRUE and FALSE are uppercase (meaning preprocessor definitions/value constants) it's obvious that "bool" was not meant to be a unique type in this hypothetical language, and instead was a typedef for an integer type. Nothing a coding standard can't rectify.

  • by shaitand ( 626655 ) on Saturday July 24, 2010 @10:11AM (#33013172) Journal

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

  • by Anonymous Coward on Saturday July 24, 2010 @10:28AM (#33013252)

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

  • by Anonymous Coward on Saturday July 24, 2010 @10:28AM (#33013256)

    use x264 to encode video to h.264, audio can be anything you like if you mux into matroska. If you care about quality then forget about using xvid. OK, it seemed great several years ago, but next to video encoded with x264 it is *pitifully* bad. You can use ffmpeg or mencoder to handle the cropping, scaling, muxing, encoding parameters etc. ffmpeg is better in some ways because it can mux successfully into mkv or mp4 while mencoder is only really useful for avi or outputting raw video.

    If a movie looks good at 1.2GB made with xvid, it will usually look equally good at 700MB in h.264. The same movie at 1.2GB in h.264 will be so much better you'll wonder why you ever though xvid doesn't look like shit.

    x264 encoding initially seems horribly complex, but google for x264 presets and ffmpeg x264 presets and read the docs that come with ffmpeg and x264 and you'll soon be producing rips that look indistinguishable from the source DVD or VOB *and* are smaller than your xvid avi files.

  • by Anonymous Coward on Saturday July 24, 2010 @10:36AM (#33013302)

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

  • by Anonymous Coward on Saturday July 24, 2010 @10:46AM (#33013378)

    Personally, I've been going with H.264 and native audio (either AAC or DTS), in an MKV file. I usually throw the subtitles, and any director commentary (downmixed MP3 96kbps stereo 44.1) tracks.

    I've been doing the same with my blu-ray rips, but get frustrated because handbrake and VLC can't handle the subtitles on-disk.

  • by cynyr ( 703126 ) on Saturday July 24, 2010 @12:23PM (#33014036)

    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.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...