|
Tera
2002-10-04 17:34:45 ( ID:ddthquhkz/a )
[ 削除 / 引用して返信 ]
みなさんこんにちは。
さて、TMPGEnc でMPEGを出力したときに、出力先ディスクの空きが足りないと、
「ストリーム書き込みエラー」になってしまいますが、現状では最初からやり
直すしかありません。
私は時々これをやってしまいます。特に、8 時間とか 10 時間のエンコードで
97% 終了したところで「ストリーム書き込みエラー」になったときは泣くに
泣けないです。
そこで、「ストリーム書き込みエラー」になったときに、再試行で続行できる
ようにする事はできないでしょうか。もし、OK だけでなく、再試行ボタンがあ
れば、間にファイルを退避させるなどして出力を完了でき、とてもありがたい
です。
エンコードの中断はキャンセルできるので、結構簡単にできそうに思うのです
が、どうでしょうか?
POP
2002-10-04 17:57:31 ( ID:bziuu02jpsm )
[ 削除 / 引用して返信 ]
Teraさんの要望に対しては、「中断」とか「レジューム」という単語で過去ログを検索すれば、どのような話しがされてきたのかがわかると思いますので調べてみてください。
> 出力先ディスクの空きが足りないと、「ストリーム書き込みエラー」になってしまいますが
これは私はこういうものだ、、、と思っています。そして、ハードディスクの空き容量の管理は、基本的にユーザーの責任だと思います。ですからこの点についてはTeraさんが管理するのがベストだと私は思います。
す
2002-10-04 18:52:34 ( ID:nnsvmkybmuw )
[ 削除 / 引用して返信 ]
ま、しかし、できたらできたで、親切ではあるかも、ですね。:-)
Tera
2002-10-04 20:01:58 ( ID:ddthquhkz/a )
[ 削除 / 引用して返信 ]
みなさん、こんにちは
POP さん:
>Teraさんの要望に対しては、「中断」とか「レジューム」という単語で過去
>ログを検索すれば、どのような話しがされてきたのかがわかると思いますの
>で調べてみてください。
検索してみました。私の書き方が悪いせいか、誤解を与えてしまったようで
申し訳ありません。サスペンドや電源断を乗り越えて中断したいという意味
ではありませんでした。これが無理だということは理解しています。
そうではなく、エンコード中に中断ボタンを押すと「エンコードを中断しま
すか?[はい][いいえ]」というダイアログが出てきますが、ここで[いいえ]を
押すと何事もなかったようにエンコードを継続しますよね。
「ストリーム書き込みエラー」ダイアログでも、このように動作すれば、こ
のエラーが出ている間に、エクスプローラなどを使って、ディスク上のファ
イルをバックアップし、ディスクが空いてから再開することができ、とても
助かる、ということが言いたかったのです。
これが容易なことかどうかは作者の堀さんでないと決められないとは思いま
すが、単にファイル書き込み関数を呼びなおすのではいけないのかなぁと思っ
てしまいます。……そこが素人の浅はかさ……なんでしょうか?
>>出力先ディスクの空きが足りないと、「ストリーム書き込みエラー」になっ
>>てしまいますが
>これは私はこういうものだ、、、と思っています。そして、ハードディスク
>の空き容量の管理は、基本的にユーザーの責任だと思います。ですからこの
>点についてはTeraさんが管理するのがベストだと私は思います。
重々ごもっともです。確かに私の責任です。普段から注意はしているのですが、
時たまうっかりやってしまうのです(^^;
# CQ-VBR の時とか、pagefile.sys が増大したとかで(^^;;;;
す さん:
>ま、しかし、できたらできたで、親切ではあるかも、ですね。:-)
本当にそう思います。可能なら実現してほしいです。
長文失礼しました。
yammo
2002-10-04 20:25:24 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
> Teraさんの要望に対しては、
> 「中断」とか「レジューム」という単語で過去ログを検索すれば、
> どのような話しがされてきたのかがわかると思いますので調べてみてください。
レジュームとはまた別だと思いますよ。
空き容量チェックと書き出しでディスクの空きがなかったときに、
続きを処理するかキャンセルするかを選べるようになっていると
いいですね。
私も、無いよりはあったほうが良い機能だとは思います。
fay
2002-10-04 22:35:24 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
ようするに空き容量を空けるように警告を出してエンコードを一時止めるような
機能があれば良いということでしょうか？ まあ、今のままでは書き込みに行って
初めて空き容量がないということが分かるため、警告を出して止めるということは
まず無理です。エンコード処理はどこででも止められるものではありませんので。
常時空き容量をチェックして、一定以下の空き容量になった場合に警告を出して
止められるところで止めると言うのが現実的でしょうか。しかしそのような処理を
行なうとエンコード全体の速度が若干なりとも落ちますので、付けないで欲しいと
いう人もいるかと思います。
Tera
2002-10-05 00:26:32 ( ID:ddthquhkz/a )
[ 削除 / 引用して返信 ]
fay さん:
>ようするに空き容量を空けるように警告を出してエンコードを一時止めるような
>機能があれば良いということでしょうか？ まあ、今のままでは書き込みに行って
>初めて空き容量がないということが分かるため、警告を出して止めるということは
>まず無理です。エンコード処理はどこででも止められるものではありませんので。
私が当初考えていたのは、書き込みにいってはじめて空き容量がないというこ
とがわかったとき、続行するかどうかダイアログで質問して、続行する場合は
もう一度、書けなかったデータを書き込みにいくというものです。
書き込み失敗が、書き出し中のファイルに何か破壊的な影響を与えない限りは、
いかにも警告+質問ダイアログで止まってくれそうですが、だめでしょうか?
>常時空き容量をチェックして、一定以下の空き容量になった場合に警告を出して
>止められるところで止めると言うのが現実的でしょうか。しかしそのような処理を
>行なうとエンコード全体の速度が若干なりとも落ちますので、付けないで欲しいと
>いう人もいるかと思います。
こちらの方式は、書き込み失敗を避けられる点で、汎用性は高いと思います。
ご指摘のとおり速度の点で問題があるので、この方式にする場合は機能を切れる
ようにする必要があるかもしれません。使えるかどうかはどの程度遅くなるか次
第だとおもいます。
yammo
2002-10-05 18:08:30 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
fay さんへ
> まあ、今のままでは書き込みに行って初めて空き容量がないということが分かるため、
> 警告を出して止めるということはまず無理です。
ビットレートなどから大まかでも書き込みをする前の段階でも
空き領域があるかどうかは判定できると思いますが、
いかがでしょうか。
> エンコード処理はどこででも止められるものではありませんので。
それを言ってしまっては、
「中断」のボタンと機能の立場がないような気がします。
内部的にはどうなっているのかはわかりませんが、
エンコード中押すことができて、中断するのも、エンコードを再開するのも
できていますから、今回の要望もそれに近い感じの事を指していると思います。
> 常時空き容量をチェックして、一定以下の空き容量になった場合に警告を出して
...中略...
> しかしそのような処理を行なうとエンコード全体の速度が若干なりとも落ちますので、
> 付けないで欲しいという人もいるかと思います。
何かしらの処理が増えるわけですから、
遅くなることはあっても、変わらないあるいは早くなることは無いでしょう。
しかし、エンコードやファイルの処理に比べたら、
空き領域のチェックは無視できるぐらい短い時間でできる可能性も
あるのではないでしょうか。
ファイルの書き込み処理命令ごとに
空き領域チェックをする必要があるかどうかは別だとは思いますが、
検討しても良い機能だとは思っています。
fay
2002-10-05 18:27:30 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
> > エンコード処理はどこででも止められるものではありませんので。
> 「中断」のボタンと機能の立場がないような気がします。
中断ボタンは、内部的にはTMPGEncが一番止めやすい一定の位置で止まっているで
しょうから、エラーが起きた時の止め方とは違いがあると言いたかったわけです。
また空き容量の取得にはさほど時間は掛かりませんが、頻度次第では影響がないと
は言えません。TMPGEncではGOP単位で書き込みをしますのでそのたびにチェックす
ることになります。少しでも速くして欲しいと言う要望もある中ですし、付けると
したらオプションになるのでしょうね。技術的に付けるのが難しいということはな
いはずですし。
yammo
2002-10-05 22:31:05 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
どうも、yammoです。
fay さんへ
>また空き容量の取得にはさほど時間は掛かりませんが、頻度次第では影響がないと
>は言えません。TMPGEncではGOP単位で書き込みをしますのでそのたびにチェックす
>ることになります。
書き出し先の空きが無くてとまってしまうとき、
どういう動作をしたのかはっきりと覚えていませんが、
書き出し中に空きがないと、「ストリーム書き込みエラー」というダイアログに
「OK」ボタンのみだったように記憶しています。
書き出すデータは、ディスク＋メモリ上の管理情報、
あるいはメモリ上にあると思いますので、
書き出しで、書き込めなくてエラーが帰ってきたときは、
プログラム的に判定できると思いますし、
書き出し処理直後のエラーが帰ってきた直後は、書き出す前の時点の状態や情報は、
全て残っている、あるいは残っているようにすることも
比較的容易では無いかと思いますので、
もちろんディスクを開けるのは操作者が行う必要はありますが、
そこから再開させることも実現可能ではないでしょうか。
また、ある単位で書き出すたびにチェックしなくても、
書き出し処理が成功しなかったエラーを受け取ったら、
停止して、「再試行」か「中断」を選べるようにして、
再試行であれば、そのエラーが起こったときのデータから
書き出しを始めるというのは、特別なことではないように思います。
フィルターやエンコード処理と書き出しの処理の絡みで、
上記の事が実は困難ということでしたら、しょうがないとは思いますが、
動作的にもそんなに特別な機能だとも思えない気がするのは私だけでしょうか。
dia
2002-10-05 22:52:17 ( ID:fomhn2qgefk )
[ 削除 / 引用して返信 ]
TMPGEncの内部処理を知らない者ではありますが、
リアルタイムでのキャプチャならともかく、
ファイルから入力してデータ変換してファイルに書き出しているだけなら
Writeエラー発生時にダイアログを出して、その後にリトライすることは、
やろうとすればできて当然かと思います。
# それとも、エラー発生時に中途半端なデータがWriteされて
# どの程度Writeされたのか不定となるなどといったことが
# あり得るのでしょうか？？
匿名さん
2002-10-06 03:26:12 ( ID:s7anaa0hwjn )
[ 削除 / 引用して返信 ]
># それとも、エラー発生時に中途半端なデータがWriteされて
># どの程度Writeされたのか不定となるなどといったことが
># あり得るのでしょうか？？
あり得ると思います。というか遅延書込み（ライトキャッシュ）を
サポートしているＯＳでは当然のことではないかと。
ライトキャッシュが働くシステムの場合は
エラーの発生はTMPGEncがファイルに書き出したときとは限らず、
（この時点ではキャッシュに蓄えられるだけ）
キャッシュに蓄えられていたデータが（ＯＳによって）実際にＨＤＤに
書き出されるときに発生すると思われます。
TMPGEnc側としては実際にHDDに書き出されなくても、キャッシュに収まれば
そのデータの書き込みは成功したことになりますので、
いざエラーが出た時点では、いつ払い出したデータからやり直せばよいかは
TMPGEncにはわからないのではないかと思います。
プログラム的に回避するなら、データを書き出す前に
データのフラッシュ（キャッシュのデータをすべてＨＤＤに吐き出す）を
すべてのプログラム（TMPGEncだけでいいはずはない）について実行した後、
ＨＤＤの容量チェックを行う必要があるのではないでしょうか？
KOIKOI
2002-10-06 07:07:56 ( ID:8zuvl5msklf )
[ 削除 / 引用して返信 ]
発想を逆にすると・・・。
エンコードしたファイルを置くドライブの空き容量の問題なわけですが。
エラーが出て、初めて、不要なファイルの移動や削除を行うのではなく、エンコード前に
移動・削除を行なっておけば問題ないのでは？
８０ＧＢのＨＤＤでも１万円ちょっとの時代ですし。
他のエンコーダ、ＣＣＥやＰａｎａのMPEG1&2でも、こういった機能は無いのですから。
それと、ＯＳがエラー表示してからでは遅い（はず）です。
確か仕様でＤＯＳ時代から、途中どこまで書き込んだかは保証されません。
TMPGEncはどういったタイミングで書き出しているか知りませんが、正確にどこまで
書き込めたかチェックするとなると、いったんクローズして、クローズが成功したかを
確認するしかありません。
当然、オープンとクローズが頻繁に行なわれるので、動作は遅くなります。
別な方法では、エンコード前に空きを確認するというのもありますが、Windowsの場合
マルチタスクで動作することが求められるので、このようなリソースの独占を前提とした
プログラミングは出来ません（少なくとも推奨されません）。
私としては、無理に付けるような機能ではないと思います。
Tera
2002-10-06 17:33:55 ( ID:ddthquhkz/a )
[ 削除 / 引用して返信 ]
匿名さん:
>># それとも、エラー発生時に中途半端なデータがWriteされて
>># どの程度Writeされたのか不定となるなどといったことが
>># あり得るのでしょうか？？
>あり得ると思います。というか遅延書込み（ライトキャッシュ）を
>サポートしているＯＳでは当然のことではないかと。
KOIKOIさん:
>それと、ＯＳがエラー表示してからでは遅い（はず）です。
>確か仕様でＤＯＳ時代から、途中どこまで書き込んだかは保証されません。
>TMPGEncはどういったタイミングで書き出しているか知りませんが、正確にどこまで
>書き込めたかチェックするとなると、いったんクローズして、クローズが成功したかを
>確認するしかありません。
この辺の動作をはっきりさせるためにもちょっと調べてみました。
間違っていたらご指摘ください。
MS-DOS 2.0以前 (Write FCB):
書き込むとバッファにたまり、バッファがいっぱいになると実際に
書き込まれる。どの程度書き込めたか不定になる、ならないという
記述はみつけられなかった。
MS-DOS 2.0以降 (Write handle):
書き込みに成功すると、書き込んだバイト数が報告される。1バイト
でも書き込めると、成功扱いになる。書き込み済みバイト数が0のと
き空きがない。空きがないというエラーは存在しない。
16bit Windows (_lwrite):
書き込みに成功すると、書き込んだバイト数が報告される。ネット
ワーク接続などでは書こうとしたバイト数よりも少ない量を書き込ん
で成功することがあるが、ハードディスクなどではすべて書き込むか
エラーになるかしかない。エラー時には中途半端に書き込むことは
ない。
32bit Windows (WriteFile):
通常は、書き込みが完了するまで制御が戻らない。ネットワーク接続
などでは書こうとしたバイト数よりも少ない量を書き込んで成功する
ことがある。書き込みの成功、失敗にかかわらず書き込んだバイト数
が報告される。
非同期で書き込みをする場合、専用のデータ領域を指定し、そのデー
タ領域に結果が記録される。ここに書き込んだバイト数も記録される。
という具合になりました。Windows では、この結果を見る限り、たし
かに途中どこまで書き込んだかは保証されないようですが、どこまで
書き込めたかは検出できるようです。
|