|
TV見てくれたんですね。私は1回戦落ちでした。圧縮率はトップのつもり
だったんだけどなぁ。
僕はもちろん圧縮部分担当。エラー訂正の部分も、後輩が考えたアルゴリズムを
却下し即席で僕が考えたアルゴリズムを実装させました。
圧縮部分
6次元PPMのRangeCoder。圧縮部分はスピード無視のコーディングで、出現頻度表
作成に力を入れました。100MB超のテキストを処理するため1週間前にPerlを覚えたり(w
エラー訂正部分
決めたバイト数のブロックを送信した後、抜かれたボールにインデックスをつけて
再送を繰り返す。エラー訂正符号が抜かれたらそこも訂正する。ボールの個数を
訂正パケットの最後にする事により、後ろから訂正すればブロック全体が復号できる。
余分なボール送信は少なくてもブロックの間で無駄な時間が起こるので、最初の
ブロックを大きめにとる。第一ブロックだけを送信するとして、余裕を持って7分中3分を
訂正前データの送信、2分が訂正データの送信、残りの2分がその他処理として計算し、
練習の時の送信速度から最初のブロックサイズは36Byteに決定。
しかし、予行演習で他の高専が思いのほか弱く、1回戦は上位2チームが進出できる
ということで第一ブロックを30Byteに変更。送信の子に「ゆっくり送っていいよ」と
言っておいたら、練習の倍の時間をかけて送信してくれました(w
送信プログラムに送信者の目標ペースを表示する機能を付けるなりなんなりと
対策はあった筈で、リーダーなのにソフトウェアの性能ばかりに目がいっていた
自分のミスです。
下のWebページの掲示板も暇があればどうぞ。ソースコードもその掲示板で
後に整形して公開予定なんで。(現在圧縮dllのみ公開中)
http://www.cs.knct.ac.jp/procon/13th/
基礎研の動画圧縮codecも、順調じゃないけどとりあえず進行中。既にDPCM+RangeCoderで
Huffyuvより数%高い圧縮率を数十%長い時間をかけて圧縮できる(w
現在Haar変換で簡単な不可逆をしてます。JPEG2000の整数DWTってどうやって
実装してるのかな。値を1つおきに取って、抜いた所は差分を保存する方法だと、
ノイズの多いキャプチャ用codecとしては好ましくない。でも2値の平均値と差分を
取る方法だと、差分が大きいと桁が足りなくなるから可逆にならない。
|
|