Recherche avancée

Sur d’autres sites (10407)

• Internecine Legal Threats

  1er juin 2011, par Multimedia Mike — Legal/Ethical

  FFmpeg and associated open source multimedia projects such as xine, MPlayer, and VLC have long had a rebel mystique about them ; a bunch of hackers playing fast and loose with IP law in order to give the world the free multimedia experience it deserved. We figured out the algorithms using any tools available, including the feared technique of binary reverse engineering. When I gave a presentation about FFmpeg at Linuxtag in 2007, I created this image illustrating said mystique :

  
  
  

  It garnered laughs. But I made the point that we multimedia hackers just press on, doing our thing while ignoring legal threats. The policy has historically worked out famously for us– to date, I seem to be the only person on the receiving end of a sort-of legal threat from the outside world.

  Who would have thought that the most credible legal threat to an open source multimedia project would emanate from a fork of that very project ? Because that’s exactly what has transpired :

  
  
  Click for full threat
  

  So it came to pass that Michael Niedermayer — the leader of the FFmpeg project — received a bona fide legal nastygram from Mans Rullgard, a representative of the FFmpeg-forked Libav project. The subject of dispute is a scorched-earth matter involving the somewhat iconic FFmpeg zigzag logo :

  Original 2D logo		enhanced 3D logo

  To think of all those years we spent worrying about legal threats from organizations outside the community. I’m reminded of that time-honored horror trope/urban legend staple : Get out ! The legal threats are coming from inside the house !

  I’m interested to see how this all plays out, particularly regarding jurisdiction, as we have a U.K. resident engaging an Italian lawyer outfit to deliver a legal threat to an Austrian citizen regarding an image hosted on a server in Hungary. I suspect I know why that law firm was chosen, but it’s still a curious jurisdictional setup.

  People often used to ask me if we multimedia hackers would get sued to death for doing what we do. My response was always, “There’s only one way to know for sure,” by which I meant that we would just have to engage in said shady activities and determine empirically if lawsuits resulted. So I’m a strong advocate for experimentation to push the limits. Kudos to Michael and Mans for volunteering to push the legal limits.

• Encoded images into H264 video are skipped and/or missing ?

  25 juillet 2013, par Jona

  I'm trying to encode images into an H264 MP4 video. The issues I'm having is that some of the images are skipped or at the end of the video simply missing. I need the video to play every single image I encode since it is an animation.

  Any help setting the encoder properly would be greatly appreciated !

  Encoder settings :

  AVCodecContext *c;
  
  ...
  
  c->codec_id = AV_CODEC_ID_H264;
  
  c->bit_rate = mOutputWidth*mOutputHeight*4;//400000;
  
  /* Resolution must be a multiple of two. */
  
  c->width    = mOutputWidth;
  
  c->height   = mOutputHeight;
  
      /* timebase: This is the fundamental unit of time (in seconds) in terms
  
       * of which frame timestamps are represented. For fixed-fps content,
  
       * timebase should be 1/framerate and timestamp increments should be
  
       * identical to 1. */
  
  c->time_base.den = mFps;
  
  c->time_base.num = 1;
  
  c->gop_size      = 12; /* emit one intra frame every twelve frames at most */
  
  c->pix_fmt       = AV_PIX_FMT_YUV420P;
  
  ...
  
  av_dict_set(&pOptions, "preset", "medium", 0);
  
  av_dict_set(&pOptions, "tune", "animation", 0);
  
  
  
  /* open the codec */
  
  ret = avcodec_open2(c, codec, &pOptions);
  
  if (ret < 0) {
  
      LOGE("Could not open video codec: %s", av_err2str(ret));
  
      return -1;
  
  }

  Update 07/24/13 :
  I was able to achieve a better video by setting the gop_size=FPS and writing the last video frame repeatedly FPS+1 times seemed to resolve all issues. To me it seems odd to do that but might be something standard in the video encoding world ? Any tips feedback about this ?

• Parsing avconv/ffmpeg rawvideo output ?

  23 avril 2013, par DigitalMan

  I'm about to begin a project that will involve working with the output of avconv/ffmpeg, pixel-by-pixel, in rgb32 format. I intend to work with a raw byte stream, such as from the pipe protocol. Basic pointer arithmetic (C/C++) will be used to iterate over these pixels, and modify them in arbitrary manners in real-time.

  I've created a very small file using rawvideo format and codec, and opened it up in a hex editor. As expected, it's just a series of pixels, read right to left, top to bottom. No distinguishing between lines - no problem, if you know how wide the video is beforehand. No distinguishing between frames - no problem, if you also know how tall the video is. No file header for frame rate, or even what the encoding (rgb32, rgb24, yuv, etc.) is - again, as long as you already know, it can be worked with.

  The problem occurs when - for one reason or another - some bytes are missing. Maybe the stream isn't being examined from the beginning, which is likely be the case in my project, or maybe something just got lost. All the pre-existing knowledge in the world (besides maybe a byte count of what's been missed, not gonna happen) won't prevent it from happily chugging along, with an incorrect offset of line and frame.

  So, what I'm looking for is an option for rawvideo, or possibly some other format/codec, that will allow me to work with the resulting stream at the pixel level, in RGB, yet still have a clear definition of where a new frame begins, even if it happens to start "looking" in the middle of a frame. (Width, height, and framerate will indeed be known.)