VP7 encoder release

While a certain country cosplays the Third Reich and conducts talvisota simultaneously—and tries to bomb my home city to debris, I still need some distraction…

borrowed from vp7.de

Since I’m rather bored with VP7 encoder I’ve decided to release it and move to something else. It should work about the same as VP6 encoder (i.e. poorly and nobody should care about it) but if you want to know what knobs you can turn just invoke nihav-encoder --query-encoder-options vp7 (but I guess the only useful options are to set bitrate/quantiser and keyframe interval).

Have fun!

Update from March 4: encoding with low quantisers should now work as well.

4 Responses to “VP7 encoder release”

  1. EHT_shiniori says:

    great! i was waiting for this.

    that said i may have hit a few snags in your VP7 encoder.
    in particular, if i set the “quant” value to 3 or lower, it may produce an unplayable video file, as proven with these two files below.
    https://www.sendspace.com/file/wg522b
    https://www.sendspace.com/file/l2idw5

    though if i set the quant value to 4 or higher (up to 127), it actually produces a playable result but i can’t quite put my finger on it.
    https://www.sendspace.com/file/q9x75e

    i used mpv and ffplay to play the relevant files.

    as for the encoding settings used, here they are.

    psa_1[vp7][v23].avi – –ostream0 encoder=vp7,key_int=60,version=1,lf_level=0,lf_sharpness=0,quant=0,mbtree_depth=60
    psa_1[vp7][v24].avi – –ostream0 encoder=vp7,key_int=60,version=1,lf_level=0,lf_sharpness=0,quant=4,mbtree_depth=60
    psa_1[vp7][v25].avi – –ostream0 encoder=vp7,key_int=60,quant=0

  2. Kostya says:

    It might be missing coefficients clipping that causes it, I’ll try to investigate.

  3. EHT_shiniori says:

    ok, just tested the new update and encoding with low quantizers actually gives out playable results now.

    i’m not sure about the video over-sharpening itself every second though…

  4. Kostya says:

    Yeah, that’s why it’s a failure.

    There might be a bug somewhere caused either coefficients being too large, incorrect frame reconstruction inside the encoder or some decision weighting to the visually less pleasant but better metric modes. Or maybe there’s some trick like rounding switch for older codecs that I haven’t employed.

    Sadly I don’t have enough inspiration to dig inside it myself (not right now at least) but all zero people who care enough to fix it are welcome to do so.