x265 rev3©2ch.net

**名無しさん＠編集中転載ダメ©2ch.net** · 2016/05/03(火) 19:09:55.21

H.265/HEVCのコマンドラインエンコーダーであるx265について語るスレです。
AviUtlやx265guiExなどの話はスレ違いなのでそれぞれの専用スレへどうぞ。

[本家]
http://x265.org/index.html
https://bitbucket.org/multicoreware/x265/wiki/Home

[ソース]
https://bitbucket.org/multicoreware/x265/src
https://github.com/videolan/x265

[バイナリ]
http://x265.ru/en/builds
http://rigaya34589.blog135.fc2.com (右側のメニューの"ビルドしたものとか")

[ビルド方法(MSVC)]
http://rigaya34589.blog135.fc2.com/blog-entry-402.html
http://rigaya34589.blog135.fc2.com/blog-entry-540.html

[ドキュメント]
http://x265.readthedocs.org/en/default/index.html

[諸注意]
x265のrevはMercurial(Bitbuket)とGit(Github)では算出方法が違います。
当スレではMercurial準拠で示すようにして下さい。
次スレは>>980が建てること。

[前スレ]
x265 rev2
http://echo.2ch.net/test/read.cgi/avi/1418252184/

**名無しさん＠編集中** · 2016/09/11(日) 11:02:31.58

再来年にはAVX512が使えるCPU出そうだけどどうなるんだろうな

**名無しさん＠編集中** · 2016/09/21(水) 22:31:27.74

ずいぶん早いなスライスだけで終わりか

**名無しさん＠編集中** · 2016/09/21(水) 23:50:36.79

Merge with default; prep for 2.1

それほど開発進んでいるようには思えなかったけどもう近いうちに2.1出るんだね

**名無しさん＠編集中** · 2016/09/28(水) 00:28:50.54

2.1きたぞ

**名無しさん＠編集中** · 2016/09/28(水) 12:50:43.95

Version 2.1

Release date - 27th September, 2016
Encoder enhancements

Support for qg-size of 8
Support for inserting non-IDR I-frames at scenecuts and when running with settings for fixed-GOP (min-keyint = max-keyint)
Experimental support for slice-parallelism.

API changes

Encode user-define SEI messages passed in through x265_picture object.
Disable SEI and VUI messages from the bitstream
Specify qpmin and qpmax
Control number of bits to encode POC.

Bug fixes

QP fluctuation fix for first B-frame in mini-GOP for 2-pass encoding with tune-grain.
Assembly fix for crashes in 32-bit from dct_sse4.
Threadpool creation fix in windows platform.

**名無しさん＠編集中** · 2016/10/01(土) 08:36:48.35

なんでx265のqcompって0.5より下げられないんだろう？
もっと低い値で使いたいのに

**名無しさん＠編集中** · 2016/10/01(土) 23:17:06.87

qcomp下げたら線が歪まなないか？

**名無しさん＠編集中** · 2016/10/02(日) 02:19:12.84

どういう線？

**名無しさん＠編集中** · 2016/10/02(日) 09:00:33.52

線が歪むかどうかは完全にケースバイケースで
qcompを下げた結果むしろ大人しい場面の線が綺麗になることも普通にあるよ
現状の下限の0.5だと、騒がしい場面を基準にcrfを設定すると大人しい場面での画質がいまいちに感じてしまうんだよな
逆に大人しい場面を基準にcrfを設定すると騒がしい場面までやたら忠実にエンコされてサイズが肥大化しちゃって困る

**名無しさん＠編集中** · 2016/10/02(日) 09:44:16.52

俺は上限ビットレートを制限する派
元ソースより多く割り振っても意味ないし
デブロックフィルタ付きコーデックだからx264は12Mbps、x265は10Mbpsにしてる

**名無しさん＠編集中** · 2016/10/03(月) 13:00:32.32

6Mbpsで試したらそこそこ目的を達成できたから、qcomp < 0.5が実装されるまではそのテクを使わせてもらって生きていくわ

**名無しさん＠編集中** · 2016/10/06(木) 20:13:57.00

つかぬ事をお聞きしますが、
x265はインタレ保持は出来るようになったのですか？

**名無しさん＠編集中** · 2016/10/06(木) 20:25:12.91

HEVCの規格に存在しなかったと思うので㍉

**名無しさん＠編集中** · 2016/10/06(木) 22:23:17.21

