- 機能追加
-
- ULY2, ULH2, ULY0, ULH0: YV16 での入出力に対応した。
- 性能向上
-
- ULY4, ULH4, ULY2, ULH2, ULY0, ULH0: ネイティブな planar フォーマットでの入出力を高速化した。
readme 日本語 英語 / ライセンス (GPLv2) 日本語 英語
バイナリ Windows (exe) Mac (zip) / ソース
だいたい20%ぐらい速くなるようです。YUV420 の場合は元が速すぎてあまり速くならないようですが。
あと Predict Median のデコードがちょっと速くなってるようです。
このバージョンのexeを実行するとexplorerがフリーズするだけで、
インストールが開始されないのですがなぜでしょうか？
使用OSはWin10 64bitです、ちなみにver 17.2.0はインストール出来ました。
手元で試験しましたが、再現しませんでした。
他に思い当たる節も無く、原因は不明です。
Now the UYL0 ouput YV16 “by default” instead of YV12, it seems there is an issue in the priority output format of the codec.
When i open an UYL0 file with AVISource in avisynth, i have an YV16 data file instead of an expected YV12.
AVISource filter does not follow the priority of output formats of the codec. The filter just tries output formats in the filter’s predefined order. See http://avisynth.nl/index.php/AviSource for more information.
If you want to let Avisynth follow the priority of output formats of the codec, you should use DirectShowSource instead.
Argh… Ok, thanks for the information. It screws all the scripts i have (i’ll have to add the pixel_type in all of them now), but it’s not the codec fault…
更新お疲れ様です。
AE使用しております。
先日4K60fpsの動画を作ったのですが、
QuickTime Animation 100%で出力したら
ビットレートが3.5Gbpsとかいうアホみたいな数値になっていたので
他にコーデックはないものかと探しておりました。
さて、今の流行のように、
GPGPU使ってエンコードできるようになればいいんですけどね。
いかんせん、Nvidiaではx264とx265(URL参照)、
RadeonやIntel等仕様が異なってくるので
日本人で言うと対応させてるのはRigayaさんくらいですね。
これぐらい速くなってくるとGPU使っても速くなりません。また、UtVideoの圧縮原理はGPUのような何十何百コアもあるアーキテクチャには不向きです。
速度はそこそこでいいので圧縮比を向上させる（そのような新しいコーデックを作る）という方向性ならGPUを使うのもありでしょうが、それだったら別に新しいコーデックを作らなくても世界中の人がH264とかに注力しているのでそれを使えば用は足ります。あと、私にはそういった開発環境（GPUとかのこと）を整えるような資金がありません。
ご丁寧にありがとうございます。
これからも使用させて頂きますね。
13.x.xのころから利用させていただいています。
以前からあった症状で、17.3.0でも同様なのですが、UtVideoCodecを使用した動画ファイルを、PegasysのTMPEGEncVideoMasteringWorks6(以下TVMW6)でmp4(H.264)などにエンコードすると、エンコードが終了しなくなってしまいます。
録画環境は、MonsterXU3.0Rとその付属キャプチャソフトを使用した場合、
アマレコTV4を使用した場合、スーパーアマレココを使用しデスクトップキャプチャをした場合を試しました。
試したのは、「UtVideo YUV420 BT.709 VCM」と「UtVideo RGB VMC」です。
TVMW6に上記の録画ファイルをソースとして、mp4などにエンコードを行うと、出力ファイルは正常に出力し終わっているにもかかわらず、エンコードが終了しないという状態になります。
UtVideoCodecによるファイル以外をソースにした場合に同様の症状になったという事は記憶に無く、おそらくUtVideoCodec側に原因があるのではないかと思っています。
原因がわかるようであれば、対処をお願いしたく思います。
追加で必要な情報等あれば、可能な限り提供いたします。
また、デバッグ協力が必要と言うことであれば、出来る限りの協力をさせていただきます。
よろしくお願い致します。
ご報告ありがとうございます。
TVMW6は使ったことはないのですが、「エンコードが終了しない」というのは、例えば「途中経過ダイアログが自動で閉じない」とかそういう感じの現象でしょうか？
説明のためにTVMW6のエンコード画面を、dropboxにアップロードしました。
https://www.dropbox.com/s/hlbs1424xaj09r5/2017-01-25.png?dl=0
＃しばらくは置いておきますが、そのうち削除しますのでご了承下さい。
TVMW6はエンコードを開始すると、画面下部の「進捗」グラフが増加していき、エンコードが終わると、エンコードが完了した旨のダイアログが出ます。
UtVideoの動画をソースにした場合、この進捗が100%になっても、完了ダイアログが出ず、経過時間のカウントだけが延々上昇していきます。
この状態から、「出力中断」を行っても、操作を受け付けなくなるだけで、経過時間のカウントもそのまま増加し続け、アプリの終了も出来ないという状態になります。
タスクマネージャで強制終了するか、Windowsごと再起動するしか無い状態になります。
ちなみに、出力されたファイルの方は、もうTVMW6も掴んではおらず、正常に出力完了した状態のようです。再生できるだけでなく、ファイルの削除や移動も可能ですので。
お手数をかけていただけるのであれば、TVMW6の体験版で試してみていただくのが、手っ取り早いかもしれません。
記憶違いでなければ、TVMW6は体験版は、出力の際にTVMW6のロゴが自動付加される以外は、製品版と同様に動作したかと思います。
http://tmpgenc.pegasys-inc.com/ja/download/tvmw6.html
エンコード画面は確認しました。ありがとうございます
手元では再現しませんでした (Windows 8.1 x64)
とりあえずアタリを付けるために以下のことをやってください。
コマンドプロンプトを開き、”c:\Program Files\utvideo\utv_logc.exe” を実行する。
TVMW6 を実行し、エンコードを行う。この時、コマンドプロンプトの方でログがズラズラと出てきます。
TVMW6 がハングアップしたら、出て来たログをください。長い（はず）のでコメント欄ではなくdropboxとかでお願いします。ハングアップした状態でログが止まっているかどうかも教えて下さい。
デバッガをアタッチできれば簡単なんですがねぇ。
>手元では再現しませんでした
ありゃ、ということは環境依存と言うことなのでしょうか？
utv_logを起動し、表示された物をメモ帳にコピペして保存した物をdropboxにアップロードしました。
https://www.dropbox.com/s/9onwfshcc02mk6f/utv.log?dl=0
30秒ほどの録画ファイルを作成し、TVMW6でエンコードを行ってみたのですが、エンコード画面のプレビューが動き出す前くらいにログの出力が止まり、エンコードが止ったところや、TVMW6の出力中断を行ったタイミングでログが増える様子はありませんでした。
出力中断後1分ほど待ってもログが増える様子はなかったので、ログを上記ファイルにコピペし、utv_logc.exeを停止しました。
ちなみに、上記の中断から、まだTVMW6が放置状態で、17,8分になりますが、進捗の経過時間だけが増えて行っています。
あ、すみません、環境を書き忘れました。
Windows10Pro 64bit、
CPUはAMDのFX-8350です。
搭載メモリ16GB、ストレージはsystemがSSD256GBで110GBほど空きがあり、
データ用のドライブは3TBのHDDで600GB弱の空きがあります。
ログを確認しました。より詳細なログを出すようにしたものを作るのでしばらくお待ちください。
お手数おかけして申し訳ありません。
よろしくお願いします。
>ログを確認しました。より詳細なログを出すようにしたものを作るのでしばらくお待ちください。
-f でフルログ出力。
-e オプションでログを表示しつつutv_2017-02-03_09_08_23.log
等のファイル名で出力できるようにすればいいかもですね。
AfterEffectsでAVIに変換したのですが、
途中で映像が破綻していました。
一度別なソフトでutvideoから非圧縮にしたところ
問題なく処理できたので、
コーデックの問題な気がします。
別な話で思いついたこと。
aviコーデックでは対応できないので独自コーデックを作る必要があるとおもうのですけど、
同一フレームが一定数以上続く場合はカラー値ではなく、
[開始横ピクセル,開始縦ピクセル,同一フレームとみなす横ピクセル長,同一フレームとみなす縦ピクセル長,開始フレーム,終了フレーム]
とすればアルファ付きの映像素材データ等ではさらにファイルサイズを小さくできそうです。
あと、設定アイコンが寂しかったのでアイコン作ってみました。
が、よくみたらこれRunDll32へのリンクだったんですね。
無駄でしたｗ
http://www.mediafire.com/file/2orfdo1dzm922bh/ico.zip
確かに Windows には（標準で）tee コマンドが無いのでコンソールに出しつつファイルに落とせれば便利かもしれません。Unix だとそんな機能要らないんだけど。…と思いつつググったら PowerShell だとワンライナーで書けるようです。
AEでの問題はそれでは何が起きているのか分かりません。詳細にお願いします。
アイコンは単にインストーラでショートカットのアイコンを指定していないのでそうなっているだけで、指定すれば表示されます。
>>いっつぁ さん
ログを増やしたものを作りました
http://umezawa.dyndns.info/utvideo-17.3.0-test0-win.exe
1フレームごとに大量のログが出るはずなので、短い動画で試してください。（そういえば短い動画でも長い動画でも発症するかどうか聞いていなかった気がする）
ありがとうございます。
先の30秒ほどので試してみましたが、かなりログが膨大すぎて、スクロールバック出来る範囲を超えてしまいましたので、
もっと短い2～3秒程度の録画ファイルを作ってログを出してみます。
少々お待ち下さい。
これまで試した範囲では、ソースファイルの長さに関係なく症状は出ていたと思います。
また、報告後エンコード設定を変えて試していた中で気がついたのは、2パスでエンコードを行った場合、解析を行うための1パス目が終了するタイミングでエンコード処理は止まってしまい、2パス目には入れないことです。
印象としてはUtVideoとTVMWの間でソースファイル終端を示すやりとりに齟齬があるのかな?という感じです。
いっつぁさん
デスクトップ等でShiftを押しながら右クリックし、
コマンドプロンプトを開き、
以下の行を張り付けて実行してみてください。
デスクトップにutv_log.txtが出力されます。
cls&&ECHO ログ出力を終了するには [Ctrl]+[C]キーを押してください&&”c:\Program Files\utvideo\utv_logc.exe”>%USERPROFILE%\Desktop\utv_log.txt
梅澤 威志 さん
以下がログと生成結果の動画(ロスレス)です。
https://www.dropbox.com/sh/v1qlmgn0pt99ica/AADE1_VvebFj_YaQTLJS1CZLa?dl=0
texraykさん
リダイレクトは知ってるんですが、前にやったら、画面出力がないのでログの出力終わりが不明で、途中で強制終了させてしまったログになってしまったんですよ。
上で、梅澤さんがPowerShellでならtee的なのが可能のようなこと書いておられるので、調べてPowerShellでやってみます。
ごめんなさいｗ 上記テストVerを入れるときに
PCを再起動したからなのか現象が発生しなくなりました。
正常終了となりますが、
ログだけ入れておきます。
起きなくなりましたか。うーん
以前の詳細ではないほうのログを
ゴミ箱からみつけたので入れておきました。
テストverのログをdropboxにupしました。
https://www.dropbox.com/s/0ssnk1jgydctigk/utv_logc_Rec.log?dl=0
ログがどういうタイミングで出るかが解る方がいいのかと思い、
エンコード中の画面を別のコーデック(AMV4)でデスクトップ録画して、
その動画をupしました。
https://www.dropbox.com/s/6gsman66m25u87v/UtVideoLoging.mp4?dl=0
しかし、この動画を作るために編集していたら、同様の現象が出てしまいました。
以前はAMVコーデックでは出ていなかったように思うのですが、
私の記憶違いだったのか、いろいろやっている内に何かおかしくなっているのか解りませんが
ここまでお手数をかけさせたのに申し訳ないですが、もう一度手元で確認してみます。
これから、どのコーデックのどういう設定で症状が起き、症状が起きないのかを
一個づつ確認・検証してみます。
ちょっと時間が掛かると思いますが、検証結果はこちらにもお知らせさせてもらいます。
ログ見ました。予想したところとは違うところで処理が止まっていました。なんでそこで止まる…
ちょっと考えます。
ところで、止まっている状態でCPUを消費している気配はありますか？
CPUやメモリを極端に消費している様子はありません。
上でも書きましたが、他のコーデックでも発生してしまいました。
なので、もう一度各コーデックで、止まる物止まらない物を確認します。
確認できましたら、どのコーデックのどういった設定でというのをまとめてお知らせさせていただきます。
いっつぁさん
横から失礼します。
動画を見て少し気になったのですが、エンコード処理時にCPUとCUDAが有効のようですが、一度CUDAを切ってCPUのみでエンコードしてみてはいかがでしょうか？
以前私もTVMW5のときにHWエンコードを行った時に、出力が終了せず20時間以上エンコード処理を行おうとしていた時がありました。
この時はPCを再起動するしかリセット方法がなかったです。
*HW = CRI SpursCoder for TMPGEnc
見当違いでしたらすいません。
すいすいさん。
アドバイスありがとうございます。
確かにあり得ると思ったのと、片手間に試せるので、早速やってみました。
CUDAモジュールを読み込まない設定にして再起動し、エンコードをやってみましたが、残念ながら結果は変わりませんでした。
私の方はハードウェアエンコードを行っているわけではなく、フィルタ処理にCUDAを利用されているだけですので、すいすいさんの以前の状況とは違うと言うことなのでしょうね。
>> いっつぁ さん
http://umezawa.dyndns.info/utvideo-17.3.0-test1-win.exe
これで試してみてください。ログの量は test0 よりはだいぶ少ないです。
メモリを破壊していると見てログを仕込んでいますが、狙い通りの情報が取れても、どこで破壊しているのかは直接わからないので頓挫ということになる可能性が高いです（涙
ログ終了時にファイルとしてメモリダンプしてから
コーデックエンジンを終了するとかしてみたら取れそうですね。
＞梅澤さんへ。
検証の途中経過報告です。
まず、どうやらUtVideoCodecが根本原因というわけでは無さそうでした。
ということで、こちらに疑いをかけたことをお詫びさせて頂きます。
現状、自PCにて録画したファイルは試したCodecに関わらず、すてべ同様にTVMWでエンコードが終了できなくなっていました。
そこで、別のCodec類やCodecを組み込みそうなアプリケーションをアンインストールして見たのですが、症状に改善がありませんでした。
どのCodecでも同様になることで、録画ファイルの破損を疑ったのですが、
同じ録画ファイルを別PCに持って行って、TVMW（こちらは5）でエンコード
を行ったところ、問題なくエンコードを終了したため、録画ファイルの
破損というわけでも無さそうです。
今後、クリーンインストール環境を作成し、症状を確認し、
現在の環境に近づけながら、症状が出るかを確認したいと思います。
ということで、どうやら自PCの何らかのCodecないしアプリケーションとの
相互干渉などがあっての症状である可能性が高いと思われます。
何をインストールしたときに症状が出るのかがわかれば報告させて頂きます。
UtVideoCodecに疑いを掛けたこと、重ねてお詫び致します。
＞いっつぁさん
すいすいです。
以前の私の推測は外れていたみたいで、すいませんでした。
最新のコメントを見るとクリーンインストール環境から再度試されるとのことですので、
梅澤さんへのフィードバックをペガシス側にも提供すると良いかもしれません。
また推測ですが、TVMWの読み込みエンジンは独自ので読み込んでいると記憶していましたが、PCがわの環境として再生フィルター（DirectShowとかMedia FoundationとかFFdshowとかLAVFilterとか）が何か不具合を引き起こしているのではないかと思うようになりました。
私もいちユーザーとしてこのデコード問題が何を起因して発生しているかが気になりますね。
検証頑張ってください。
あらっ（＾＾；
しかし、どういう理由で固まるんでしょうかねぇ…確実な再現手順and/or環境が見つかる（=ペガシス側で容易に再現できる）とよいですが。
＞いっつぁさん
別HDDの空き容量に余力があれば、
バックアップと復元にてシステムを別HDDに保存し
その上で怪しいアプリケーションを削除して確認するとか。
このバックアップイメージはvhdですので、
VirtualBOXとかで読み込めます。
http://fanblogs.jp/honeycome/archive/78/0
先の件の報告です。
クリーンインストールの前に、最初に試すべき事を一つやっていないことを思い出しました。
TVMW6自体の再インストールです。Mpeg系やWMV系のファイルは正常にエンコできるため、うっかりしていましたが、上記辺りは多分TVMW内蔵のデコーダを利用するであろう事から、UtやAMV4とは条件が異なります。
で、結果ですがTVMW6を再インストールしたところ、症状は改善し、エンコードは正常に終了するようになりました。
その後、アンインストールしていたcodecやアプリを再インストールしたのですが、今のところ症状が再現していません。
状況から考えて、何らかのアプリかcodecのインストール、あるいはWindowsの更新をした際に、TVMWが外部codecを読み込む際に使用するDLLが別バージョンに書き換わるなどして、そのバージョン違いにより発生した異常だったのではないかと考えています。
Ut以外では動いていたと思い込んだ原因は、最初の症状発生が現環境でUtを導入した時期と重なっていた事と、上記の内蔵codecは正常に動作する事による、私の記憶混乱と思います。
結局、何が根本的な原因と切っ掛けだったのかが解明できず歯痒いですが、こちらでゴタゴタやってしまった者の義務として、一応の解決の報告と原因に対する予測を述べさせて頂きました。
UtVideoCodecに疑いを掛けたこと、重ね重ねお詫びさせて頂きます。
いっつぁさん
すいすいです。
>あるいはWindowsの更新をした際に、
コレがものすごく原因として怪しいですよね。
昨今のWin10のアップデート方式が大型の場合はまるっと差し替えインストール式ですから、外部コーデックを使う内部フィルタ周りで差異が出てしまった気がしますね。
どのみちアプリの再インストールは重要になってきますね・・・。
*私はまだWin7なのでWin10だと色々と検証手順が増えそうですね・・・。
ともあれ、現象が解消されたこと、おめでとうございます。