Recherche avancée

Sur d’autres sites (7815)

• How to handle differing .mp4 file types from different sources ?

  10 octobre 2017, par Dave502619

  If I take a .mp4 recorded on my mobile (Samsung S5) and pass it through FFmpeg with the below command, the output file (fileX.avi) is a greyscale bitmap uncompressed video file.

  • The offset values in fileX.avi (output from FFmpeg) to allow me to locate the video frame data are always 5680 bytes for the file header.

  • And 62 bytes for the inter frame header.

  • The data is uncompressed RGB24 so i can easily calculate the size of a video frame from height x width x 3.

  So my C# application can access the video frames in fileX.avi always at these above offsets.
  (This works great).

  My FFmpeg Command is :

  ffmpeg.exe -i source.mp4 -b 1150 -r 20.97 -g 120 -an -vf format=gray -f rawvideo -pixfmt gray -s 384x216 -vcodec rawvideo -y fileX.avi

  However... I recently took an .mp4 file from a different source (produced by Power Director 14 instead of direct from my mobile phone) and used this as the input source.mp4. But now the structure of fileX.avi differs as the offset values of 5680 + 62 bytes from the start in fileX.avi do not land me at the start of the video data frames.

  There seems to be different file formats for .mp4 - and obviously if there are my crude offset approach will not work for them all. I suspected at the time I wrote the code my method was all too easy a solution !

  So can anyone advise on the approach I should take now ? Should I check the original .mp4 or the output file (fileX.avi) to determine a "file type" to which I can determine the different offsets ?

  At the very least I need to be able to identify the "type" of .mp4 file that works so I can declare the type that will work with my software.

