7月
26
- バグ修正
-
- Windows で、エンコード時およびデコード時に、出力イメージのサイズ(バイト数)が正しく設定されないことがある。
readme 日本語 英語 / バイナリ Windows (exe) Mac OS X (zip) / ソース
修正内容を書きながら、どっかで見たような…と思ったら、5.1.2 の時も同じような修正をしていました。内部構造が変わった時に設定するコードが消えちゃったんですな。
Windows Media Encoder でソースとして指定するとエラーになる、というレポートで見つかったバグですが、潜在的にはいろんなアプリケーションに影響しているはずです。
追記:エンコード後のフォーマットにおけるサイズは実際には意味が無いはずなので、再エンコードする必要はありません。
対応ありがとうございます。こちらでもUtVideo11.1.1で各種AVIを出力し、
WindowsMediaエンコーダのファイル変換でエラーが出ないことを確認しました。
Thank you for UT Video codec for Mac OS X (and source code)
Perhaps this is useful for the Xcode project, after installing NASM 2.10.x – allows you to compile in Xcode using newer NASM binary. I was getting errors with Xcode 4.5 and 4.4, since NASM is too old.
NASM Assembly Files using Script
—-
cd “${INPUT_FILE_DIR}”
/usr/local/bin/nasm -f macho -s -o “${DERIVED_SOURCES_DIR}/${INPUT_FILE_NAME}.nasm.o” “${INPUT_FILE_PATH}”
—-
Output File:
${DERIVED_SOURCES_DIR}/${INPUT_FILE_NAME}.nasm.o
http://i.imgur.com/RLx4H.png
Many thanks for this code!
utv_core/TunedFunc_x64.cpp で tfnSSE2の初期化が足りないようです。
(x64_sse2_ConvertTopdownRGBxxToULY2がない)
実質問題ないのか?よく分かりませんが一応報告。
>>vade-san
Oh, is that the way to applying target-specific build rule for some file types?
Very useful. Thank you.
(But it’s unfortunate that Xcode displays “Run custom shell script XXX” rather than “Assemble XXX” or “Nasm XXX”…)
>>kishさん
ああ本当だ、足りてませんね。いけませんね。つかコンパイラは警告しないのかこれ…
現状、x64 版があるのは Windows 版だけで、Windows 版ではこの関数は呼ばれないので、動作上は問題ありません。
えーとちょっと無知な質問をさせてください。
ULRA ULRG ULY0 ULY2ならどの順番で綺麗に取れますか?
後もう一つ、こちらは質問ではないのですが
アマレコTVでPS2のインターレースの映像を60fpsでキャプチャ(キャプボの仕様上30fpsのキャプチャ不可)するとaviutlでインターレース解除が出来無いのですがこれはどうしてでしょうか?ちなみにAMVコーデックを使ったらちゃんと解除できましたのでコーデックの問題だと思うのですが・・・・?
一般論としては、ULRG が一番きれいで、ULY2 ULY0 の順番です(ULRA はアルファチャンネルを持つソースのための物なので枠外)。ただし、一般ユーザが買うようなキャプチャデバイスでは、ULY2 が必要とするデータより多くのデータを送ってこないので、ULRG ではなく ULY2 でキャプチャするのが適切です。
インターレース解除の方ですが、「解除できない」というのは具体的にどういう挙動になりますか?(エラーダイアログが表示されるとか乱れた映像が出力されるとか)
あと、4つのうちどれでキャプチャしたかも場合によっては重要な情報です。
インターレース解除ですが、乱れた映像が出力される(解除しきれていない?)ますね。ちなみにULY2でキャプチャしました。 後キャプチャボードに fcc=UYVY,YUY2,YVYU の3つがありましたがUYVY,YUY2,YVYUの順で綺麗に取れますよね?
ちなみにUYVY,YUY2,YVYU全部試しましたがどれもインターレースはうまく解除できませんでした
もしあれならAVIファイルを斧ろだにアップしましょうか?
済みません、問題解決しました。
インターレース映像としてエンコードにチェック入れたら綺麗に解除できました。ご迷惑をお掛けして大変失礼致しました・・・・
fcc=UYVY,YUY2,YVYU の3つがありましたがUYVY,YUY2,YVYUの順で綺麗に取れますよね?
↑こちらの質問にお答えしていただけると嬉しいです・・・
何度も済みません
インターレース映像としてエンコードにチェック入れても映像が2分ぐらい経つと綺麗に解除できなくなりました・・・・
何が原因なんでしょうね・・・
本当何度もすみません・・・・
UYVY,YUY2,YVYU は、どれも同じだけの情報を持っているので、きれいさという点では変わりません。普通は UYVY か YUY2 を選んでおけば問題ありません。
で、インターレースの方ですが、何なんでしょうね…
・ULY2 で録った(ちゃんと解除できない) AVI ファイル
・ちゃんと解除できるときの AMV2 の設定ダイアログ(スクリーンショット)
をお願いします。デカそうですが。
URL:http://ll.la/+4jZ
DLパス:utvideo
です。これで原因がわかればいいのですが・・・・
受け取りました。
で…そもそも手元では現象(ちゃんと解除できない)が発生しません。何が違うんだろう。うーむ(困
ところで、コマ送りしながら見てたんですが、6フレーム進んで6フレーム同じフレームが連続する(12フレームのうち6フレームは時間が止まっている)、を繰り返す不思議な映像になってますね。問題の現象とは無関係かと思いますけど。
[…] ・作者さんサイト : 或るプログラマの一生 ・コーデック : Ut Video Codec Suite カテゴリー: MMD, 雑記 パーマリンク ← […]
As a note, when I cross compile it for win32, then try to use it in ffmpeg (cross compile), I get this error:
BEGIN /tmp/ffconf.T4DG4bQ3.cpp
1 #include
2 #include
3 #include
4 #include
5 int main(void) {
6 CCodec* obj1;
7 return 0; }
END /tmp/ffconf.T4DG4bQ3.cpp
/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/bin/i686-w64-mingw32-g++ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -std=c99 -fomit-frame-pointer -pthread -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include/fribidi -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include/freetype2 -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include/freetype2 -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include/opus -I/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/include -D__STDC_CONSTANT_MACROS -c -o /tmp/ffconf.4VroEG7h.o /tmp/ffconf.T4DG4bQ3.cpp
cc1plus: warning: command line option ‘-std=c99’ is valid for C/ObjC but not for C++ [enabled by default]
In file included from /tmp/ffconf.T4DG4bQ3.cpp:4:0:
/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/utvideo/Codec.h:31:10: error: ‘INT_PTR’ does not name a type
/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/utvideo/Codec.h:32:10: error: ‘INT_PTR’ does not name a type
ERROR: utvideo not found
This patch seems to clear it up:
https://github.com/rdp/ffmpeg-windows-build-helpers/blob/master/patches/utv.diff
HTH.
-r
Ah, that’s right. Thanks.