Linuxでテレビ総合スレ 避難所 2
■ このスレッドは過去ログ倉庫に格納されています
PE4シリーズは無理してPCIeにつなぐ必要ないけどな。 最近Q3U4+ラズパイ+px4_drvという環境を構築したのですが、
ラズパイを再起動するとQ3U4の認識に失敗して/dev/px4video*が登録されない、
という症状が頻繁に発生し、悩んでいます。
そもそもLinuxのドライバ読み込み処理そのものに原因があるような気もするのですが、
回避する方法はないものでしょうか。 gpio使ってQ3U4か間に挟んだセルフパワーHUBの電源OFF/ONするっていうのはどう? >>789
本当にご迷惑おかけしました…。まだ当分チューナを使って遊んでると思うので、不具合らしいものがあったらまた頼らせていただきます。
私はとりあえず動いたらいいなぐらいな気持ちで、amazonでとりあえず動かせそうなものを買いました。
http://amzn.asia/d/9PIMONf
これですが、特にPCIEx1に刺さなくても補助電源をさすだけで動いてます。
電源はペリフェラルのACアダプターからとってます。
https://www.yodobashi.com/product/100000001003807353/
あとはAINEXのUSBのメスとピンヘッダ変換パーツを使って接続して使えてます。
http://amzn.asia/d/gKJuhO3
まあこれだとW3U4とやってること変わらないんですけどね…
Rock64はRaspberry piと似ているみたいですので、多分同じような方法で、あとは認識さえすれば使えるのではないかなと思います。 RPi使っている人ってケースというか本体以外も含めた収納どうしてるんです?
以前、本体、USBハブ、チューナー、 HDDとかを100円ショップのプラスチックケースに
ひとまとめにして使ってたんだけどケーブルが思ったより曲がらなくて意外と場所を取る
のと性能とか安定性(px4_drvの話ではないです)とかも含めていまいち気に入らなかった。
やっぱりHDDを内蔵できるケースでCeleronでもPCが良いなあと。でも小型のやつ。
PCG3みたいにケース作るの憧れる。 Chinachuを導入しようと思ってかれこれずっとAir待ちぼうけなんだけど、最近はEPGStationが勢いあるのね。
EPGStationの方が新しい分こなれてるっていう意見はちょくちょく見かけるけど、逆にChinachuじゃないと
出来ないことって何かあります? Harekaze for Kodi でkodi経由の録画
ルール作成時に複数局指定
こんなもんかな なるほど。ルール設定時に複数局指定できないのは運用次第では辛そうだけど、
そのうち実装されそうな気もする。
これからEPGStationセットアップしてきますわ、サンクス。 >>794
いえいえお気になさらず〜
ありがとうございます。
なるほど。こういったライザーカードでも動作するのですね。
参考になります。
一応手元にはAINEXの変換ケーブルがあったので、試しにQ3PE4を別PCのPCIe x1スロットに接続して電源を入れておき、USB変換ケーブルを使ってRock64に繋いで、mirakurun等を使用せず録画コマンド単体で8ch(地デジx4,BSx4)の録画をしてみました。
数分程度録画してみましたが、録画し始めを除いてドロップは無かったので、期待できそうな感じでした。 特に問題なくEPGStationインストールできたまではいいが、なぜかGRのU局だけが
http://localhost:8888/api/channels に登録されているにもかかわらず
WebUIに表示されないの何でなんですかねぇ・・・
(config.jsonのexcludeServicesは設定していないです) 局情報は取れていても、番組情報が取れていなくて表示されないのでは? >>803
少しでも助けになったのであればよかったです。やはり給電さえできればとりあえずは何でもいいのかなという感じはします。
Rock64ってUSB3.0があるおかげであんまり帯域を意識しないでも使えそうですよね。
また、mirakurunで録画が数分から10分程度で切れる不具合発生、、、
と思ったら、HDDケースかHDDそのもののどちらかがおかしかったみたいです。
2ch分録画するだけでなぜか録画が勝手に終了してたり、して共通項をずっと探してたら、合計1GB程度でファイルが途切れていました。
しかし、作者様が8ch同時録画でも大丈夫だったとのことで、流石にCPUの性能不足の線はなし。となるとストレージ?
と、考え込んでいたらasyncでHDDを読み込んだことが関係ありそうだったので色々調べたら原因はストレージだったという、、、
windowsマシンに繫いで大容量のデータを送信したら、400MB程度でなぜか全く書き込めなくなってしまってました。
まだしっかり切り分けできていませんが、あとはPCのSATAに直接繋いで挙動を確認です。
本当に今回は想定外のトラブル続きで勉強になります。 >>805
恐らくそんな所だと思ってrivarunを直接立ち上げて表示されないチャンネルに合わせたら直後に表示されました。
ただ1局合わせただけで見えてなかったU局2つ同時に表示されるようになったのがよくわからん。
ちなみにUbuntu18.04標準リポジトリに入ってるffmpegパッケージインストールしたけど、config.jsonに
記述されたデフォルトパス(/usr/local/bin/)と違いますね。ちょっとハマった。(/usr/bin/)
しかしストリーミング配信chinachuより重いな・・・HWエンコじゃないとちょっとやってられない。 >>807
一気に見えるようになったのはepgstation側の更新のタイミングかと
デフォで10分毎に更新のはず
ffmpegのオプションがveryfastだからchinachuに合わせてultrafastにすれば同じになると思うよ ffmpegはソースからビルドする人も多いし、複数入れることもあるからパス変えられると便利
chinachuは自前ビルドのffmpeg内蔵してるけどvaapi使うなら消してグローバルに入れ直す必要あるんじゃなかったかな ultrafastはビットレを盛るかQPを15未満ぐらいにしないとエグい画質になるぞ。
圧縮率も悲惨だし。トランスコーダの軽さ重視で見て消すだけの用途なら
そこまで気にしなくていいと思うけど px4_drvの作者です。
そういえば今までどこにも書いていなかったのですが、Raspberry PiのようなARM系CPUのコンピュータでpx4_drvを使う際には、カーネルのコマンドラインに
coherent_pool=4M
を追加することをお勧めします。
カーネルコマンドラインはRaspberry Piの場合、/boot/cmdline.txtに記述されています。 (本文が長すぎると言われたので分割)
そして、少し気になってRaspberry Pi 3 Model B(B+ではないです)にQ3PE4を >>803 と同じようにして繋いでみました。
自作したリアルタイムにドロップチェックができる録画コマンドを使用し、出力先に/dev/nullを指定して8ch(地デジx4,BSx4)の録画をしてみましたが、Rock64の場合とは異なりドロップがポロポロと継続的に出てしまいました。
ただしCPU使用率は8プロセス合計でも10〜15%くらいでしたので、性能不足というわけではなさそうです。
6ch(地デジx3,BSx3)でも、ドロップが出たり出なかったりしましたので、Raspberry Piで安定的に録画できるのは4ch(地デジx2,BSx2)までだろうと思います。ですが、BSx2ではなくCSx2だと少々厳しいかもしれません。
BS/CSの録画を行わなずに地デジの録画のみを行うのであれば、もう少しチューナー数が増えても問題ないかもしれませんが。 (本文が長すぎると言われたので分割その2)
ただ、Rock64で試したときはなんとなくupstreamカーネル(4.19.4 SMP PREEMPT)を使用したので、PREEMPTでないカーネルだとRock64でも結果はRaspberry Piの場合と同じになるかもしれません。
(逆にRaspberry PiでもPREEMPTなカーネルを使うと8chでも問題なかったりするかも?)
あとは、Rock64とRaspberry PiのUSBポートの割り振り方の違いが影響していたりするのでしょうか。
Rock64の3つのUSBポートはRaspberry Piとは違って、それぞれが独立したルートハブに接続されています。
>>806
もしかしてUASPが不安定だったりしませんか?
HDDとケースの組み合わせによっては、大容量の転送を行うとディスクの読み書き操作がフリーズすることがあるようです。 PLEXのデジベスト系チューナーのそういう問題はもともとチューナー側USBコントローラの問題なんだから
ホスト側コントローラとの相性が悪ければLINUX・WINDOWSに関係なくそうなる epgstation でエンコードオプションいじってるんだけど
エンコード後のファイルが登録されないのはなんでだろう?
具体的には
{
"name": "H264",
"cmd": "/bin/bash %ROOT%/config/enc.sh main",
"suffix": ".mp4",
"default": true
},
を、書き換えて
{
"name": "H264",
"cmd": "/bin/bash /home/epgstation/bin/AmatsukazeAddTask.sh mp4",
"suffix": ".mp4",
"default": true
},
みたいにして、実際にエンコード自体は出来ていて、ファイルも
出来ているのだが、録画一覧とか録画詳細で、H264ボタンが出ない。
このへんはどこをいじればいいのだろうか? エンコード後にepgstationで指定している出力先にファイル置いてる?
環境変数OUTPUTで渡ってくるやつ
あとはコマンドの戻り値がおかしいとか
ログ見りゃ分かるよ ファイルは指定先に置くようにしているし、実際にできてる。
コマンドの戻り値見てなかった。チェックしてみる。
ありがと。 連投すまん。
ログみたら答えが書いてあった。
AmatsukazeAddTask.sh を実行後に、即座にOUTPUTにファイルを
作ってあげないと、登録に失敗するみたいだったので、touchで
空のファイルを作ってあげることで解決した。
これでガンガンエンコードできる。 それだとファイル容量正しく認識できないから駄目なのでは?
エンコード完了までスクリプト側で待つようにしないと >>815
enc.shかエンコード待ち時間が終わる時点で
エンコード済みファイルがあるかどうかチェックするんだよね
なので非同期なenc.shだとファイルが無いんでとうろくされない
エンコ時間かかりすぎてもだめ
待ち時間はconfig.jsonに設定する。rateだっけな? rate=40にして呼び出してるけど
logoや字幕外字でペンディングする事もあるからtouchでもいいのかもね なるほど、たしかにファイルサイズが0だw
enc.sh の終了見てるなら、ファイルができるまでずっとsleepのloopして
いるようにして、待てばいいのかな。
まあ、サイズ表示が0以外に問題が出たら考えよう。 スカパースレでMax M4の真ん中の端子が地デジ用だと知って驚愕しつつ試してみたら感度が良くなった
NHK(27ch)の信号強度
ブースターで増幅した後に4分配 = 25dbm
ブースターなしで真ん中の端子のみ = 30dbm
以前は拾えなかった地方局のチャンネルも見えるようになった
普段使わないようなコネクタだったから下のやつで変換してる(ドイツのテレビで使われてる規格っぽい?)
ttps://www.amazon.co.jp/gp/product/B01KBUIDA2/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
ファミコンのテレビ端子みたいな見た目だけど大きさ違ったから注意したほうがいいかも EPGStationならMySQLサーバ内に全部レコード登録されてるから、selectコマンドで引っ張り出せるな。やったぜ!
$ ruleid="$(sudo mysql -u root -N -B -e "select ruleId from epgstation.Recorded where programId = ${PROGRAMID}")"
$ keyword="$(sudo mysql -u root -N -B -e "select keyword from epgstation.Rules where id = ${ruleid}")"
$ echo "${keyword}" left outer joinでSQLを一回にできんかと思ったが俺の知能では無理だった んぁー、rootアカウントのシェルからキックした時はちゃんとselect結果
変数に格納されてるのに、EPGStationで実行すると空になるのなんでだ。
録画終了時コマンドrootで実行されてるから大丈夫だと思ったのに・・・ select Rules.keyword
from Recorded
inner join Rules on Recorded.ruleId = Rules.id
where Recorded.programId = ${PROGRAMID} EPGStationはrootでシェル実行なんかしないと思うが touch だと問題が出たw
ts残さない設定にすると、キューに登録しただけでエンコ終わったと
間違えられてしまい、tsファイルが消されてエンコに失敗することが
判明した。
対策すっか。 >>815を見るにバッチのキューに登録してるものと推察するが、
俺もエンコはバッチ処理でやって欲しいなあ なるほど別のバッチマネージャ的なものにキュー登録してるのか
ならその完了を待つ部分は自作になるな
EPGStation自身に非同期のジョブ管理機能があればいろいろできそうだが(ジョブ登録・終了監視・正常/異常時処理定義など)
録画管理にそこまでは求めすぎなのか、エンコードする人が多いならあってしかるべきなのか BSディジタルがいつ停波されるか心配になってきた
2030年までもたんような ファイルサイズが0で保存されていると、kodi のプラグインから
読み込むのも支障が出るな。ぐぬぬ。 今更な話題で申し訳ないのですが、ffmpeg4.0.1のvaapi(vp9_vaapiで)>>565のパッチを当ててもhwaccel vaapiを使うと冒頭の1秒画像が崩れるのですが
(逆に言えば問題はそれくらいなのですが)、同様の症状の方います?
録画している番組は主にBS1とBSプレミアムなんですが、どれも冒頭の1秒だけ崩れます。 vp9_vaapi?? どのパッチの話をしてるんだろう。 >>839
>>565
のパッチです。今試してみたらh264_vaapiでは画面が崩れずエンコードできました。vp9_vaapiの問題かもしれません。
くだらないこと書いてすみません。 パッチを当てない素のffmpeg4.1でやってみましたら今度はvp9_vaapiでも最初の一秒は崩れませんでした。
やはりパッチとvp9_vaapiの関係のようです。(hwaccel vaapiを使わなくてもパッチを当てたffmpegだと画像が崩れる) mpeg12dec.cだけでなくisdb向けffmpegをまるごとコンパイルしてみたのですが、やはりh264_vaapiでは冒頭ノイズなしなのにvp9_vaapiだとノイズがでます。 snapshotnのmpeg12dec.cの>>565の修正箇所を自分で書き加えたら画面が崩れなくなりました。
ffmpegのバージョンが違うのに、パッチだと思ってファイルを上書きしていたのでどこかおかしくなったようです。
それでもなんとか動くのがすごいですが。
くだらない話で邪魔をしてすみませんでした。 >>813
遅くなりました。注文したりしばらく試行錯誤して見ていなかったもので、、、
UASP周りは確認しませんでしたが、とりあえずSATAに直接繋いで確認してみたところやはりHDDの不良でした。
今度は別の問題にぶつかっております。
不定期なのかもよくわからないのですが、録画すると27MB程度のファイルしか生成されないことがあります。
しかし、普通に録画できるときはできているのですが、駄目になると一気に失敗するファイルが増えます。たまにその状態でも正常に録画できたりもします。
HDDも買い替えテストしたところ正常ですし、録画ファイル自体も再生でき、冒頭の20秒前後が録画されています。
BS11やサンテレビ、TBSなどを録画しますが、どの放送局でもこの症状が出るときは出る。
複数録画しているときもあれば、一つしか録画していないときも発生します。
録画はrecpt1のstz版でスクランブル解除も含めて録画なのですが、ここも関係あったりしそうでしょうか。
ログはまた確認してみるつもりですが、再起動してもその後の番組で録画失敗したり、どの状況で失敗しているのかも検討がつかないのです。 もうちょい切り分けないといかんのでは
mirakurunのログ見るとか
うちはラズパイでなくDebianだが
録画先をNASにしてたときmirakurunでTSFilter?のバッファがたまに溢れて、録画→中止→録画を繰り返してコマ切れファイルになったことがある
原因はわからないが、録画先をローカルSSDに変えてからは発生してない
貴方と同じような局を録ってるが、たぶんTBSじゃなくてMBSだよね mirakurun.stderr.logに以下のような出力がある場合はバッファあふれによる停止。
上位のEPGStation等がリトライするが同様にあふれると、録画失敗を繰り返して細切れになる。
TSFilter is overflowing the buffer...
TSFilter will closing because reached time limit of overflowing the buffer...
バッファを拡張したり、使用率をmirakurunのログに出したり工夫してる人がいた。
http://nodoka.org/mirakurun-%E3%83%90%E3%83%83%E3%83%95%E3%82%A1-%E6%9E%AF%E6%B8%87-%E9%9A%9C%E5%AE%B3%E5%AF%BE%E7%AD%96/
http://nodoka.org/mirakurun-%E3%83%90%E3%83%83%E3%83%95%E3%82%A1-%E6%9E%AF%E6%B8%87%E9%9A%9C%E5%AE%B3-%E5%AF%BE%E7%AD%96%E7%B7%A8/ >>845
>>846
ありがとうございます。
mirakurunログにオーバーフローの形跡がありました。
重い作業をすると録画が終了したりしていたのでchinachuばかり疑っていました。
とりあえずバッファを増やして様子を見てみます。 録画はリアルタイム処理だから、入力〜出力のどこかが追いつかなければバッファに溜まる
バッファ増加は溢れるまでの時間を稼ぐ意味しかないから、一時的なことならバッファで耐えるだろうが、現状27MB録画程度で溢れるなら、同じ状況(重い作業?)になればやはり溢れるのでは
よほどバッファが大きくないと
発生条件を絞り込んで原因を取り除かないと忘れた頃に発生しそう
仮に重い作業とやらが原因ならそれを発生しないようにするとか でも様子見ってことだし、バッファ消費が瞬間的なことならバッファ増加で足りるケースもあるか
余計なことだったかも失礼 とりあえず数日間稼働させてますが、特に問題なくいけてます。シンプルにバッファ不足だったみたいです。
重い処理と言ってもラズパイにとって重い処理で、chinachuのシーンのカット?みたいなのを表示させるために、
ffmpegが動いてるだけで録画が止まったりしてました(毎回ではない)。
そもそも録画中にchinachuを開くことがあまりないので、取り敢えずは重い処理のことは気にせずこの状態で運用してみます >>844
なるほどHDD自体の不具合でしたか
そういったこともあるのですね
なにより原因がはっきりして良かったです
>>847
mirakurunがバッファのオーバーフローにより停止することへの対策ですが、
バッファサイズを増やすほかに、Linuxカーネルの vm.dirty_writeback_centisecs や vm.dirty_ratio 等のパラメータを調節して、
ページキャッシュが溜まり過ぎないようにしても多少効果があるのではないかと思います おっとっと
バッファサイズを増やして問題なさそうなんですね
なら良かったです Mirakurun+ChinachuってEDCBみたいに録画しながらリアルタイムでtvtestで視聴する機能ってある?
1つしかチューナーがないのでEDCBで出来るUDPかTCPで送信してTVTestで再生できるのをしたいんですが >>853
BonDriver_mirakurunで録画中の番組も含め、視聴できるようにできますよ。 なら最初からWindowsで組めやって話じゃないの?
あえてMirakurunやChinachuを挟む意味を感じないんだが >>855
Windowsでは一部チューナー(PLEX系)が糞品質なドライバのせいでまともに録画できないとかじゃね? mirakurunにepg文字化け修正来たけど、皆どうですか? Fedoraの吊るしのカーネル、earth-pt3モジュールが無いでやんの (′・ω・`) >>857
その一部Plexチューナーの問題はチューナー側USBコントローラに問題があるのが原因で
LinuxだろうがWindows だろうが誰のドライバだろうが起きる時は起きる。
速度に余裕のあるUSB IF用意してH/Wの競合がある時は原因を除くのが唯一の解決策だよ。
オレ等のLinuxドライバは優秀だからLinuxええでー てのはよくあるLinux好きの妄想だね >>861
Plexの場合非公式ドライバで直せる程度のバあで放置してるから訳が違う digibestスレ見てこいよ
プレ糞がいかに仕事していないか丸分かりだぞ 少なくともWindowsのドライバよりはよっぽど優秀だよ
ラズパイとW3U4だけどほとんどドロップもない そう思い込んでるだけだろ?
>>812あたり見ても作者も原因が判らない問題みたいだし プレクスが昔から糞なのは同意だけど
今のレベルでLinuxドライバーにすれば解決とは思わないな
どっちも安定する環境では全く問題ない、
安定しない環境ではとことんだめ、特に4トラポン並列以上は
ユーザーの目が多い分安定しない環境があれば遠慮なく叩くのがWin環境
安定した環境で使えたらとことん褒めるのがLinux環境
そこが違うだけだろ >>866
>>812はq3pe4で8ch録画してるからな。
4ch録画なら問題なさそうだと書いてあるだろ。 >>867
すくなくともPLEX純正ドライバのせいでBSODになるよりマシ。 q3pe4, q3u4はものが怪しいからな
しゃーない 一般的にハードル低目なのは確かだが
これは現実に安定優秀 ドイツ製のMaxM4をすこるのだ…
ddbridgeにisdbsのコードが追加されたから最新ドライバを入れるだけで全部動くようになったのだ…
数ヶ月後にはきっとlinuxカーネルの標準ドライバとして使えるようになるのだ…
売れるようになれば製品ラインナップも増えるのだ… >>872
高い (299 EUR) ので買いたくないのだ…
Full Hight とか欲しくないのだ…
PT3 を持ってるのだ…
私には合いませんが、良いチューナーのようですね。 >>873
mirakurun経由で録画と視聴に使ってるけど問題なし
受信感度は体感だけど PT3 > MaxM4 >>>>>>>> W3PE4 くらいの違い
W3PE4でドロップ恐怖症になったからちょくちょく手動でドロップの確認するけど今まで一回もなかった
スカパー関係なければPT3と大差ない割に4倍近く高いけど、PT3の新規生産がない現状だと
金をかけてでもPT3を代替えできるクオリティが新品で欲しい人の選択肢になると思うんだよね
あと4チューナが地上波と衛星のどっちでも使えるから「地上波3チャンネル同時にカバーしたい」みたいな時に1枚で済んで便利だった >>876
サンクス
クオリティゴミならプレ糞でいいよなーって思っていたから、
安定するよりみたいで何より ま、W3PE4はv2.0が1.2万円弱で手に入るし、
とりあえずリアルタイムに見れればいい人にはちょうどいい選択なんじゃね?
録画してTSをいつまでもコレクションし続けたい人にはちょっと色々と難ありだと思うけど ラズパイでffmpegエンコテストしてたんだけど
mpeg2HWデコード+h264HWエンコ
より
mpeg2SWデコード+h264HWエンコ
の方が速いんだけどこういうもんなんですかね?
前者は32fpsでて後者は40fps出ました
ちなみtopコマンドでCPUの負荷は前者が175%で後者が50%ぐらいだったので
CPUの負荷はかなり抑えられてるけど全体のスピードは8fpsも落ちちゃってます
ちゃんとHWデコードできてるんですかね? でも、重要なのはエンコ速度よりも、エンコ後のソース映像の再現具合じゃないの?
HWエンコは特に、早く終わったからと言って画質がいいとは限らないし HWデコードはリアルタイム再生に必要なfpsしか出ない。
SWデコードはCPU次第で無限に速くできる。 デコードとエンコで同じハードウェアを共有してんじゃないの?
コンテキストの切り替えが多発&エンコとデコードが多重化できない からじゃないのか >>881
入れた
1は全部SW
2はh264だけHW
3はh264とmpeg2がHW
1. ffmpeg -fflags +discardcorrupt -i sample.ts -t 00:00:30 -c:a copy -bsf:a aac_adtstoasc -c:v libx264 -b:v 5000k -y encoded/test1.mp4
2. ffmpeg -fflags +discardcorrupt -i sample.ts -t 00:00:30 -c:a copy -bsf:a aac_adtstoasc -c:v h264_omx -b:v 5000k -y encoded/test2.mp4
3. ffmpeg -fflags +discardcorrupt -c:v mpeg2_mmal -i sample.ts -t 00:00:30 -c:a copy -bsf:a aac_adtstoasc -c:v h264_omx -b:v 5000k -y encoded/test3.mp4
fps エンコ時間 CPU負荷
1. 2.7fps 5:32
2. 40fps 0:24 175%
3. 32fps 0:29 50% VAAPIに詳しい方にちょっとお聞きしたいのですが、skylakeのhybrid-codec&VLCのVAAPI decodeで、VP9の動画を視聴した時
瞬間的にビットレートが40mbpsを超えると画像が破綻するのですが(VAAPIオフではCPU負荷が高いものの再生できます)、
skylakeのintel hybrid codecってcore シリーズ初期のh.264デコードのように40mbpsまでのビットレートに制限されているなどの制限が
あるのでしょうか?検索してみても言及しているページが見つからなかったので質問させていただきます。 >>888
スレ違いですか。テレビスレらしいので良いと思ったのですが。
どうも皆さん失礼いたしました。 ■ このスレッドは過去ログ倉庫に格納されています