Isang stream na 24/7 na hindi nagre-reconnect sa pagitan ng mga video: isang ffmpeg na pinakain sa pamamagitan ng pipe
Video
Ang live channel na nagpapakita ng mga tapos na video sa buong araw ay may dalawang madaling disenyo, at pareho silang may kulang. Ang pag-restart ng ffmpeg para sa bawat video ay nagpapalaglag ng RTMP connection sa bawat paglipat. Ang concat playlist ay binabasa nang isang beses sa simula, kaya ang bagong video ay naghihintay sa susunod na restart.
Ang disenyo
Ang bawat video ay isang beses na na-convert sa MPEG-TS sa laki at frame rate ng stream; ang vertical video ay nakalagay sa isang blurred copy nito sa halip na black bars. Isang ffmpeg process ang nagbabasa ng MPEG-TS mula sa kanyang standard input at nag-e-encode sa constant bitrate na may keyframe tuwing dalawang segundo, gaya ng inaasahan ng live ingest. Isang maliit na feeder ang sumusulat ng mga inihandang file sa pipe na iyon nang isa-isa, sa real-time pace, at pinipili ang susunod na file sa bawat paglipat: ang mga video na hindi pa napapanood ang una, pagkatapos ang pinakamabagal na napapanood. Ang MPEG-TS reader ng ffmpeg ay nakakita na ang timestamps ng bawat file ay nagsisimula ulit at inililipat ang mga ito, kaya ang output nito ay tumatakbo nang walang putol.
Detalye isa: ang pace mula sa unang byte
Ang aming unang bersyon ay nagsimula ng orasan nang simulan ang ffmpeg. Ang paghahanda ng unang file ay tumagal ng siyam na segundo, kaya akala ng feeder ay siyam na segundo na itong late at ipinadala niya ang lahat nang sabay-sabay. Ang pag-simula ng orasan sa unang byte na isinulat ang nag-ayos nito: ang 53-segundong run ay nag-produce ng 53 segundo ng stream.
Detalye dalawa: ang audio sa seam
Sa isang paglipat, ang audio ng susunod na file ay nagsimula 17 milliseconds bago matapos ang audio ng naunang file. Nagbabala ang encoder na ang input nito ay "backward in time" at inayos ng muxer ang timestamp. Ang pag-resample gamit ang aresample=async=1:min_hard_comp=0.01:first_pts=0 ay nagt-trim o nagp-pad ng mga ganitong overlap bago ito makita ng encoder. Sa run na medyo higit sa isang minuto na may limang paglipat, ang lahat ng audio at video timestamp sa natanggap na stream ay tumaas, at ang stream ay na-decode nang walang kahit isang error.
Detalye tatlo: ang ilang babala ay normal
Ang bawat file ay nagre-restart ng kanyang MPEG-TS counters at orasan, kaya iniuulat ng ffmpeg ang "Packet corrupt" at "timestamp discontinuity" sa bawat paglipat. Ang mga linyang iyon ay inaasahan, at pinapanatili namin silang hindi nakasulat sa log upang ang mga tunay na error ay lumabas.
Ang watchdog
Kung matigil ang ffmpeg o ang pag-unlad nito sa loob ng isang minuto, muling sisimulan ang stream na may lumalaking paghinto at magpapadala ng mensahe pagkatapos ng paulit-ulit na pagkabigo. Sa aming pagsubok, pinatay namin ang encoder nang manu-mano; bumalik ang stream pagkatapos ng pitong segundo, at ang isang video na idinagdag habang tumatakbo ang proseso ay sumali sa rotation nang walang muling koneksyon. Ang pag-restart ay isang maikling muling koneksyon, kaya itakda ang YouTube broadcast na awtomatikong magsimula at huwag awtomatikong huminto. Ang stream key ay naka-mask sa bawat linya ng log, kasama na ang sariling log ng ffmpeg. Ipinapadala ng Studio ang live channel na ito bilang systemd service.