6

私の目標は、zenity--progressを使用してHandBrakeCLIの出力でgtkプログレスバーを作成することです。私はいくつかの障害に遭遇しました、そして誰かがより良い方法を知っているか、または私が現在していることで私を助けることができるかどうか疑問に思っています。

通常の出力：

HandBrakeCLI -i infile -o outfile --preset=iPad

ディスプレイ

エンコーディング：タスク1の1、11.97％（72.81 fps、平均86.78 fps、ETA 00h00m43s）

HandBrakeはtrおよびcutコマンドにパイプされているので、zenityが期待するパーセンテージしかありません。

HandBrakeCLI -i infile -o outfile --preset=iPad 2>&1 | tr -s '\r' '\n' | cut -b 24-28

私が期待する結果：

1.05 
1.06 
1.10 
1.10

ただし、出力が大幅に遅れ、表示されない場合もあります。tr式のみを使用すると、各行に上記の出力が表示されますが、これは「Encoding：task......」を含む出力全体です。

これは、cutコマンドがHandbrakeの標準に追いつけないようなものです。名前付きパイプを使用して読み上げ、パイプを作成してHandBrakeの出力をパイプに送信し、別の端末でパイプを介してtr and cutコマンドを試したところ、同じ遅延が発生しました。

awkのprintサブストリングを使用しても、同じ遅延が発生します。

私はそれを理解することはできません。HandBrakeジョブがMythTVジョブとして呼び出され、進行状況バーをポップアップして、エンコードがいつ進行中であるかを確認したいので、zenity--progressインジケーターを探しています。

4

2 に答える 2

2

ここで回答された解決策は、stackexchange で使用できます。

例えば：

GNU coreutilsのstdbuf一部であるプログラム。

stdbuf -i0 -o0 -e0 command

別の例はcommandexpectです。unbuffer

unbuffer long_running_command | print_progress

unbufferlong_running_command疑似端末 (pty) 経由で接続します。これにより、システムはそれを対話型プロセスとして扱います。したがって、パイプラインで 4-kiB バッファリングを使用しないため、遅延の原因となる可能性があります。

より長いパイプラインの場合、各コマンド (最後のコマンドを除く) のバッファを解除する必要がある場合があります。

unbuffer x | unbuffer -p y | z
于 2013-01-02T15:26:18.390 に答える
1

最初の投稿で使用するために erik によって提案された UNBUFFER を使用すると、次のコマンドでトリックが実行されます。

( HandBrakeCLI -i infile -o outfile --preset=iPad | 
        unbuffer -p grep -i "encoding: task " | 
        unbuffer -p cut -c24-25 ) | 
        zenity --progress --auto-close
于 2017-04-14T20:17:56.110 に答える