Recherche avancée

Sur d’autres sites (7748)

• How can I quantitatively measure gstreamer H264 latency between source and display ?

  16 décembre 2014, par KevinM

  I have a project where we are using gstreamer , x264, etc, to multicast a video stream over a local network to multiple receivers (dedicated computers attached to monitors). We’re using gstreamer on both the video source (camera) systems and the display monitors.

  We’re using RTP, payload 96, and libx264 to encode the video stream (no audio).

  But now I need to quantify the latency between (as close as possible to) frame acquisition and display.

  Does anyone have suggestions that use the existing software ?

  Ideally I’d like to be able to run the testing software for a few hours to generate enough statistics to quantify the system. Meaning that I can’t do one-off tests like point the source camera at the receiving display monitor displaying a high resolution and manually calculate the difference...

  I do realise that using a pure software-only solution, I will not be able to quantify the video acquisition delay (i.e. CCD to framebuffer).

  I can arrange that the system clocks on the source and display systems are synchronised to a high accuracy (using PTP), so I will be able to trust the system clocks (else I will use some software to track the difference between the system clocks and remove this from the test results).

  In case it helps, the project applications are written in C++, so I can use C event callbacks, if they’re available, to consider embedding system time in a custom header (e.g. frame xyz, encoded at time TTT - and use the same information on the receiver to calculate a difference).

• How can I schedule a YouTube livestream entirely from Linux ?

  25 avril 2021, par Dale Wellman

  I have a setup on a Raspberry Pi (with its native camera) that uses a cronjob to start an ffmpeg session with its output streaming to YouTube. I re-use the same stream key each time, which is written into my ffmpeg scripts. This all works perfectly each week, automatically starting and stopping at the desired time.
However, each week PRIOR to that livestream, I have to "manually" go into YouTube Studio and "schedule" a new future event. This is easy enough, since it lets me "reuse" previous settings — all I have to change is the Title, date, and time. But I would love to figure out a way to automate that part of the process, as well. I assume it involves using the YouTube Data API, but I'm not well versed in API's, JSON, etc.
(I do have a strong Linux background, bash scripting skills, and general programming background.)

  


  My final solution just needs to :

  


  

  • create the new scheduled event (maybe 12 hours prior to going live), with Title, Date, Time, "Unlisted" status, category, and so forth — all the usual settings I do manually within Studio

  


  • retrieve the assigned URL for the upcoming stream (my script will then email that to me)

  


  


  So, basically, I'm asking for help getting started with the API, or whatever method is capable of doing this. I would prefer to code it on the same Pi that does the ffmpeg encoding (although in a pinch, I could create the schedule from another computer, even Windows). Any examples would be great.

  


  So far, all I have done is create my Google project, enable the YouTube Data API in the project, and create my API key. But I'm not sure where to go from there.

  


• Why FFmpeg is consuming more and more bandwith when restreaming a YouTube HLS stream ?

  3 janvier 2023, par NiHuShu

  I've been creating a bot in Python which allows to copy one YouTube livestream and stream it to another channel using the HLS protocol.

  


  This is the command I'm using in Python to start the FFmpeg process :

  


  m3u8_url = streamlink.streams(stream_url)['1080p'].url
ffmpeg_process = Popen(
    ["ffmpeg", "-i", m3u8_url, "-c", "copy","-ignore_io_errors", "1", "-f", "hls", "-http_persistent", "1", '-attempt_recovery', '1',
    '-method', 'POST', '-hls_time', '1', '-hls_playlist_type', 'event', '-g', '5', '-reconnect_at_eof', '1',
    'https://a.upload.youtube.com/http_upload_hls?cid=' + stream_key + '&copy=0&file=stream.m3u8'])


  


  I'm using streamlink to extract the 1080p m3u8 playlist of a given livestream and then using "-c", "copy"I'm just passing the raw HLS stream back to YouTube servers.

  


  The problem is that at first FFmpeg is using around 1.5 Mbps for both upload and download, but as the stream progresses the used bandwidth per second grows substantially. After 5 hours FFmpeg uses 5 Mbps of upload and about half of that in download, but it just keeps on growing. It's gotten to a point where my VPS was blocked as after a few days it was using > 1500 Mbps of bandwidth (with 10 active streams).

  


  The only thing that comes to my mind is that for some reason with every .ts segment, FFmpeg is trying to send all the previous ones as well. It might be worth mentioning that YouTube Studio is complaining that the incoming stream bandwith is too low and it should be 4.5 Mbps.

  


  I've tried changing the "-method" from PUT to POST, which helped reducing the download bandwidth, but didn't change anything in regards to upload.