Recherche avancée

Sur d’autres sites (14834)

• tcp : set socket buffer sizes before listen/connect/accept

  9 janvier 2017, par Joel Cunningham

  tcp : set socket buffer sizes before listen/connect/accept
  From e24d95c0e06a878d401ee34fd6742fcaddeeb95f Mon Sep 17 00:00:00 2001
  
  From : Joel Cunningham <joel.cunningham@me.com>
  
  Date : Mon, 9 Jan 2017 13:37:51 -0600
  
  Subject : [PATCH] tcp : set socket buffer sizes before listen/connect/accept
  Attempting to set SO_RCVBUF and SO_SNDBUF on TCP sockets after connection
  
  establishment is incorrect and some stacks ignore the set call on the socket at
  
  this point.  This has been observed on MacOS/iOS.  Windows 7 has some peculiar
  
  behavior where setting SO_RCVBUF after applies only if the buffer is increasing
  
  from the default while decreases are ignored.  This is possibly how the incorrect
  
  usage has gone unnoticed
  Unix Network Programming Vol. 1 : The Sockets Networking API (3rd edition, seciton 7.5) :
  "When setting the size of the TCP socket receive buffer, the ordering of the
  
  function calls is important.  This is because of TCP’s window scale option,
  
  which is exchanged with the peer on SYN segments when the connection is
  
  established. For a client, this means the SO_RCVBUF socket option must be
  
  set before calling connect.  For a server, this means the socket option must
  
  be set for the listening socket before calling listen.  Setting this option
  
  for the connected socket will have no effect whatsoever on the possible window
  
  scale option because accept does not return with the connected socket until
  
  TCP’s three-way handshake is complete.  This is why the option must be set on
  
  the listening socket. (The sizes of the socket buffers are always inherited from
  
  the listening socket by the newly created connected socket)"
  Signed-off-by : Joel Cunningham <joel.cunningham@me.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/tcp.c

• FFmpeg -> JSMpeg Websocket Closes Repeatedly

  13 mars 2018, par Kyle Martin

  I’m trying to create a fairly simple streaming server/site. Here’s the current flow :

  • OBS streams to an RTMP URL
  • Nginx accepts the RTMP stream and uses exec-push to have FFmpeg pick up the stream and transcode it
  • FFmpeg transcodes the stream and outputs it to a JSMpeg application, which displays the stream on a webpage.

  When I have my exec_push statement as follows, everything seems to work perfectly, except the browser says Possible garbage data. Skipping. on every frame it receives :

  exec_push /usr/bin/ffmpeg -re -i rtmp://127.0.0.1:1935/$app/$name -f mpeg1video  http://localhost:8080/supersecret;

  This behavior is understandable, because JSMpeg must receive MPEG-TS data, not MPEG1 data. It sees the MPEG1 frames and thinks they’re garbage.

  So through some online research, I found this :

  exec_push /usr/bin/ffmpeg -re -i rtmp://127.0.0.1:1935/$app/$name -c:v copy -c:a copy -f mpegts http://localhost:8080/supersecret;

  Supposedly, this is supposed to transcode my RTMP stream into an MPEG-TS format, which should be compatible with JSMpeg.

  However, with the second version of the command, my FFmpeg -> JSMpeg stream keeps connecting and disconnecting, connecting and disconnecting, and so on. This behavior is observed in terminal :

  Stream Connected: ::1:40208
  
  close
  
  Stream Connected: ::1:40212
  
  close
  
  Stream Connected: ::1:40216
  
  close
  
  Stream Connected: ::1:40220
  
  close
  
  Stream Connected: ::1:40224
  
  close
  
  ...

  What would cause this ? I am pretty certain the issue is in my exec_push command. OBS is perfectly content, which tells me that the stream is making it to the server, and if I do a push, I can do a test push to Ustream just fine, which tells me that Nginx is at least processing the stream with some reasonable degree of success.

  ---

  Disclaimer : I have no idea what I’m talking about. Everything I know about FFmpeg and JSMpeg/Node is from snippets of code that I found online.

• ffmpeg/ffprobe input as buffer stream, get an error always

  13 décembre 2023, par hhk

  


  Code to reproduce

  


  I attached the test.gif file on https://github.com/fluent-ffmpeg/node-fluent-ffmpeg/assets/122068264/e1f3aa31-5386-4dab-a409-9a224e0610fe

  


  
const ffprobeInstaller = require('@ffprobe-installer/ffprobe');
const ffmpeg = require('fluent-ffmpeg');
const { Readable } = require('stream');
const fs = require('fs');


(async () => {

    const buffer = fs.readFileSync('test.gif');
    let readableStream = new Readable();
    readableStream._read = () => { };
    readableStream.push(buffer);
    readableStream.push(null);

    // console.log(ffprobe.path, ffprobe.version);
    ffmpeg.setFfprobePath(ffprobeInstaller.path);
    let metadata = await get_video_meta_data(readableStream);

    async function get_video_meta_data(stream) {
        return new Promise((resolve, reject) => {
            new ffmpeg()
                .input(stream)
                .ffprobe((err, data) => {
                    // console.log(err);
                });
            resolve();
        });
    }
})();





  


  (note : if the problem only happens with some inputs, include a link to such an input file)

  


  Expected results

  


  data should include duration but empty.

  


  Observed results

  


  data is empty and err happens.
Here is error data :

  


  
  libavutil      58.  1.100 / 58.  1.100
  libavcodec     60.  2.100 / 60.  2.100
  libavformat    60.  2.100 / 60.  2.100
  libavdevice    60.  0.100 / 60.  0.100
  libavfilter     9.  1.100 /  9.  1.100
  libswscale      7.  0.100 /  7.  0.100
  libswresample   4.  9.100 /  4.  9.100
  libpostproc    57.  0.100 / 57.  0.100
pipe:0: Input/output error


  


  I only need the metadta for the input gif file. specifically, duration field.