9

高ビットレートの HLS ストリームに継続的なライブ ストリームを記録しています。次に、これを別の形式/ビットレートに非同期にトランスコードしたいと考えています。ほとんどの場合、オーディオ アーティファクトが各セグメント (ギャップとポップ) の間に表示されます。

ffmpeg コマンド ラインの例を次に示します。

ffmpeg -threads 1 -nostdin -loglevel verbose \
   -nostdin -y -i input.ts -c:a libfdk_aac \
   -ac 2 -b:a 64k -y -metadata -vn output.ts

サウンド ファイルの例を調べると、オーディオの最後にギャップがあることがわかります。

終わり

そして、ファイルの先頭が疑わしいほど減衰しているように見えます (ただし、これは問題ではない可能性があります)。

始める

私は、ストリーム全体のコンテキストなしでトランスコーディングが行われているために、これらのアーティファクトが発生しているのではないかと考えています。

HLSストリームに収まるオーディオを生成するようにFFMPEGを説得する方法についてのアイデアはありますか?

** 更新 1 **

元のセグメントの開始/終了は次のとおりです。ご覧のとおり、開始は同じように見えますが、終了は 30 秒できれいに終了しています。非可逆エンコーディングである程度のパディングが予想されますが、HLS がギャップレス再生を行う方法がいくつかあります (これは、カスタム メタデータを使用した iTunes メソッドに関連していますか?)

元の開始 オリジナルエンド

** 更新 2 **

そこで、オリジナル (MPEG2 TS の 128k aac) とトランスコード (aac/adts コンテナーの 64k aac) の両方を WAV に変換し、2 つを並べて配置しました。結果は次のとおりです。

並んでスタート サイドバイサイドエンド

これがクライアントの再生方法を表しているかどうかはわかりませんが、トランスコードされたものをデコードすると最初にギャップが生じ、セグメントが長くなるのは少し奇妙に思えます。どちらも非可逆エンコーディングであることを考えると、パディングが両方に等しく存在すると予想していました (存在する場合)。

** 更新 3 **

http://en.wikipedia.org/wiki/Gapless_playbackによると- 一握りのエンコーダーのみがギャップレスをサポートしています - MP3 の場合、私は ffmpeg でラメに切り替えましたが、これまでのところ問題は解決したようです。

AAC ( http://en.wikipedia.org/wiki/FAACを参照) については、libfaac (libfdk_aac ではなく) を試してみましたが、ギャップレス オーディオも生成されるようです。ただし、後者の品質はそれほど優れていないため、可能であれば libfdk_aac を使用したいと思います。

4

1 に答える 1

0

これは、使用する明示的なツールが含まれているというよりは、概念的な回答です。申し訳ありませんが、いずれにせよ役立つ可能性があります。これにより、処理レイヤーがより複雑になるという犠牲を払って、オーディオ アーティファクトを導入するという問題が解消されます。

私の提案は、圧縮されていない入力オーディオをまったく分割せず、icecast2 サーバー (または icecast が AAC をサポートしていない場合は同様のもの) などのオーディオ プロキシにパイプする連続した圧縮ストリームのみを生成し、分割を行うことです。 /圧縮されたオーディオのチャンクを使用して、プロキシのクライアント側で再結合します。

したがって、ここでの方法は、定期的に (たとえば、60 秒ごとに?) プロキシに接続し、ポーリングしている期間よりも少し大きいオーディオのチャンクを収集することです (たとえば、75 秒相当?) - これを設定する必要があります。いくつかの時点で2つのクライアントが実行されるため、並行して実行する必要があります-必要に応じてcronから実行することも、シェルスクリプトからバックグラウンドで実行することもできます...

それが機能すると、オーディオの一連のチャンクが少し重なります。次に、これらを比較し、各チャンクに固有の中央のオーディオのセクションを分離するために、いくつかの処理作業を行う必要があります...

明らかにこれは単純化ですが、プロキシがメタデータ情報 (つまり、ICY データまたはヒンティング) を追加しないと仮定すると、この方法でオーディオを分割すると、処理されたチャンクをオーディオ アーティファクトなしで連結できるはずです。これは、セットが 1 つしかないためです。元のオーディオ入力の出力とそれらを比較することは、実際には形式についてまったく気にしないため、その時点では単なるバイトであるため、面倒です。

ここでの利点は、オーディオ エンコーダーをクライアントから切断したことです。そのため、別のプロセスを並行して実行して、別の形式やビット レートにトランスコードしたり、他の消費者のためにストリームをより積極的にチャンクしたりする必要がある場合は、そうではありません。プロキシのエンコーダ側で何かを変更します。上記と同様のツール チェーンを使用して、別のクライアントをプロキシに追加するだけです。

于 2013-05-27T05:32:00.917 に答える