Userbase

Project: het maken van een videomatrix.
Input: 4x 10Mbps videostream (1920x1080).
Output: 1x 1920x1080 videostream

Verwerken:
Neem de inputs, verklein ze naar 960x540, en plaats er 4 op 1 HD scherm, en deze terug streamen.

Ik heb dit werkend gekregen, zowel met ffmpeg als met vlc (waarbij het met vlc iets beter werkt naar mijn mening).

OS die dit zal uitvoeren: een nog te bepalen linux distro, enkel CLI.

Nu is de vraag: welke hardware heb ik hier minimaal voor nodig.
De testomgeving die ik heb staan is alvast onvoldoende merk ik (CPU: Intel Core I5-6300).
CPU zit aan zijn max, en krijg continu artefacten in het beeld.

Is dit in feite vooral een CPU intensieve taak? Of moet ik eerder kijken naar een GPU (ook al zal het een CLI server zijn)?
Hoeveelheid RAM zal niet veel uitmaken, vermoed ik, dus een standaard 8GB van tegenwoordig zal wel volstaan.

Wil je een videoscherm matrix van die inkomende stream?

http://www.smartavi.com/assets/images/p ... wall/1.jpg

Of wil je een mozaiek scherm maken?



Mag het eventueel dedicated hardware zijn? Of is het gewoon om één dag een uitzending te doen en daarna terug voor iets anders te gebruiken?

Met ffmpeg moet je zeker eens kijken naar vaapi hardware decoding / encoding.

Volgens mij moet dit al lukken met een simpele Atom CPU van 100€.

Via vaapi of qsv kan je met gemak 4 gelijktijdige transcode jobs aan.

Block schreef:Wil je een videoscherm matrix van die inkomende stream?

http://www.smartavi.com/assets/images/p ... wall/1.jpg

Of wil je een mozaiek scherm maken?



Mag het eventueel dedicated hardware zijn? Of is het gewoon om één dag een uitzending te doen en daarna terug voor iets anders te gebruiken?

Mozaïek zal een betere benaming zijn inderdaad.

Bedoeling is om dit permanent te laten draaien (24/7, 4-5 jaar aan een stuk, en daarna kan het systeem eens rebooten), tot de opstelling het begeeft.

skindred schreef:Met ffmpeg moet je zeker eens kijken naar vaapi hardware decoding / encoding.

Volgens mij moet dit al lukken met een simpele Atom CPU van 100€.

Via vaapi of qsv kan je met gemak 4 gelijktijdige transcode jobs aan.

Even wat opgezocht, want ik dacht dat mijn testcomputer dit ondersteunde.
Blijkt dat dit enkel onder linux werkt (wat goed is, die specifieke testcomputer draaide windows op dat moment).

Dus zolang er een GPU in zit van intel, die VA-API ondersteunt, zou het vlotjes moeten gaan?
Even wat testen draaien dus.

blaatpraat schreef:Of moet ik eerder kijken naar een GPU?

Ja, absolute noodzaak als je geen geld wil verspillen aan nutteloze dure hardware van een bedrijf genaamd Intel.
Elke GPU heeft tegenwoordig H.264 hardware acceleration en Picture-in-Picture technologie waardoor dit project mogelijk wordt met een goedkope Android-mediaplayer, smartphone, of zelfs een 5 jaar oude raspberry pi.

Op een 5 jaar oude raspberry pi, gebruik je dan de hardware accelerated omxplayer of ffmpeg met h264_omx als codec. Wellicht moet je ook wat extra RAM op de Raspberry toewijzen aan de GPU.

meer uitleg op https://t3chadd1ct.wordpress.com/2013/04/19/omxplayer/

Voor het gemak zou ik gaan voor Ubuntu.
vaapi support kan je dan vrij snel testen met de tool vainfo
(apt-get update && apt-get install -y vainfo)




http://tipsonubuntu.com/2016/11/02/inst ... ntu-16-04/



Een andere optie is om via docker te werken.
Zo heb ik dit werkende op mijn Synology NAS.
Ofwel draai je de container in privileged mode, ofwel met de --device flag waarbij je /dev/dri/renderD128 passed.

Een livestream neemt net geen 20% van de GPU in beslag (volgens intel_gpu_top)


@raf1

Een RPi is zeer zeker ook een optie!
Maar zou die 4 streams tegelijk kunnen decoden, filters applyen en terug encoderen naar een nieuwe stream?

Ik heb nog wel een RPi2 en RPi3 liggen om dit mee te testen eigenlijk

