Recherche avancée

Sur d’autres sites (8383)

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

• Releasing GME Players and Tools

  22 mai 2012, par Multimedia Mike — General, alsa, github, gme, pulseaudio, Python, sdl

  I just can’t stop living in the past. To that end, I’ve been playing around with the Game Music Emu (GME) library again. This is a software library that plays an impressive variety of special music files extracted from old video games.

  I have just posted a series of GME tools and associated utilities up on Github.

  Clone the repo and try them out. The repo includes a small test corpus since one of the most tedious parts about playing these files tends to be tracking them down in the first place.

  Players
  At first, I started with trying to write some simple command line audio output programs based on GME. GME has to be the simplest software library that it has ever been my pleasure to code against. All it took was a quick read through the gme.h header file and it was immediately obvious how to write a simple program.

  First, I wrote a command line tool that output audio through PulseAudio on Linux. Then I made a second program that used ALSA. Guess what I learned through this exercise ? PulseAudio is actually far easier to program than ALSA.

  I also created an SDL player, seen in my last post regarding how to write an oscilloscope. I think I have the A/V sync correct now. It’s a little more fun to use than the command line tools. It also works on non-Linux platforms (tested at least on Mac OS X).

  Utilities
  I also wrote some utilities. I’m interested in exporting metadata from these rather opaque game music files in order to make them a bit more accessible. To that end, I wrote gme2json, a program that uses the GME library to fetch data from a game music file and then print it out in JSON format. This makes it trivial to extract the data from a large corpus of game music files and work with it in many higher level languages.

  Finally, I wrote a few utilities that repack certain ad-hoc community-supported game music archives into... well, an ad-hoc game music archive of my own device. Perhaps it’s a bit NIH syndrome, but I don’t think certain of these ad-hoc community formats were very well thought-out, or perhaps made sense a decade or more ago. I guess I’m trying to bring a bit of innovation to this archival process.

  Endgame
  I haven’t given up on that SaltyGME idea (playing these game music files directly in a Google Chrome web browser via Google Chrome). All of this ancillary work is leading up to that goal.

  Silly ? Perhaps. But I still think it would be really neat to be able to easily browse and play these songs, and make them accessible to a broader audience.

• Evolution #4346 (En cours) : Extraire la gestion des catégories de SPIP et SVP (action 1)

  11 juin 2019, par Eric Lupinacci

  Le passage sous Composer va à plus ou moins long terme remettre en cause SVP. SVP supporte aujourd’hui plusieurs fonctions distinctes dont :

  1. la "gestion" des catégories
  2. la "gestion" des branches SPIP
  3. la construction du référentiel des plugins et des dépôts.
  4. l’installation des plugins incluant la gestion des dépendances.

  La mise en place de Composer (objectif final avec les plugins) remet en cause complètement la fonction 4-.
  L’idée est donc :

  • action 1 : transférer la fonction 1 dans un plugin à part : c’est déjà fait en grande partie et le plugin s’appelle SVP Typologie.
  • action 2 : transférer la fonction 2 dans SPIP directement (ou ailleurs, à réfléchir). Cela correspond principalement à des globales et une balise.
  • action 3 : transférer la fonction 3 dans un plugin "Référentiel des plugins" qui construit la base des plugins à partir des archives XML. En complément, il serait bien de réfléchir à une autre manière d’intégrer dans le référentiel les plugins Github de façon corriger les liens erronés puis ensuite de rajouter les zips Composer.
  • action 4 : réduire SVP à la fonction 4 en nécessitant le plugin "Référentiel des plugins" pour un certain temps.

  Ce ticket est avant tout dédié à l’action 1.
  Outre le plugin SVP Typologie développé pour l’instant sur Github https://github.com/smellup/svp_typologie il faut aussi faire des modifications sur SVP et le Core.

  Pour le Core, il faut :

  • passer la catégorie en optionnelle, supprimer la liste des valeurs possibles afin de ne pas générer d’erreur. Une fois les nouvelles catégories adoptées, on pourra même supprimer la catégorie des fichiers XML.
  • vérifier que les références à la catégorie dans les fonctions de chargement des XML sont compatibles avec l’absence de catégorie (a priori c’est le cas dans info_plugin).

  Pour SVP, il faut :

  • supprimer les balises, filtres et globales associés aux catégories
  • certains autres filtres (comptage en particulier) ne sont utilisés que dans Plugins SPIP. Il convient de les déplacer dans le plugin idoine (Plugins SPIP ou Contrib à terme)
  • Supprimer le filtre catégorie dans le formulaire de recherche des plugins.