Recherche avancée

Sur d’autres sites (4768)

• Ffmpeg gets aborted in an Electron sandboxed application

  6 décembre 2017, par YoannM

  I have an Electron app, published on the Mac AppStore, and sandboxed.

  I’m trying to add a new feature that will encode/decode videos on the fly so I can stream more video formats in an Electron context.

  I’m using fluent-ffmpeg and a static exec of ffmpeg.

  Everything works awesomely, I’ve uploaded the sandboxed app to Apple, and got rejected because ffmpeg is using by default a secure transport protocol which is using non-public API, this is what they’ve sent me with the rejection :

  Your app uses or references the following non-public API(s) :

  ’/System/Library/Frameworks/Security.framework/Versions/A/Security’

   : SecIdentityCreate

  Alright, after much investigation, it appears that I have to compile ffmpeg myself with a --disable-securetransport flag. Easy enough, I do it using the same config as the static build I’ve downloaded simply adding the new flag.

  I manage to install every dependencies needed, except libxavs, no big deal I guess and simply remove its flag from the configure command :

  ./configure \
  
  --cc=/usr/bin/clang \
  
  --prefix=/opt/ffmpeg \
  
  --extra-version=tessus \
  
  --enable-avisynth \
  
  --enable-fontconfig \
  
  --enable-gpl \
  
  --enable-libass \
  
  --enable-libbluray \
  
  --enable-libfreetype \
  
  --enable-libgsm \
  
  --enable-libmodplug \
  
  --enable-libmp3lame \
  
  --enable-libopencore-amrnb \
  
  --enable-libopencore-amrwb \
  
  --enable-libopus \
  
  --enable-libsnappy \
  
  --enable-libsoxr \
  
  --enable-libspeex \
  
  --enable-libtheora \
  
  --enable-libvidstab \
  
  --enable-libvo-amrwbenc \
  
  --enable-libvorbis \
  
  --enable-libvpx \
  
  --enable-libwavpack \
  
  --enable-libx264 \
  
  --enable-libx265 \
  
  --enable-libxvid \
  
  --enable-libzmq \
  
  --enable-libzvbi \
  
  --enable-version3 \
  
  --pkg-config-flags=--static \
  
  --disable-securetransport \
  
  --disable-ffplay

  With the new ffmpeg exec, everything still works as expected. But once I’m packaging, signing and sandboxing the app, ffmpeg stops working as soon as I try to launch it throwing this error :

  An error occurred ffmpeg was killed with signal SIGABRT Error: ffmpeg was killed with signal SIGABRT
  
      at ChildProcess.eval (webpack:///../node_modules/fluent-ffmpeg/lib/processor.js?:180:22)
  
      at emitTwo (events.js:125:13)
  
      at ChildProcess.emit (events.js:213:7)
  
      at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)

  I’ve tried to remove the --disable-securetransport flag, see if it could have messed with something, same result.

  I’ve tried to compile on a Linux machine, just to see if it could help, same thing.

  As soon as I’m using my custom compiled exec it doesn’t work in the sandbox, but when using the static one, everything is ok (after I xattr it, because it’s quarantined and blocked in sandbox).

  The only thing I’ve noticed that seems odd is that my custom compilation is only 20mo or so, when the static install I’ve downloaded is 43mo.

  I’m really stuck with this.

• vc-1 : Optimise parser (with special attention to ARM)

  23 avril 2014, par Ben Avison

  vc-1 : Optimise parser (with special attention to ARM)
  The previous implementation of the parser made four passes over each input
  
  buffer (reduced to two if the container format already guaranteed the input
  
  buffer corresponded to frames, such as with MKV). But these buffers are
  
  often 200K in size, certainly enough to flush the data out of L1 cache, and
  
  for many CPUs, all the way out to main memory. The passes were :
  1) locate frame boundaries (not needed for MKV etc)
  
  2) copy the data into a contiguous block (not needed for MKV etc)
  
  3) locate the start codes within each frame
  
  4) unescape the data between start codes
  After this, the unescaped data was parsed to extract certain header fields,
  
  but because the unescape operation was so large, this was usually also
  
  effectively operating on uncached memory. Most of the unescaped data was
  
  simply thrown away and never processed further. Only step 2 - because it
  
  used memcpy - was using prefetch, making things even worse.
  This patch reorganises these steps so that, aside from the copying, the
  
  operations are performed in parallel, maximising cache utilisation. No more
  
  than the worst-case number of bytes needed for header parsing is unescaped.
  
  Most of the data is, in practice, only read in order to search for a start
  
  code, for which optimised implementations already existed in the H264 codec
  
  (notably the ARM version uses prefetch, so we end up doing both remaining
  
  passes at maximum speed). For MKV files, we know when we’ve found the last
  
  start code of interest in a given frame, so we are able to avoid doing even
  
  that one remaining pass for most of the buffer.
  In some use-cases (such as the Raspberry Pi) video decode is handled by the
  
  GPU, but the entire elementary stream is still fed through the parser to
  
  pick out certain elements of the header which are necessary to manage the
  
  decode process. As you might expect, in these cases, the performance of the
  
  parser is significant.
  To measure parser performance, I used the same VC-1 elementary stream in
  
  either an MPEG-2 transport stream or a MKV file, and fed it through ffmpeg
  
  with -c:v copy -c:a copy -f null. These are the gperftools counts for
  
  those streams, both filtered to only include vc1_parse() and its callees,
  
  and unfiltered (to include the whole binary). Lower numbers are better :
                  Before          After
  
  File  Filtered  Mean   StdDev   Mean   StdDev  Confidence  Change
  
  M2TS  No        861.7  8.2      650.5  8.1     100.0%      +32.5%
  
  MKV   No        868.9  7.4      731.7  9.0     100.0%      +18.8%
  
  M2TS  Yes       250.0  11.2     27.2   3.4     100.0%      +817.9%
  
  MKV   Yes       149.0  12.8     1.7    0.8     100.0%      +8526.3%
  Yes, that last case shows vc1_parse() running 86 times faster ! The M2TS
  
  case does show a larger absolute improvement though, since it was worse
  
  to begin with.
  This patch has been tested with the FATE suite (albeit on x86 for speed).
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/vc1_parser.c