>>174
そうですか
ありがとうございます

**名無しさん＠編集中** · 2016/10/06(木) 22:30:31.75

>>174
H.265の規格にgeneral_interlaced_source_flagとかsource_scan_typeというのがあったり
x265にも--interlaceオプションがあるけど、それは関係ないの？

**名無しさん＠編集中** · 2016/10/06(木) 22:36:33.78

一旦フィールド分離してinterlaceオプションでエンコードすればよかったような
ただ正常に再生できる環境があるのかは謎

**名無しさん＠編集中** · 2016/10/07(金) 06:07:20.90

>>177
フィールド分離方法kwsk
俺はインターレースソースをそのままx265の --interlace tff /bff オプション付けただけでエンコードして、
少し縞がでた状態になってるんだけど

**名無しさん＠編集中** · 2016/10/07(金) 07:25:22.16

ぐぐれよそれくらい…

**名無しさん＠編集中** · 2016/10/07(金) 12:45:09.69

>>178
AvisynthのSeparateFieldsかな
フィールド分離しててもAviUtlのx265guiExじゃ多分うまくいかないから注意ね

**名無しさん＠編集中** · 2016/10/08(土) 22:46:06.42

HEVC使うんならインタレ解除してからエンコードする前提で考えるべきだ。
インタレ解除の品質とCPのバランスがいいPS4(PS3よりきれいに解除される)か最新のRadeonで解除してキャプチャーすべし。

**名無しさん＠編集中** · 2016/10/08(土) 23:04:38.26

PS4ってHEVC再生出来るの？

**名無しさん＠編集中** · 2016/10/08(土) 23:24:23.51

ps4でインタレ解除したのをhevcエンコするって事じゃない

**名無しさん＠編集中** · 2016/10/08(土) 23:57:06.64

インタレ解除のためにキャプチャ・・・？そんな面倒なことする人っているもんなのか？

**名無しさん＠編集中** · 2016/10/09(日) 00:31:19.00

横から興味本位でSeparateFields()やって--interlace 1でエンコしてみたけど
出来た動画はmpc-hcでもvlcでもSeparateFields()でぺしゃんこになった映像がそのまま流れるだけだった
>>177の言うように再生環境が整ってないってことか

**名無しさん＠編集中** · 2016/10/09(日) 00:47:23.90

そもそも規格上正しいインターレース動画見かけたことないからよく分からないのよね
フィールド分離するっていうのも多分これで正しいだろうって程度だし

**名無しさん＠編集中** · 2016/10/09(日) 01:59:16.04

https://trac.mpc-hc.org/ticket/5088
ここに添付されてる動画（黄色い枠の下のAttachmentsのとこ）はベルリンの放送局が流したインタレHEVC動画を切り取ったものらしい
スレ主は「LAV filtersを使う別のソフトではちゃんと表示できたのにmpc-hcだと縦半分になっちゃう」って言ってるけど
ってことはインタレHEVC動画をちゃんと再生できるソフトが２年以上前から有るってことだな

**名無しさん＠編集中** · 2016/10/09(日) 02:11:19.92

https://trac.ffmpeg.org/ticket/5514

HEVCのリファレンス実装のhmなら正しくデコード出来るらしい

**名無しさん＠編集中** · 2016/10/09(日) 02:19:35.95

作り方が間違っている訳じゃなさそうだな

**名無しさん＠編集中** · 2016/10/09(日) 11:04:21.51

rigayaさんのところを参考に自ビルドしようとしてるんだけど、Mercurialでのクローンでコケる
二回目の実行だと復元先 ''x265 は空ではありません」と注意されて中止
このMercurialはデフォルトではどこにディレクトリを作るんです？

**名無しさん＠編集中** · 2016/10/09(日) 11:33:52.22

>>190
cd x265
hg pull
hg update
cd ../

**名無しさん＠編集中** · 2016/10/09(日) 12:20:14.96

>>191
ｔｈｘ
ドライブを跨いだディレクトリ移動時は /d をつける超初歩的な事を忘れてたのが原因でした

**名無しさん＠編集中** · 2016/10/09(日) 17:06:11.97

https://builds.x265.eu/
とうとうここ消えてしまった…
便利だったのに残念
っつか困った…

**名無しさん＠編集中** · 2016/10/09(日) 22:27:18.19

>>193
メンテとかじゃなくて消えたのかなあ
昼にはもう繋がらなかったわ

