Recherche avancée

Sur d’autres sites (5496)

• Piwik is now using Github issues as our Issue Tracker !

  9 juillet 2014, par Matthieu Aubry — Community, Development

  This is an announcement regarding the Issue Tracker used for the Piwik project. We are excited to announce that Piwik has migrated from Trac to now using Github issues for managing our issues !

  More than 5,400 tickets and 20,000+ comments from 1,000+ users were migrated to Github. Read on for more information.

  Where do I find Piwik Issue Tracker ?

  • Piwik main project issue tracker (piwik/piwik)
  • Piwik Mobile issues (piwik/mobile2)
  • Device Detector issues (piwik/device-detector)
  • Piwik iOS SDK (piwik/piwik-sdk-ios)
  • See other repositories at github.com/piwik

  Benefits of using Github Issues for the Piwik project

  There are several advantages of moving to Github issues :

  • Faster and responsive user interface
  • Better cross-project referencing of issues
  • Ability to notify people with the @username functionality
  • No spam
  • Integration with Pull requests and our Git repository

  How do I get notifications for all Piwik tickets ?

  To receive notifications for new tickets or new comments in the Piwik project, go to github.com/piwik/piwik, then click the Watch button at the top of the page.

  

  In Github, watching a repository lets you follow new commits, pull requests, and issues that are created.

  How do I report a bug in Piwik ?
  See Submitting a bug report.

  How do I suggest a new feature ?
  See Submitting a feature request.

  Next steps

  At Piwik we care a lot about Data ownership. For this reason we need to have an up to date copy of all our tickets and comments out of github.com servers. Our next step will be to create and release as open source a tool to let anyone create a Mirror of their Github issues. See #5299.

  For more information about the Trac->migration, see #5273.

  We look forward to reading your issues on Github !

• Pushing Projects to Github

  17 février 2012, par Multimedia Mike — Game Hacking, Python

  I finally got around to importing some old projects into my Github account. I guess it’s good to have a backup out there in the cloud.

  GhettoRSS
  https://github.com/multimediamike/GhettoRSS
  I describe this as a true offline RSS reader. Technically, it’s arguably not a true offline RSS reader. Rather, it does what most people actually want an offline RSS reader to do.

  I wrote this about 2 years ago when I had a long daily train ride with a disconnected netbook. I quickly learned that I couldn’t count on offline RSS readers simply because most RSS feeds to not contain much meat. Thus, I created a program that follows URLs in RSS feeds, downloads web pages and supporting images and CSS files, and caches them in an offline database which can be read via a local web browser.

  I wrote more information about this little project 2 years ago (here is part 1 and here is part 2). I fixed a few bugs in preparation for posting it but I probably won’t work on this anymore since I don’t have any use for it (the commute is long gone, but I didn’t even use it when I was commuting because I decided I just didn’t care enough to read the feeds on the train).

  xbfuse
  https://github.com/multimediamike/xbfuse
  This is a FUSE module for mounting Xbox/360 optical disc filesystems. Here is when I first discussed it. The tool has had its own little homepage for a long time. This tool has seen some development, as I learned from Googling for “xbfuse”. Regrettably, no one who has modified the tool has ever contacted me about it (at least, not that I can recall). This is unfortunate because the patches I have seen floating around which fix my xbfuse for various installations usually boil down replacing many occurrences of an include path in the autotool-generated build system. There is probably a simpler, cleaner fix.

  gcfuse
  https://github.com/multimediamike/gcfuse
  Written prior to xbfuse, this is a FUSE module for mounting GameCube optical disc filesystems. I first discussed this here and here. This tool has not seen too much direct development although someone eventually used it as the basis for WiiFuse which, as you can predict, mounts optical disc filesystems from Nintendo Wii games.

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