7月
17

新しいクリップでの圧縮比

梅澤 威志 Ut Video Codec Suite, 技術ネタ 2017-07-17

先日の記事で作った4Kのクリップをザックリ圧縮してみました。

…あれっ

以前から使っているクリップは大元は同じものなのですが、圧縮結果は傾向がかなり違っています。以前はこんな結果でした。

以前から使っているクリップは以下のようにして作っていました。

  1. 元の 4K 16bit RGB を YUV420 に変換した .y4m ファイルが公開されていたので、それをダウンロード
  2. 以下のような AviSynth スクリプトで変換
    LoadPlugin("N:\xiph-test-media\rawsource.dll")
RawSource("crowd_run_2160p50.y4m")
ConvertToRGB32
BilinearResize(Width/2, Height/2)

縮小のしかたで傾向が違うかも、と思って、4K のクリップを AviSynth に実装されているいくつかの縮小アルゴリズム (Point, Bilinear, Bicubic, Lanczos) で変換したものを比較してみました。めんどくさいので RGB24 だけ。

Point 以外は圧縮比が高くなっています。補完するアルゴリズムだとある意味「ぼかし」が入るわけなので、それにより全般的に圧縮比が良くなり、また縦横どちらの方向にもぼかされるので gradient の圧縮比が改善されるのではないかと思います。

4K の方は left も gradient もそんなに圧縮比が変わらないという結果になってしまってグラフを描くときに面白くないのですが、まあいいか。

ちなみにこの結果をもって gradient と left を使い分けるべきとか gradient やっぱり要らなかったといった結論にはならなくて、大抵の場合は gradient の方が良い結果ですし、圧縮してみないとどちらが良い結果になるかは分からないので、 gradient を選んでおくのが適切だと思います。

Address: http://umezawa.dyndns.info/wordpress/?p=6588
«
»
Trackback

only 1 comment untill now

  1. Olaf Koenders @ 2017-07-25 16:57

    Thank you very much for your hard work on UTVideo. I was looking for a HuffYUV replacement and you’ve done an exceptional job.

    I work with Virtualdub all the time and usually only with YV12. Most of my frame sizes are anywhere from 720×576 to 1046×576, which are then made into DVD’s with Nero.

    One thing I noticed with almost all video compression codecs is that blank frames (all-black at the start or end of a movie, or fades/cuts between scenes) still have a very large byte-count after compression.

    With my YUV 4:2:0 frame sizes, UTVideo and HuffYUV retain roughly around 80k of compression code per entirely black frame. As you can imagine, some videos have several seconds of these (25 FPS here in Australia) and that rapidly adds up which to me seems wasteful and could be exploited.

    For example, 5 seconds of black video with 80k bytes per compressed frame = 10 megabytes.

    As I was an assembly programmer for the old Amiga platform long ago, I’m aware of Huffman code and have dabbled with it myself. I’ve also made my own video compression codec, but not using Huffman code.

    One thing my codec checked for during compression was entirely blank frames/scenes (either black, white or all one colour) and compressed them into a single byte code noting to the decompressor that the frame’s blank, followed by the colour code and then the number of frames this repeats – 3 bytes in all describing up to 256 blank frames of a certain colour.

    For example (hex) 00:FF:0A

    These three bytes mean decompress (create from scratch) 10 all-white blank frames and could save some 800k of data.

    This may be beyond Huffman and difficult to implement depending on the colourspace, but it would be nice to see added as it would likely speed up and increase compression/decompression much further.

    The main problem I foresee with this is that a check during decompression of video compressed with older versions of UTVideo would be required to avoid a crash.

    Again, many thanks.

Add your comment now