• Play MPEG-CENC encrypted local file on android

  26 mai 2018, par rd7773

  I need to decrypt and play a cenc-aes-ctr mp4 video on the fly which is locally stored on the device.
  The video was encrypted at server end by using following ffmpeg command and then downloaded to phone :

  ffmpeg -i SampleVideo_1280x720_1mb.mp4 -vcodec copy -acodec copy -encryption_scheme cenc-aes-ctr -encryption_key 76a6c65c5ea762046bd749a2e632ccbb -encryption_kid a7e61c373e219033c21091fa607bf3b8 SampleVideo_1280x720_1mb_encrypted.mp4

  It is successfully getting played with ffmpeg command :

  ffplay SampleVideo_1280x720_1mb_encrypted.mp4 -decryption_key 76a6c65c5ea762046bd749a2e632ccbb

  But I do not want to use ffmpeg in android so I am using libeasy library which creates a local http server to make a stream of offline video and then decrypt it on the fly using Cipher. The Cipher which is provided to the LocalHttpServer for decryption process, needs the initialisation vector (iv) for CTR mode which is not externally available to us.
  From above command it is clear that ffmpeg doesn’t require the IV for encryption or decryption to be passed but i guess internally it uses 8 byte random iv.

  This is how i am creating Cipher to pass to LocalHttpServer :

  final Cipher c = Cipher.getInstance("AES/CTR/NoPadding","BC);
  
  c.init(Cipher.DECRYPT_MODE, new SecretKeySpec(hexStringToBytes("76a6c65c5ea762046bd749a2e632ccbb"), "AES"), new IvParameterSpec(new byte[16]));

  So my question is, what value of iv should i pass in this case to Cipher ? My basic requirement is to play a offline MPEG-CENC encrypted mp4 video stored on device.
  Keeping in mind my very limited knowledge of cryptography, references to any library that provides such implementation with or without any tweaks is welcomed.

• FFmpeg - MJPEG decoding gives inconsistent values

  28 décembre 2016, par ahmadh

  I have a set of JPEG frames which I am muxing into an avi, which gives me a mjpeg video. This is the command I run on the console :

  ffmpeg -y -start_number 0 -i %06d.JPEG -codec copy vid.avi

  When I try to demux the video using ffmpeg C api, I get frames which are slightly different in values. Demuxing code looks something like this :

  AVFormatContext* fmt_ctx = NULL;
  
  AVCodecContext* cdc_ctx = NULL;
  
  AVCodec* vid_cdc = NULL;
  
  int ret;
  
  unsigned int height, width;
  
  
  
  ....
  
  // read_nframes is the number of frames to read
  
  output_arr = new unsigned char [height * width * 3 * 
  
                                  sizeof(unsigned char) * read_nframes];
  
  
  
  avcodec_open2(cdc_ctx, vid_cdc, NULL);
  
  
  
  int num_bytes;
  
  uint8_t* buffer = NULL;
  
  const AVPixelFormat out_format = AV_PIX_FMT_RGB24;
  
  
  
  num_bytes = av_image_get_buffer_size(out_format, width, height, 1);
  
  buffer = (uint8_t*)av_malloc(num_bytes * sizeof(uint8_t));
  
  
  
  AVFrame* vid_frame = NULL;
  
  vid_frame = av_frame_alloc();
  
  AVFrame* conv_frame = NULL;
  
  conv_frame = av_frame_alloc();
  
  
  
  av_image_fill_arrays(conv_frame->data, conv_frame->linesize, buffer, 
  
                       out_format, width, height, 1);
  
  
  
  struct SwsContext *sws_ctx = NULL;
  
  sws_ctx = sws_getContext(width, height, cdc_ctx->pix_fmt,
  
                           width, height, out_format,
  
                           SWS_BILINEAR, NULL,NULL,NULL);
  
  
  
  int frame_num = 0;
  
  AVPacket vid_pckt;
  
  while (av_read_frame(fmt_ctx, &vid_pckt) >=0) {
  
      ret = avcodec_send_packet(cdc_ctx, &vid_pckt);
  
      if (ret < 0)
  
          break;
  
  
  
      ret = avcodec_receive_frame(cdc_ctx, vid_frame);
  
      if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
  
          break;
  
      if (ret >= 0) {
  
          // convert image from native format to planar GBR
  
          sws_scale(sws_ctx, vid_frame->data, 
  
                    vid_frame->linesize, 0, vid_frame->height, 
  
                    conv_frame->data, conv_frame->linesize);
  
  
  
          unsigned char* r_ptr = output_arr + 
  
              (height * width * sizeof(unsigned char) * 3 * frame_num);
  
          unsigned char* g_ptr = r_ptr + (height * width * sizeof(unsigned char));
  
          unsigned char* b_ptr = g_ptr + (height * width * sizeof(unsigned char));
  
          unsigned int pxl_i = 0;
  
  
  
          for (unsigned int r = 0; r < height; ++r) {
  
              uint8_t* avframe_r = conv_frame->data[0] + r*conv_frame->linesize[0];
  
              for (unsigned int c = 0; c < width; ++c) {
  
                  r_ptr[pxl_i] = avframe_r[0];
  
                  g_ptr[pxl_i]   = avframe_r[1];
  
                  b_ptr[pxl_i]   = avframe_r[2];
  
                  avframe_r += 3;
  
                  ++pxl_i;
  
              }
  
          }
  
  
  
          ++frame_num;
  
  
  
          if (frame_num >= read_nframes)
  
              break;
  
      }
  
  }
  
  
  
  ...

  In my experience around two-thirds of the pixel values are different, each by +-1 (in a range of [0,255]). I am wondering is it due to some decoding scheme FFmpeg uses for reading JPEG frames ? I tried encoding and decoding png frames, and it works perfectly fine. I am sure this is something to do with the libav decoding process because the MD5 values are consistent between the images and the video :

  ffmpeg -i %06d.JPEG -f framemd5 -
  
  ffmpeg -i vid.avi -f framemd5 -

  In short my goal is to get the same pixel by pixel values for each JPEG frame as I would I have gotten if I was reading the JPEG images directly. Here is the stand-alone bitbucket code I used. It includes cmake files to build code, and a couple of jpeg frames with the converted avi file to test this problem. (give ’—filetype png’ to test the png decoding).