Recherche avancée

Sur d’autres sites (10217)

• Can Linux buffer UDP packets to correct the sequence

  6 avril 2021, par QuickPrototype

  Good Day,

  


  I am transmitting MP3 audio using UDP through the Internet. Yes, it's most likely a bad idea for various reasons, however my use case limits me to this setup. To expand further based on comments below, my source device connects over a very high latency link with low and limited throughput as these devices are located in rural/remote areas. My latency is up to 1 seconds (shocking yes). Using TCP will therefore degrade my service due to its two way coms, acks, resends and the likes.

  


  The issue I'm trying to resolve is that on the receiver server (Linux Ubuntu 18.04), I am seeing all the packets but many times slightly out of sequence. I.e. packet 5 comes before packet 4.

  


  Is there a way in Linux to buffer the incoming UDP stream such that consumers (FFMPEG in my case) is able to get stream in order (being a buffer, with an expected delay, that would be linked to buffer size).

  


  Tcpdump example of issue (note : ids are out of sequence) :

  


  16:04:48.648448 IP (tos 0x0, ttl 24, id 25335, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:48.648503 IP (tos 0x0, ttl 24, id 25334, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:48.884324 IP (tos 0x0, ttl 24, id 25336, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:48.884357 IP (tos 0x0, ttl 24, id 25337, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.145213 IP (tos 0x0, ttl 24, id 25339, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.145257 IP (tos 0x0, ttl 24, id 25338, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.406068 IP (tos 0x0, ttl 24, id 25340, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.406125 IP (tos 0x0, ttl 24, id 25341, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.667095 IP (tos 0x0, ttl 24, id 25342, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.667175 IP (tos 0x0, ttl 24, id 25343, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.929139 IP (tos 0x0, ttl 24, id 25344, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.929200 IP (tos 0x0, ttl 24, id 25345, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:50.164307 IP (tos 0x0, ttl 24, id 25346, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:50.164385 IP (tos 0x0, ttl 24, id 25347, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:50.425221 IP (tos 0x0, ttl 24, id 25348, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:50.425285 IP (tos 0x0, ttl 24, id 25349, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80


  


• rtpdec : HEVC/H.265 support

  26 août 2014, par Thomas Volkert

  rtpdec : HEVC/H.265 support
  As specified in draft-ietf-payload-rtp-h265-06.
  Signed-off-by : Luca Barbato <lu_zero@gentoo.org>
  

  • [DBH] Changelog
  • [DBH] libavformat/Makefile
  • [DBH] libavformat/rtpdec.c
  • [DBH] libavformat/rtpdec_formats.h
  • [DBH] libavformat/rtpdec_hevc.c
  • [DBH] libavformat/version.h

• Dynamically record parts of a video stream using ffmpeg based on incoming events

  12 septembre 2023, par ganjim

  Say I have a RTSP stream running on some server.

  


  I want to record parts of this video stream based on some events that will come up on my machine.
My goal is to record 10 seconds before up to 10 seconds after the PTS in any received event. Consider that I have a way to synchronize the PTS between the sender and the receiver, but by the time I receive the events, its already streamed and is in the past.
So I either need to have the ffmpeg command running already, or to have buffered streaming video in my memory.

  


  I just added some code with comments as a way to simulate the situation, it is not complete as I still don't have a working solution. But I'm looking to understand if ffmpeg has capabilities for dealing with rtsp streams suitable for this situation.

  


  const { spawn } = require('child_process');

function processEvent(event){
  
  let startTime = event.pts - 10
  let endTime = event.pts + 10

  const ffmpegArgs = [
    '-i', "rtspUrl",
    '-ss', startTime.toString(),
    '-to', endTime.toString(),
    '-c', 'copy',
    '-f', 'mp4',
    `output_${startTime}_${endTime}.mp4` // Output filename
  ];
  // Here it is obviously not possible to give ffmpeg a negative startTime.
  // We either have to have spawned the ffmpeg command and somehow give it a starting time for recording on demand or have a buffering system in place.
  // Having a buffer to store every raw frame and then attach them after endTime is also considerably CPU and memory intensive.
  // Looking for alternative ways to achieve the same output.

  const ffmpegProcess = spawn('ffmpeg', ffmpegArgs, {
    stdio: 'inherit'
  });
}

// Code to simulate the events:
// imagine these pts to be relative to Date.now(), so using negative PTS to show the events are going to be in the past by the time we receive them.
setTimeout(() => {
  const event1= { pts: -30 };
  processEvent(event1);
}, 1000);

setTimeout(() => {
  const event2 = { pts: -20 };
  processEvent(event2);
}, 5000);