OS zal ofwel Centos ofwel Debian worden.
Mijn voorkeur gaat uit naar de laatste, maar we zullen zien of ik de IT-server-afdeling op mijn werk daarin meekrijg.

Ik zal eens experimenteren met een RPI (1), daar heb ik er thuis eentje van liggen

Ik ben ooit op zoek gegaan naar het omgekeerde 1 stream om op te splitsen naar diverse schermen in een videowall opstelling. Welke zoekwoorden ik heb gebruikt weet ik niet meer maar kwam een project of 2 tegen die inderdaad het omgekeerde deden (open source)

Verstuurd vanaf mijn Innos_D6000 met Tapatalk

Ooit wel eens een smartavi product voor zoiets gelijkaardig gebruikt. Om een productieketen in een diepvriesomgeving in het oog te houden. De kostprijs weet ik niet, maar werkt denk ik nog altijd probleemloos.

http://smartavi.com/products/multiviewe ... v-16x.html

Ongeveer zoiets maar ging maar tot 4 kanalen.

skindred schreef:Maar zou die 4 streams tegelijk kunnen decoden, filters applyen en terug encoderen naar een nieuwe stream?

Vermoedelijk wel met 1080i-bronnen. Het is zeker een must om decoding, scaling en encoding door de GPU te laten afhandelen.
Decoding en scaling moet dan afgehandeld worden via MMAL, ecoding met OpenMAX.
Met een recente multicore RPi kan je eventueel nog iets door de CPU laten afhandelen als je multithreading software gebruikt.

Je zal alleszins ffmpeg of vlc zelf moeten compileren vanaf de source om MMAL, OpenMAX en multithreading te ondersteunen.

Als je onvoldoende framerate en resolutie haalt met de raspberry, dan bestaan er zeker ook iets duurdere ontwikkelbordjes met een GPU die 4k ondersteunt en waarmee het wel kan.

Het blijft natuurlijk een uitdaging om de juiste software instructies vanuit Linux rechtstreeks naar de GPU te sturen.

Misschien moet je dit eens bekijken...

Nog even dit topic schoppen.

Ondertussen al wat doorgetest, maar nog steeds geen stabiele oplossing gevonden.
Noch onder windows, noch onder linux krijg ik iets stabiel als output.

Een RPI heb ik nog niet geprobeerd, maar wel met een (hardwarematig) zwaardere computer.

Voorbeeld van een commando (ik heb verschillende variaties alvast geprobeerd): Ik heb de fifo_size vergroot en overrun_nonfatal aangezet omdat ik continu circular buffer overrrun kreeg, maar voor zover ik weet is dit enkel maar een pleister op de wonde, en niet de correcte manier.
Iemand een idee hoe ik dit wel kan oplossen?

De 4 input streams zijn 1080i, elk zo'n 10Mbps, doenbaar dus zou ik stellen.
De stream-bron en de computer zitten naast elkaar op een gigabit-switch.

De bedoeling is dus dat dit robuust werkt (als 1 van de 4 inputs een probleem zou vertonen, de kans is immens klein alvast, zou dit nog steeds moeten werken). De reden dat ik dit zeg, is omdat ffmpeg soms de neiging heeft om gewoon te stoppen, zonder enige aanleiding.

Ook krijg ik maar iets van een 15 fps (vanaf ik iets van filtering toepas), wat in feite te weinig is hiervoor (de bron is 50-60 fps).

Iemand een idee wat ik fout doe? Of zit ik echt wel aan de hardwarematige limieten?
CPU van de testmachine is een Intel I5 6300.
GPU is een Intel HD Graphics 520.

Als de framerate naar 15 daalt, dan lijkt me dat je op de CPU werkt aan 100% belasting. Dan ga je natuurlijk circular buffer overrrun krijgen omdat de CPU de input gewoon niet kan volgen. In principe mag de CPU niet noemenswaardig belast worden, bijvoorbeeld 30 á 40%, en moet al het grafische werk door de GPU gedaan worden.

Je zal dus moeten proberen om ffmpeg te optimaliseren voor jouw GPU, dit betekent misschien dat sommige filters niet werken. Je zal eens moeten opzoeken welke scaling filters werken op een Intel GPU.

Probeer bijvoorbeeld eens met -vcodec h264_qsv, dan gebruik je rechtstreeks de Intel HD Graphics 520
zie handleiding: https://software.intel.com/en-us/articl ... ith-ffmpeg