Recherche avancée

Sur d’autres sites (11863)

• Killing all child processes

  12 juin 2016, par ErraticFox

  I have written a onclick function that runs child process for a command line for ffmpeg. Though I can’t seem to force close or kill the process in the middle of it. I’ve tried multiple ways such as child.kill() along with SIGINT, SIGKILL, SIGHUP, SIGQUIT, and SIGTERM and it continuously runs in the background still until finished or killed in the task manager. So how can I kill all the process related to the exec ?

  Here’s my current code :

  function submitBtn() {
  
      var selectVal1 = $("#inputFile1 option:selected").val(),
  
          selectVal2 = $("#inputFile2 option:selected").val(),
  
          selectOpt2 = $("#inputFile2 option:selected").text().toLowerCase()
  
  
  
      if (!selectVal1 || !selectVal2) {
  
          Materialize.toast('Please select your formats', 4000)
  
      } else if ($("#uploadFile").val() === '') {
  
          Materialize.toast('Please select your file', 4000)
  
      } else {
  
          var process = require("child_process")
  
          var inputDir = uploadFile.files[0].path
  
          var dir = inputDir.split("\\")
  
          var pop = dir.pop()
  
          var outputDir = dir.join("\\")
  
          var cmd = `ffmpeg -y -i "${inputDir}" "${outputDir}\\output.${selectOpt2}"`
  
  
  
          $("#load").removeClass("disabledLoad")
  
          func = process.exec(cmd, function(error, stdout, stderr) {})
  
  
  
          func.on('exit', function() {
  
              $("document").ready(function() {
  
                  $("#load").addClass("disabledLoad")
  
                  Materialize.toast('Conversion compelete!', 4000)
  
              })
  
          })
  
  
  
      }
  
  }
  
  
  
  function exitBtn() {
  
      //var remote = require('electron').remote
  
      //var window = remote.getCurrentWindow()
  
      //window.close()
  
      func.kill()
  
  }

  I even tried renaming process to proc and then doing

      process.on('exit', function () {
  
      console.log('process is about to exit, kill ffmpeg');
  
      func.kill()
  
  })

  in exitBtn but still nothing. It doesn’t give errors or log my string I put.

• Are avcodec_send_packet and avcodec_receive_frame thread safe ?

  6 novembre 2022, par nckm

  I am trying to implement video decoding application with libav decoder.
Most libav examples are built like this (pseudocode) :

  


  while true {
    auto packet = receive_packet_from_network();
    avcodec_send_packet(packet);
    auto frame = alloc_empty_frame();
    int r = avcodec_receive_frame(&frame);
    if (r==0) {
        send_to_render(frame);
    }
}


  


  Above is pseudocode.
Anyway, with this traditional cycle, when I wait receive frame complete and then wait rendering complete and then wait next data received from network incoming decoder buffer becomes empty. No HW decoder pipeline, low decode performance.
Additional limitation in my application - I know exactly that one received packet from network directly corresponds to one decoded frame.

  


  Besides that, I would like to make solution faster. For that I want to split this cycle into 2 different threads like this :

  


  //thread one
while true {
    auto packet = receive_packet_from_network();
    avcodec_send_packet(packet);
}
//thread two
while true {
    auto frame = alloc_empty_frame();
    int r = avcodec_receive_frame(&frame);
    if (r==0) {
        send_to_render(frame);
    }


  


  Purpose to split cycle into 2 different threads is to keep incoming decoder buffer always feed enough, mostly full. Only in that case I guess HW decoder I expect to use will be happy to work constantly pipelined. Of cause, I need thread synchronization mechanisms, not shown here just for simplicity. Of cause when EGAIN is returned from avcodec_send_packet() or avcodec_receive_frame() I need to wait for other thread makes its job feeding incoming buffer or fetching ready frames. That is another story.

  


  Besides that, this threading solution does not work for me with random segmentation faults. Unfortunately I cannot find any libav documentation saying explicitly if such method is acceptable or not, are avcodec_send_packet() and avcodec_receive_frame() calls thread safe or not ?

  


  So, what is best way to load HW decoder pipeline ? For me it is obvious that traditional poll cycles shown in any libav examples are not effective.

  


• avformat/hls : add http_multiple option

  13 décembre 2017, par Aman Gupta

  avformat/hls : add http_multiple option
  This improves network throughput of the hls demuxer by avoiding
  
  the latency introduced by downloading segments one at a time.
  The problem is particularly noticable over high-latency network
  
  connections : for instance, if RTT is 250ms, there will a 250ms idle
  
  period between when one segment response is read and the next one
  
  starts.
  The obvious solution to this is to use HTTP pipelining, where a
  
  second request can be sent (on the persistent http/1.1 connection)
  
  before the first response is fully read. Unfortunately the way the
  
  http protocol is implemented in avformat makes implementing pipleining
  
  very complex.
  Instead, this commit simulates pipelining using two separate persistent
  
  http connections. This has the advantage of working independently of
  
  the http_persistent option, and can be used with http/1.0 servers as
  
  well. The pair of connections is swapped every time a new segment starts
  
  downloading, and a request for the next segment is sent on the secondary
  
  connection right away. This means the second response will be ready and
  
  waiting by the time the current response is fully read.
  Signed-off-by : Aman Gupta <aman@tmm1.net>
  
  Signed-off-by : Anssi Hannula <anssi.hannula@iki.fi>
  

  • [DH] doc/demuxers.texi
  • [DH] libavformat/hls.c