Recherche avancée

Sur d’autres sites (5311)

• Continously running a PHP script waiting for videos to trancode

  12 mai 2017, par Ian

  I’m making a transcoding server which uses FFMPEG to convert videos to flv. After user uploads a video it’s queued for processing in amazon Simple Queue Service. System is linux ubuntu.

  Instead of running CRON each 1min I wonder if it would be possible to continously run several PHP scripts (dowload queued files, process downloaded etc). Each of them would have its own queue which would be read every 10s or so looking for new tasks.

  My question is :

  How to detect if the script is already running ? I’d run CRON each 1min and if one of the programs would not be running I’d load it again. How stuff like that is done on linux ? PID files ?

  thanks for help,
  ian

• How to loop an MPEG TS stream

  17 février 2015, par Brainfloat

  I’m looking for a way to stream a TS file as an infinitely looping http stream. I’ve tried just concatenating the file but that results in playback corruption.

  I have basic code to read the TS packet headers, but I’m not sure how packets relate to the underlying video stream. Are frames aligned to packets (so potentially I can loop it by repeating the right packets) or would I have to fully demux/remux the original TS stream for it to work ?

  The service that will hosting the http stream will be running on one of those Amlogic S802 based Android STBs, is it possible to pipe this data through the Android version of ffmpeg through Java or would any solution have to be purely Java ?

• ffmpeg can't recognize an UDP stream

  30 décembre 2014, par yaapelsinko

  When executing

  ffmpeg -i udp://239.192.1.2:3456

  kind of command, ffmpeg seems not being able to read such stream. No metadata info, and no transcoding if appropriate commands given.

  My network layout is the following :

  Ubuntu Server (ffmpeg) <---> Windows Server (Wowza) <---> Multicast subnet

  Stream must come from Multicast subnet through Window Server. Windows is configured to route IGMP via RRAS service. When I launching ffmpeg on Ubuntu, I can monitor that appropriate reports are received by RRAS and UDP stream starts to flow from Windows-to-Multicast network interface. I wasn’t able to monitor Ubuntu-to-Windows network interface, though, because Ubuntu is actually a Hyper-V VM on that Windows Server. Something is preventing Wireshark from listening on virtual NICs. Windows Server also has third NIC to the Internet, but it doesn’t matter here. Stream itself is okay, it can be successfully played with VLC or transcoded by Wowza (all on Windows Server). It is encoded with MPEG2/MP3 codecs.

  If I restream the stream through Wowza (passing through or transcoding), then ffmpeg is able to ingest it from rstp ://windows-server-ip:1935/LiveApp/myStream.stream so that I see metadata report and can transcode it. But I want to get it directly from multicast.

  Is it ffmpeg can’t read directly from udp ? Or maybe I missed something in configuration ? How can I investigate it further and localize the problem ?

  Update : Well, when restreaming the stream via VLC right into Ubuntu server NIC, ffmpeg can grab it. There are another problems, though, but at least I see that ffmpeg receives something. So, IGMP routing is not working correctly.

  Here is what I’ve done when configuring it : Enabled RRAS service. Added IGMP protocol to IPv4 routing. Added pNIC and vNIC as interfaces. pNIC is in Proxy mode, vNIC is in Router mode.

  That way I can at least see : 1) new records in IGMP group table when someone is requesting IGMP membership, 2) UDP packets flooding pNIC multicast interface when request from vNIC is received. However, I can’t listen vNIC interface with Wireshark from guest or host by some reason so I don’t know if packets are actually reaching the player on VM. I assume they aren’t, because I can’t play it with VLC or ingest the stream by ffmpeg (but who knows, maybe it just can’t be played in Hyper-V ?).

  If both interfaces are in IGMP router mode, no UDP traffic can be detected.