**名無しさん＠編集中** · 2016/10/10(月) 00:53:58.93

>>193-194
こっちだと見れる
https://open.lolicon.eu/

**名無しさん＠編集中** · 2016/10/10(月) 06:04:45.32

マルウェアサイトだな

**名無しさん＠編集中** · 2016/10/10(月) 06:35:41.27

マルウェアの警告とは違うような
他サイト用(おそらくbuilds.x265.eu用？)に発行されたセキュリティ証明書を使用してるって警告じゃない？

**名無しさん＠編集中** · 2016/10/10(月) 09:43:29.66

open.lolicon.eu は不正なセキュリティ証明書を使用しています。
この証明書は builds.x265.eu にだけ有効なものです。
エラーコード: SSL_ERROR_BAD_CERT_DOMAIN

**名無しさん＠編集中** · 2016/10/10(月) 10:44:49.25

http://msystem.waw.pl/x265/
結局ここ使わせてもらうことにした

**名無しさん＠編集中** · 2016/10/13(木) 16:25:16.83

--scenecut　ってまったく機能してないよねぇ？
preset medium で--scenecutの値を40→100→900と変えてエンコしてみたんだけど出力結果が全部同じになった
テストに使った動画には人の目に分かるシーンチェンジが19箇所あるんだが、それを察知してキーフレを挿入してくれた箇所は1箇所のみで
それ以外はシーンチェンジを無視してkeyintのデフォ値の250フレームごとに盲目的にキーフレが挿入されてるだけだったわ

Version 2.1のチェンジログにSupport for inserting non-IDR I-frames at scenecutsって書いてあったから改善に期待したんだが最新版でもダメ
ちなみにx264の方はちゃんと--scenecutの値に応じてフレーム構成が変化してくれた

**名無しさん＠編集中** · 2016/10/13(木) 18:08:10.48

なんか前にもそんなバグがあったな

**名無しさん＠編集中** · 2016/10/15(土) 00:16:40.11

>>200
それ、ちょっと気になってたから0 (たぶん無効)と50でやってみたらサイズが変わった
だからIフレーム自体は適切な箇所に挿入されてると思う
（x264みたく挿入しまくりはしない感じ）

**名無しさん＠編集中** · 2016/10/15(土) 08:54:18.17

>>200
メーリングリストで挙動を質問してみたら

**名無しさん＠編集中** · 2016/10/16(日) 00:23:34.99

それはちょっとハードルが高すぎる

**名無しさん＠編集中** · 2016/10/17(月) 09:20:22.13

cpuが100%行かないんだけどそんなもん？
i7 3770 メモリは16GB
pmodeとpmeは入れても自分のCPUじゃ効果無いかと思って使ってないんだけど入れたほうが良いかな

**名無しさん＠編集中** · 2016/10/17(月) 15:43:02.58

>>205
CPUが100%行けばいいってもんじゃないと開発者側の言葉がどこかにあったと思う。
CPU使用率じゃなくて純粋にエンコード速度だけみてりゃOK的な事だったような。

**名無しさん＠編集中** · 2016/10/17(月) 15:59:11.90

そういうものなのか！ありがとう！
x264使ってた時は100%が当たり前だったからそういうものと勘違いしていた
エンコ速度は・・・すごく遅いｗｗｗ
だから一生懸命仕事してくれているのだろうと思うことにする

**名無しさん＠編集中** · 2016/10/17(月) 16:11:04.38

pmode入れてみたら80%位までは行くようになった
余裕があるっていう感じではないからpmeはちょっと迷うな
機会が有ったらpmeも付けてみて速度比較してみようと思います
ありがとうございました

**名無しさん＠編集中** · 2016/10/17(月) 20:17:27.74

CPU100%行かない場合はどこがボトルネックになってるんだ？

**名無しさん＠編集中** · 2016/10/17(月) 20:18:31.60

メモリアクセスとか

**名無しさん＠編集中** · 2016/10/17(月) 20:24:22.54

無圧縮の映像で読み込みが間に合わないとか
エンコード前のフィルタ処理とか

**名無しさん＠編集中** · 2016/10/18(火) 09:17:06.90

メモリアクセスはCPU使用率にカウントされる。
読み込みが間に合わないのもあるかもしれないけど、
フィルターかけないで転送も間に合ってる場合でもそうなるのは
おそらくスレッド間同期待ちでしょうな。
短い同期待ちはビジーループでCPUを使用するけど、
ある程度待ちが長くなるとCPUを使用しないモードに移行してOSのスケジューラーに制御を任せる。