• muxing into MPEG-TS : wrong parameters for audio stream

  18 janvier 2017, par user1058600

  I am trying to mux video (H.264) and audio (PCM_S16LE, no compression) into an MPEG transport stream using ffmpeg. The video shows fine. The audio stream, however, does not play. The audio stream, shown by ffprobe is AAC, which is obviously not my intention. So I must be doing something wrong in adding the audio stream. Any idea how I can correct this ?

  This is my code for adding an audio stream :

  void add_audio_stream()
  
  {
  
  
  
      CodecID codec_id = CODEC_ID_PCM_S16LE;
  
  
  
      AVStream *p_ast = av_new_stream(fc, 1);
  
  
  
      if (!p_ast) {
  
          fprintf(stderr, "Could not alloc audio stream\n");
  
          exit(1);
  
      }
  
  
  
      ai = p_ast->index;
  
  
  
      AVCodecContext *pcc = p_ast->codec;
  
      avcodec_get_context_defaults2( pcc, AVMEDIA_TYPE_AUDIO );
  
  
  
      pcc->codec_type = AVMEDIA_TYPE_AUDIO;
  
      pcc->codec_id = codec_id;
  
      pcc->sample_fmt = AV_SAMPLE_FMT_S16;
  
      //pcc->bit_rate = 44100*16*2;
  
      pcc->bit_rate = 0;
  
      pcc->sample_rate = 44100;
  
      pcc->channels = 2;
  
      pcc->time_base = (AVRational){1, 44100};
  
  
  
  
  
      // some formats want stream headers to be separate
  
      if (fc->oformat->flags & AVFMT_GLOBALHEADER)
  
      {
  
          printf(" **** 1 ****\n");
  
          pcc->flags |= CODEC_FLAG_GLOBAL_HEADER;
  
      }
  
      else
  
          printf(" **** 2 ****\n");
  
  
  
  
  
      AVCodec *codec;
  
  
  
      /* find the audio encoder */
  
      codec = avcodec_find_encoder(pcc->codec_id);
  
      if (!codec) {
  
          fprintf(stderr, "codec not found\n");
  
          exit(1);
  
      }
  
  
  
  
  
      /* open it */
  
      if (avcodec_open(pcc, codec) < 0) 
  
      {
  
          fprintf(stderr, "could not open codec\n");
  
          exit(1);
  
      }
  
  }

  Here is the output of ffprobe :

  ffprobe version N-32405-g6337de9, Copyright (c) 2007-2011 the FFmpeg developers
  
    built on Sep  8 2011 11:20:12 with gcc 4.4.3
  
    configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfaac --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-x11grab --enable-libmp3lame
  
    libavutil    51. 16. 0 / 51. 16. 0
  
    libavcodec   53. 13. 0 / 53. 13. 0
  
    libavformat  53. 12. 0 / 53. 12. 0
  
    libavdevice  53.  3. 0 / 53.  3. 0
  
    libavfilter   2. 39. 0 /  2. 39. 0
  
    libswscale    2.  1. 0 /  2.  1. 0
  
    libpostproc  51.  2. 0 / 51.  2. 0
  
  [mpegts @ 0xa96daa0] Continuity Check Failed
  
  [mpegts @ 0xa96daa0] Continuity Check Failed
  
  [aac @ 0xa974da0] channel element 0.1 is not allocated
  
  [aac @ 0xa974da0] More than one AAC RDB per ADTS frame is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
  
  
  
  .
  
  .
  
  lot of gobbly-gook about missing AAC parameters . . . 
  
  .
  
  .
  
  
  
  [aac @ 0xa974da0] More than one AAC RDB per ADTS frame is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
  
  [aac @ 0xa974da0] Error decoding AAC frame header.
  
  [mpegts @ 0xa96daa0] max_analyze_duration 5000000 reached at 5429789
  
  [mpegts @ 0xa96daa0] Continuity Check Failed
  
  [mpegts @ 0xa96daa0] Continuity Check Failed
  
  
  
  Input #0, mpegts, from 'test_audio_video.mts':
  
    Duration: 00:00:40.35, start: 0.010000, bitrate: 1907 kb/s
  
    Program 1 
  
      Metadata:
  
        service_name    : Service01
  
        service_provider: FFmpeg
  
  Stream #0.0[0x100]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p, 640x480, 30 fps, 30 tbr, 90k tbn, 60 tbc
  
  
  
  Stream #0.1[0x101]: Audio: aac ([6][0][0][0] / 0x0006), 96000 Hz, 4.0, s16, 9 kb/s