 Re: Webラジオの保存方法の質問はこちら【22】 ( No.8 ) |
- 日時： 2015/12/31 14:58
- 名前： りんりん
- >>6
>>7
私がもたもたしている間に解説ありがとうございます！（笑）私の方が横やりになってしまいましたね……（汗）
しかもバッチまで！素晴らしいです！！！
これさえあれば、私の解説はもう蛇足になってしまうのですが、一部おひげさんと違う意見の部分がありましたので、私も一応書かせていただきます。
>>5
お手間を取らせてごめんなさいでした！今日は AniLabo は更新無かったのですね（笑）
いずれにしても、ちゃんとダウンロード出来てよかったです。
まず、最初にお断りしておきますが、私は FFmpeg についてそんなに詳しくないです。ですから、推測が多く混じった説明になってしまいますが、その点は許してくださいね。
まず、以下に AniLabo 第17回を No.4 の書式でダウンロードしたときのコマンドプロンプトの表示の一部をコピペします。
（ダウンロード中に CTRL+S を押すと、処理を途中で止めて確認することが出来ます。何かキーを押すと再開します）
Input #0, hls,applehttp, from 'https://vms-api.hibiki-radio.jp/api/v1/videos/playlist.m3u8?token=lFwUmp8H9FfBcWNMWkizqrEo38YKbsudXXULKMZLsD8%3D&vms_video_id=494&user_id=-1':
Duration: 00:10:31.58, start: 1.400000, bitrate: 0 kb/s
Program 0
Metadata:
variant_bitrate : 72000
Stream #0:0: Audio: aac (HE-AACv2) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 62 kb/s
Metadata:
variant_bitrate : 72000
Program 1
Metadata:
variant_bitrate : 3689000
Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 135 kb/s
Metadata:
variant_bitrate : 3689000
Stream #0:2: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p, 640x358 [SAR 10561:10560 DAR 59:33], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Metadata:
variant_bitrate : 3689000
Program 2
Metadata:
variant_bitrate : 5227000
Stream #0:3: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 135 kb/s
Metadata:
variant_bitrate : 5227000
Stream #0:4: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 640x358 [SAR 10561:10560 DAR 59:33], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Metadata:
variant_bitrate : 5227000
[mp4 @ 0679e920] Codec for stream 0 does not use global headers but container format requires global headers
[mp4 @ 0679e920] Codec for stream 1 does not use global headers but container format requires global headers
Output #0, mp4, to 'C:\Users\##################\Downloads\Downloads_2\HibikiTool300_beta7\HibikiTool300_beta7\download\AniLabo 隨ｬ17蝗・mp4':
Metadata:
encoder : Lavf57.19.100
Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 640x358 [SAR 10561:10560 DAR 59:33], q=2-31, 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
Metadata:
variant_bitrate : 5227000
Stream #0:1: Audio: aac ([64][0][0][0] / 0x0040), 44100 Hz, stereo, 135 kb/s
Metadata:
variant_bitrate : 5227000
Stream mapping:
Stream #0:4 -> #0:0 (copy)
Stream #0:3 -> #0:1 (copy)
まず、「Program 〜」というのが 0〜2 まであることに注目して下さい。
それぞれを見ていくと中に「Stream #0:〜」という記述があり、
Program 0 に Stream #0:0（ビットレートが 72000 の音声ファイル）
Program 1 に Stream #0:1（ビットレートが 3689000 の音声ファイル）
Stream #0:2（ビットレートが 3689000 の映像ファイル）
Program 2 に Stream #0:3（ビットレートが 5227000 の音声ファイル）
Stream #0:4（ビットレートが 5227000 の映像ファイル）
となっています。そして最後の「Stream mapping:」を見て下さい。多分、
「Stream #0:4 -> #0:0 (copy)」 が「Stream #0:4（ビットレートが 5227000 の映像ファイル）を #0:0 としてダウンロード（今回の設定だと無変換でコピー）」
「Stream #0:3 -> #0:1 (copy)」 が「Stream #0:3（ビットレートが 5227000 の音声ファイル）を #0:1 としてダウンロード（今回の設定だと無変換でコピー）」
という意味だと思います。これがデフォルトの設定だと
「Stream #0:2 -> #0:0 (copy)」→「Stream #0:2（ビットレートが 3689000 の映像ファイル）を #0:0 としてダウンロード（今回の設定だと無変換でコピー）」
「Stream #0:0 -> #0:1 (copy)」→「Stream #0:0（ビットレートが 72000 の音声ファイル）を #0:1 としてダウンロード（今回の設定だと無変換でコピー）」
となってしまいます。
ここは完全に私の当て推量ですが、FFmpeg は（特に指定がない場合）、
・映像ストリームの内の1番若い番号のものを「#0:0」として
・音声ストリームの内の1番若い番号のものを「#0:1」として
処理するのではないでしょうか。
今回の AniLabo 第17回の映像が乱れた件に関しては、「ビットレートの違う動画と音声の組み合わせのせいで問題が起きたのではないだろうか？」と最初私は考えました。
しかし、Stream #0:1 と Stream #0:2 の組み合わせでダウンロードしたものも、やはり映像が乱れます。
そこで、改めて観て気付いたのですが、パーソナリティの画像は崩れていますが、テロップはそれほど崩れていません。
とすると、 Stream #0:2 を構成する実写映像部分に何かしらの問題があったのではないでしょうか？
つまり、響のコンテンツ作成段階でのミスではないかと私は考えています。
他のラジオがダウンロードできなくなる現象に関してはおひげさんと全く同じ意見です。
長くなってしまって、本当に申し訳ありません。ここまで読んでくださった方、本当にありがとうございましたっ！
追記
ごめんなさい（汗）
今、低ビットレートの方を最後までちゃんと観てみましたが、後半部分と比べると、明らかに前半部分はテロップも乱れてますね（汗汗）
これは実写部分だけの問題ではないですね（笑）。訂正せていただきます！（苦笑）
追記 その2
たびたびでごめんなさい（汗）
今、高ビットレートの方も最後まで観てみたのですが、こちらも前半部分の方が後半部分より画質が落ちるような気がします（汗汗）
これは配信されている元ファイルに何か問題があるのではないでしょうか？？？
|
|