マルチスレッドアプリってのはスレッドがてんでバラバラに動けばいいというものではなく、
同期して協調しながら動くものだ。

**名無しさん＠編集中** · 2016/10/18(火) 09:26:18.88

>>212
マルチスレッド化で、なんとかの法則（忘れた）の壁にぶち当たってると開発者が言ってた気が

**名無しさん＠編集中** · 2016/10/18(火) 09:57:55.47

マルチスレッド化じゃなくSIMDが占める時間がどうこうって

**名無しさん＠編集中** · 2016/10/18(火) 09:58:28.67

いうアムダールの法則？

**名無しさん＠編集中** · 2016/10/18(火) 12:40:00.08

分割できるタイルの数には限りがあるんだから余るようなら2つ同時に走らせればいいでしょ

**名無しさん＠編集中** · 2016/10/18(火) 20:16:28.32

x265のcrfでエンコした動画をBitrate Viewerに放り込んでもCodec not foundで見れないのですが何か他に良いツールはありますか？

**名無しさん＠編集中** · 2016/10/18(火) 20:20:57.27

>>217
rigayaの日記兼メモ帳 CheckBitrate
http://rigaya34589.blog135.fc2.com/blog-entry-800.html

**名無しさん＠編集中** · 2016/10/18(火) 21:04:14.20

>>218
助かりましたありがとうございます！

**名無しさん＠編集中** · 2016/10/18(火) 21:22:12.77

本当にx264の半分のビットレートで同等の画質だとびっくりしました（自分の眼で見た限り）

**名無しさん＠編集中** · 2016/10/19(水) 01:14:12.55

目眩にも程があんだろ

**名無しさん＠編集中** · 2016/10/19(水) 01:28:25.67

そういう眼なのでまぁ仕方ないですね
静止してコマ送りでもしながら見比べないと分からないので
もっともそんな鑑賞の仕方は普段絶対しないですがｗ

**名無しさん＠編集中** · 2016/10/19(水) 01:43:07.59

うちも病的に録画しまくる親のためにx265で640x360にしてエンコードしてるが
x264からビットレート半分ほどにしても全く問題なく見ていて助かってる

**名無しさん＠編集中** · 2016/10/19(水) 08:54:42.83

実際近い画質にしたいならビットレート抑えるにしても半分じゃなくて7割程度までに留めた方が
でも5割でも気にならない人も多そうだな

**名無しさん＠編集中** · 2016/10/19(水) 09:12:12.96

求める画質にも人それぞれだからね

**名無しさん＠編集中** · 2016/10/19(水) 18:14:11.67

動きの激しい映像はx264よりあんまり減らないよね

**名無しさん＠編集中** · 2016/10/24(月) 13:06:20.83

軽い設定にするとリンギングというかゴーストというかエッジ周辺にそんな模様が浮き上がりやすいような

**名無しさん＠編集中** · 2016/10/30(日) 20:19:33.98

グレインが消えるのは何とかなりませんか？
psy-rdoqを盛れば消えませんか？

**名無しさん＠編集中** · 2016/10/30(日) 21:31:12.51

tuneのgrainを使うとか
バカみたいに膨れるけど

**名無しさん＠編集中** · 2016/10/30(日) 21:56:56.06

こんな感じだな

x265 2.1+028
Xiph.orgのStockholm

--preset slow --crf 18
encoded 604 frames in 54.59s (11.06 fps), 8841.46 kb/s, Avg QP:27.62
SSIM Y:0.924460 U:0.957868 V:0.955896 All:0.935268 (11.888781)

--preset slow --tune grain --crf 18
encoded 604 frames in 148.53s (4.07 fps), 【34693.46】 kb/s, Avg QP:24.04
SSIM Y:0.947751 U:0.956224 V:0.954316 All:0.950258 (13.032736)

--preset slow --crf 13.4
encoded 604 frames in 113.93s (5.30 fps), 【34638.59】 kb/s, Avg QP:23.18
SSIM Y:0.955600 U:0.972801 V:0.967569 All:0.960461 (14.029775)

**名無しさん＠編集中** · 2016/10/31(月) 08:59:25.98

本物グレインを取り去ったあと、
圧縮の効く擬似グレインのようなものを
付ける機能はないものか

