Recherche avancée

Sur d’autres sites (13373)

• FFmpeg - MJPEG decoding - getting different values

  27 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.

  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 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).

• FFMPEG or GStreamer - HLS to UDP [closed]

  24 août 2023, par Alex Romero

  I can't manage to input HLS and output UDP on these two softwares correctly.

  


  I'm trying to understand how to use these two softwares. I got better results using FFMPEG but somehow, I didn't manage adding a hls playlist that started with "https". It works with "http". What I found facsinating about this was that FFMPEG can even output UDP through the Ethernet port, by indicating the destination IP, which would be another computer/server. I'm not sure if GStreamer has this capability, since I'm starting to understand how it works.

  


  I know HLS means HTTP Live Streaming and UDP stands for User Datagram Protocol.

  


  Here are 2 of the examples I used for each software :

  


  FFMPEG

  


  ffmpeg -i https://hls_source -c:v libx264 -crf 23 -preset fast -c:a aac -s 1280x720 -f mpegts -bufsize 4000k -max_delay 1000000 -fflags nobuffer udp ://destination_ip:port ?pkt_size=1316

  


  GStreamer(runs but not work)

  


  gst-launch-1.0 souphttpsrc location=http://hls_source ! hlsdemux ! udpsink host=ip port=1234

  


  I want to know if there's any way I can fix the FFMPEG playlist issue. If there isn't any solution, how can I fix the issue I'm having on GStreamer. All the testing was done through VLC Media Player. Any suggestions or recommendations are gratefully accepted. If I have to try another software that is focused on this, please let me know.

  


• Multiple nVidia GPU transcoding (NOT computing) bottleneck

  11 décembre 2018, par Daniel Cantarin

  I’m doing some nVidia multi-GPU testing. However, this tests are not on the computing field but transcoding, using nvenc/nvdec.

  I have a setup with 3 Quadro GPUs (max 4 on this motherboard), and running some transcoding jobs using ffmpeg.

  Thing is, up to 8 jobs everything is fine, with tolerable GPU and CPU stats.
  But when reaching the 9th job, the nVidia cards metrics start to fall down. Whats troublesome is this : it doesn’t matter the job distribution. That is, if I send 8 jobs to GPU0, and 1 job to GPU1, is the same as 4-5, or 4-4-1, or 0-4-5, etc.

  What I see beggining on the 9th job is :

  1. CPU gets to about 60% usage (30% up to 8th jobs) and doesn’t go up much after adding more jobs.
  2. DECODING metrics falls from about 75% (when single card has 8 jobs) to about 20%.
  3. Every card behaves the same when this problem starts, no matter how many jobs they have.

  And the last strange thing I see : when that problem happens, and I kill all the jobs, the cards keep working for a while (sometimes even minutes).

  All this points to some bottleneck somewhere on the motherboard. Maybe the PCIe bus, maybe some CPU subsystem, I’m not sure. It also points to some buffering happening somewhere. I’m using the usual popular tools to see high-level metrics and curves (top/htop, nvidia-smi, nvtop, etc).

  My question : does anybody knows some common bottlenecks regarding multi-GPU setups that could lead to a problem like this ?

  Any tip would be nice.

  Thanks in advance.