Recherche avancée

Sur d’autres sites (9339)

• dnn/vf_dnn_detect.c : add tensorflow output parse support

  6 mai 2021, par Ting Fu

  dnn/vf_dnn_detect.c : add tensorflow output parse support
  Testing model is tensorflow offical model in github repo, please refer
  
  https://github.com/tensorflow/models/blob/master/research/object_detection/g3doc/tf2_detection_zoo.md
  
  to download the detect model as you need.
  
  For example, local testing was carried on with 'ssd_mobilenet_v2_coco_2018_03_29.tar.gz', and
  
  used one image of dog in
  
  https://github.com/tensorflow/models/blob/master/research/object_detection/test_images/image1.jpg
  Testing command is :
  
  ./ffmpeg -i image1.jpg -vf dnn_detect=dnn_backend=tensorflow:input=image_tensor:output=\
  
  "num_detections&detection_scores&detection_classes&detection_boxes":model=ssd_mobilenet_v2_coco.pb,\
  
  showinfo -f null -
  We will see the result similar as below :
  
  [Parsed_showinfo_1 @ 0x33e65f0]   side data - detection bounding boxes :
  
  [Parsed_showinfo_1 @ 0x33e65f0] source : ssd_mobilenet_v2_coco.pb
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 0,       region : (382, 60) -> (1005, 593), label : 18, confidence : 9834/10000.
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 1,       region : (12, 8) -> (328, 549), label : 18, confidence : 8555/10000.
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 2,       region : (293, 7) -> (682, 458), label : 1, confidence : 8033/10000.
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 3,       region : (342, 0) -> (690, 325), label : 1, confidence : 5878/10000.
  There are two boxes of dog with cores 94.05% & 93.45% and two boxes of person with scores 80.33% & 58.78%.
  Signed-off-by : Ting Fu <ting.fu@intel.com>
  
  Signed-off-by : Guo, Yejun <yejun.guo@intel.com>
  

  • [DH] libavfilter/vf_dnn_detect.c

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

• FFMPEG HTTP protocol closing after first packet

  27 août 2019, par rusty

  I’m trying to send a live video stream from my webcam to FFMPEG via the HTTP protocol. However after the first packet is sent FFMPEG closes, but does indeed output a fully playable video. As my intention.

  After going over the documentation for the protocol I thought mulitiple_requests would stop this behavior which it did not. After searching online for a few hours I can not find an example specific to my scenario. i.e. receiving a network stream over HTTP.

  Code running on the client-side :

  var xhttp=new XMLHttpRequest;
  
  
  
  if (navigator.mediaDevices) {
  
  
  
      var constraints = { audio: true, video: true };
  
  
  
      navigator.mediaDevices.getUserMedia(constraints)
  
        .then(function(stream) {
  
          var mediaRecorder = new MediaRecorder(stream);
  
          m = mediaRecorder;
  
          m.start();
  
          m.ondataavailable=e=>{
  
            xhttp.open("POST","http://localhost:8080");
  
            xhttp.send(e.data);
  
          }
  
          setInterval(function(){
  
            m.requestData();
  
          },2000);
  
        }).catch(function(error) {
  
          console.log(error.message);
  
        });
  
  }

  The FFMPEG command I have tried thus far :

  ffmpeg -listen 1 -multiple_requests -i http://localhost:8080 file.webm

  Maybe this is not possible with FFMPEG ? If this is the case then it appears the only solution would be to put this command in a loop and keep appending to the output.