**名無しさん＠編集中** · 2016/10/31(月) 18:09:29.71

一口にグレインといっても主に空間的にザラザラなやつと時間的にも非常にザラザラしてるやつとでは扱いが違ってくる

**名無しさん＠編集中** · 2016/11/02(水) 18:21:51.31

>>228
グレインのボケや消失を防止したい場合は真っ先にSAOをオフるといいよ
で、平坦部のザラザラが維持されるようにaq-strengthを1.2や1.3にしてpsy-rdを3や4まで上げる
こうすると処理量やレートを激変させずにとりあえず空間的なザラザラが保持されるようになってコスパがとてもいい

rdoqが出番になるのはこれに加えてグレインのさらさら流れるような時間的性質も保持したいという場合
そういう時はrdoq-level=2、psy-rdoq=50とかにしてみて、物足りなかったらaq-strengthとpsy-rdを更に盛るといい
psy-rdoqは50が最大値だけど10とかに下げても大差ないから弱めたい時は4とか2とかその辺の値に
これでもまだグレインが保持できない場合、その原因はレートの絶対的な不足だから、
あとはcrfを下げるなりして目指すグレイン感が得られるまでレートを盛っていくようにする

ちなみにpresetやtuneの類は基本的にあんまり当てにしないほうがいいよ

**名無しさん＠編集中** · 2016/11/02(水) 18:52:56.39

昔はx265でグレイン保持は無理って言われてたけど今は色々やりようがあるのかな

**名無しさん＠編集中** · 2016/11/02(水) 20:39:07.24

>>233
なるほど aq-strengthを上げてsaoをoffですね。
以前psy-rdoqは10以上まで盛ったことが有るのですが変化をあまり感じなかったので戻していました。
psy-rdを3や4にしても処理量やレートがあまり変わらないのであればちょっと盛って様子を見てみたいと思います。
psy-rdoqに関してはソース次第ということでしょうか。これも様子を見たいと思います。

このページ（http://x265.readthedocs.io/en/default/presets.html）の"Film Grain"を見ると--sao 0 psy-rd 4.0 psy-rdoq 10(と+α)になっていますね。
aqやcutreeを切る勇気は無いのでそのあたりは切らずに、機会が有ったら --sao 0 と psy-rd 4 を試してみたいと思います。
ありがとうございます。

**名無しさん＠編集中** · 2016/11/03(木) 19:52:24.95

RC-grain「そんな…」

**名無しさん＠編集中** · 2016/11/05(土) 14:14:28.54

報告された元々のバグは修正されたみたいだけど、知見を得たとのことなので転載
https://twitter.com/OumaeKumikoBot/status/793861294210199552

muken@黄前久美子猥褻妄想Bot ?@OumaeKumikoBot 11月2日

x265で
--no-opt-qp-pps
--no-opt-ref-list-length-pps
しないとMP4にした時、面倒くさいことになるという知見を得た。
x264での結合する時は--stitchableを指定しないといけないやつみたいなの。

**名無しさん＠編集中** · 2016/11/05(土) 15:24:50.73

面倒くさいって具体的にはどうなるの？

**名無しさん＠編集中** · 2016/11/05(土) 15:30:37.15

何も困ってないけどなあ

**名無しさん＠編集中** · 2016/11/05(土) 17:52:14.03

全く意味が分からん

**名無しさん＠編集中** · 2016/11/05(土) 18:01:51.59

事の発端はL-SMASHでh265をmuxしたらLAVFiltersで再生出来ないmp4が出来たってバグ報告ね
オプション付けたほうが安全なストリームが出来るんだろう多分

**名無しさん＠編集中** · 2016/11/05(土) 18:19:11.94

L-SMASHとLAVFilters、どっちの問題なの？

**名無しさん＠編集中** · 2016/11/05(土) 18:21:30.62

それかx265の問題かもしれんし、その事象の話だけ聞くとどのプロジェクトの問題なのかわからん

**名無しさん＠編集中** · 2016/11/05(土) 18:39:01.91

L-SMASH使ってるが一度もそんなファイル出来たことないわ

**名無しさん＠編集中** · 2016/11/05(土) 18:48:02.33

https://twitter.com/OumaeKumikoBot/status/794836337123725312
echo.2ch.net/test/read.cgi/avi/1462270195/237- …
L-SMASH, ffmpeg両方に問題があった。前者は修正済み。
一般向けに説明すると、キーフレームごとにコーデックのパラメータがIDが同じまま変わる。これをMP4に入れたものには対応していない実装があるので、途中で映像が壊れる。

https://twitter.com/OumaeKumikoBot/status/794838024118906880
x265でエンコードする時に--no-opt-qp-pps --no-opt-ref-list-length-ppsをつけるとキーフレームごとにコーデックのパラメータが変わることが無くなるので、
MP4に入れても多くの実装で再生できる。これらはオーバーヘッド抑制の無効化オプション。

**名無しさん＠編集中** · 2016/11/05(土) 19:03:17.71

一般人はL-SMASHを最新のにすればいいの？
最新のにした上で --no-opt-qp-pps --no-opt-ref-list-length-pps をつければいいの？

**名無しさん＠編集中** · 2016/11/05(土) 19:05:09.45

最新にするならそのオプションは要らないって意味かと思った

**名無しさん＠編集中** · 2016/11/05(土) 19:05:47.67

https://twitter.com/OumaeKumikoBot/status/794839381882245121
なんか、最近になってx265側で実装されたものらしく(私はもうx265追ってません。メーリングリストは見てますが)、
以前は大丈夫だったけど、x265のオーバーヘッド最適化実装によって、いつからか壊れるようになったということです。

https://twitter.com/OumaeKumikoBot/status/794840048105439232
x265で--no-opt-qp-pps --no-opt-ref-list-length-ppsを付けないのであれば、L-SMASHのmuxerはrev1416以降をお使い下さい。
それより前はmux時に3種類目以降のコーデックパラメータでデータが壊れます。

**名無しさん＠編集中** · 2016/11/05(土) 19:19:10.83

1384使ってるけど何の問題もなく再生出来るんだが
だから何言ってるかサッパリだわ

**名無しさん＠編集中** · 2016/11/05(土) 19:27:38.23

>>249
毎回必ずおかしくなるんじゃなくて稀におかしくなるんじゃろ

**名無しさん＠編集中** · 2016/11/05(土) 19:33:52.49

もう何千とファイルあるけど1つもないなぁ
なんじゃそりゃと

**名無しさん＠編集中** · 2016/11/05(土) 19:37:31.80

>>251
問題が発生する可能性があるのは9/28以降のx265らしい

**名無しさん＠編集中** · 2016/11/05(土) 19:46:18.18

2.1+11くらいかな
2、300ファイルが対象だけど問題ないなぁ
問題あったら最新のmuxer使ってみるよ
ありがと

**名無しさん＠編集中** · 2016/11/05(土) 19:52:13.05

まさにその2.1+11使ってたわ…。
10個くらいだからエンコし直すかな。
さっきはsage忘れスマヌ。

**名無しさん＠編集中** · 2016/11/05(土) 20:46:36.02

うわ・・・最近動画再生中に映像だけ止まって狂ってたやつあったけどこいつが原因だったんか...
L-SMASH ビルドしてくるか。MUX 前なんて消しちゃってるしエンコし直しだるいな

**名無しさん＠編集中** · 2016/11/05(土) 20:50:08.89

16^2

**名無しさん＠編集中** · 2016/11/05(土) 20:53:33.03

速効ビルドしてきたがこれなら大丈夫か。

muxer.exe --version

L-SMASH isom/mov multiplexer rev1417 bd95444
Built on Nov 5 2016 20:48:21
Copyright (C) 2010-2015 L-SMASH project

**名無しさん＠編集中** · 2016/11/05(土) 21:31:58.34

>>255
ffmpegに修正が取り込まれたら再生できるようになるんじゃない？
スマホかとPC以外では怪しいかもしれないけど

**名無しさん＠編集中** · 2016/11/05(土) 21:54:07.79

>>258
俺環では mux は L-SMASH でプレイヤー側のデコーダーは LAV。
これで発生しますた。FFMpeg は全くからんでないんで、今回ビルドした r1417 で解決しているらしいから
またちょっと時間出来たらエンコして試さないとです。

**名無しさん＠編集中** · 2016/11/05(土) 21:59:55.69

>>259
LAVFilterはffmpegをエンジンとして使ってるそうだよ
元ソースがあるなら推奨コマンドラインつけて再エンコが確実だろうね

**名無しさん＠編集中** · 2016/11/05(土) 22:16:33.48

バイナリエディタでも修正できるのか