Recherche avancée

Sur d’autres sites (8739)

• Trouble with CoCCA Registry

  7 octobre 2012, par Multimedia Mike — General

  I’ve been rather despondent all week. People who see me daily could readily identify this fact. Unfortunately, the exact reason was difficult to adequately explain. The problems that nerds deal with…

  When A Domain Expires
  As a few people noticed, the multimedia.cx domain and all of it’s subdomains didn’t work this last week. The problem started on Monday, October 1. Whose fault ? Well, fundamentally, I neglected to renew the domain name in time. However, I prefer to place the blame on the .cx domain registrar, CoCCA Registry. You see, they have never developed the technology to email a domain holder with a notice that their domain is about to expire or has already expired.

  This domain is the only one I have ever held so I don’t have a lot of experience in this matter. I wondered if I was crazy for thinking it would be normal for a registrar to send an email or 2 with status updates about your domain. I get the impression from speaking with others that this is indeed normal. I have 3 different email addresses listed under my account at the registrar– 2 at multimedia.cx and a backup gmail account. I checked spam folders after this incident. Then I remembered that I have never received any email notifications from them (although password reset emails show up, so that part thankfully works). Also, their support emails are black holes.

  So, I guess the moral is : be wary of dealing with CoCCA Registry. However, they seem to be the only way to register domains under a wide variety of uncommon country codes.

  By Friday, the domain appeared to have been reinstated, even through the status was officially listed as “renewal-pending” according to the web-based management console. Eventually, as cached DNS results started to time out throughout the day, I started seeing subdomains come back. I excitedly used the ‘dig’ command to count down the seconds until gamemusic.multimedia.cx was accessible on the network I was on (the number after the domain name is the time-to-live or ‘TTL’ value) :

  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 3      IN      A       174.143.152.251
  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 2      IN      A       174.143.152.251
  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 1      IN      A       174.143.152.251
  $ dig +nocmd gamemusic.multimedia.cx +noall +answer
  gamemusic.multimedia.cx. 12962  IN      A       207.45.186.114
  

  Finally, today (Saturday), I received a receipt confirming that the domain has been renewed.

  8 Years Old
  Incidentally, happy eighth birthday to multimedia.cx. It was September, 2004 when I decided to branch out from a simple ISP-based web presence.

  People often ask why I went with the .cx TLD. When I decided I wanted a proper domain name 8 years ago, I found that multimedia.X was already taken for just about every TLD value of X. .cx was a notable exception and was distinctive enough (speaking of .X, though, I see that multimedia.xxx is still up for grabs as of this writing ; I imagine that would come with a whole other set of problems).

  It’s funny that tech nerds often rail against outsourcing too much — email, storage, computing power, web hosting — all to some type of cloud provider under the premise that it could easily be taken away. But this episode teaches me that even having your own domain name is no guarantee of a solid online presence.

  Meanwhile, I have taken proactive steps to avert this same situation from arising again :

  
  
  

  Barring a lack of automated emails from the registrar, I hope a Google Calendar reminder set up a month ahead of expiration will do the trick.

• Ffmpeg decoder yuv420p

  4 décembre 2015, par user2466514

  I work on a video player yuv420p with ffmpeg but it’s not working and i can’t find out why. I spend the whole week on it...

  So i have a test which just decode some frame and read it, but the output always differ, and it’s really weird.

  I use a video (mp4 yuv420p) which color one black pixel in more each frame :

  For the video, put http://sendvid.com/b1sgf8r1 on a website like http://www.telechargerunevideo.com/en/

  VideoContext is just a little struct :

  struct  VideoContext {
  
  
  
  unsigned int      currentFrame;
  
  std::size_t       size;
  
  int               width;
  
  int               height;
  
  bool              pause;
  
  AVFormatContext*  formatCtx;
  
  AVCodecContext*   codecCtxOrig;
  
  AVCodecContext*   codecCtx;
  
  int               streamIndex;
  
  };

  So i have a function to count the number of black pixels :

  std::size_t  checkFrameNb(const AVFrame* frame) {
  
  
  
      std::size_t  nb = 0;
  
  
  
      for (int y = 0; y < frame->height; ++y) {
  
        for (int x = 0 ; x < frame->width; ++x) {
  
  
  
          if (frame->data[0][(y * frame->linesize[0]) + x] == BLACK_FRAME.y
  
              && frame->data[1][(y / 2 * frame->linesize[1]) + x / 2] == BLACK_FRAME.u
  
              && frame->data[2][(y / 2 * frame->linesize[2]) + x / 2] == BLACK_FRAME.v)
  
            ++nb;
  
        }
  
      }
  
      return nb;
  
    }

  And this is how i decode one frame :

  const AVFrame*  VideoDecoder::nextFrame(entities::VideoContext& context) {
  
  
  
    int frameFinished;
  
    AVPacket packet;
  
  
  
    // Allocate video frame
  
    AVFrame*  frame = av_frame_alloc();
  
    if(frame == nullptr)
  
      throw;
  
  
  
    // Initialize frame->linesize
  
    avpicture_fill((AVPicture*)frame, nullptr, AV_PIX_FMT_YUV420P, context.width, context.height);
  
  
  
    while(av_read_frame(context.formatCtx, &packet) >= 0) {
  
  
  
      // Is this a packet from the video stream?
  
      if(packet.stream_index == context.streamIndex) {
  
        // Decode video frame
  
        avcodec_decode_video2(context.codecCtx, frame, &frameFinished, &packet);
  
  
  
        // Did we get a video frame?
  
        if(frameFinished) {
  
  
  
          // Free the packet that was allocated by av_read_frame
  
          av_free_packet(&packet);
  
          ++context.currentFrame;
  
          return frame;
  
        }
  
      }
  
    }
  
  
  
    // Free the packet that was allocated by av_read_frame
  
    av_free_packet(&packet);
  
    throw core::GlobalException("nextFrame", "Frame decode failed");
  
  }

  There is already something wrong ?

  Maybe the context initialization will be useful :

  entities::VideoContext  VideoLoader::loadVideoContext(const char* file,
  
                                                        const int width,
  
                                                        const int height) {
  
  
  
    entities::VideoContext  context;
  
  
  
    // Register all formats and codecs
  
    av_register_all();
  
  
  
    context.formatCtx = avformat_alloc_context();
  
  
  
  
  
    // Open video file
  
    if(avformat_open_input(&context.formatCtx, file, nullptr, 0) != 0)
  
      throw; // Couldn't open file
  
  
  
    // Retrieve stream information
  
    if(avformat_find_stream_info(context.formatCtx, nullptr) > 0)
  
      throw; // Couldn't find stream information
  
  
  
    // Dump information about file onto standard error
  
    //av_dump_format(m_formatCtx, 0, file, 1);
  
  
  
  
  
    // Find the first video stream because we don't need more
  
    for(unsigned int i = 0; i < context.formatCtx->nb_streams; ++i)
  
      if(context.formatCtx->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
  
        context.streamIndex = i;
  
        context.codecCtx = context.formatCtx->streams[i]->codec;
  
        break;
  
      }
  
    if(context.codecCtx == nullptr)
  
      throw; // Didn't find a video stream
  
  
  
  
  
    // Find the decoder for the video stream
  
    AVCodec*  codec = avcodec_find_decoder(context.codecCtx->codec_id);
  
    if(codec == nullptr)
  
      throw; // Codec not found
  
    // Copy context
  
    if ((context.codecCtxOrig = avcodec_alloc_context3(codec)) == nullptr)
  
      throw;
  
    if(avcodec_copy_context(context.codecCtxOrig, context.codecCtx) != 0)
  
      throw; // Error copying codec context
  
    // Open codec
  
    if(avcodec_open2(context.codecCtx, codec, nullptr) < 0)
  
      throw; // Could not open codec
  
  
  
    context.currentFrame = 0;
  
    decoder::VideoDecoder::setVideoSize(context);
  
    context.pause = false;
  
    context.width = width;
  
    context.height = height;
  
  
  
    return std::move(context);
  
  }

  I know it’s not a little piece of code, if you have any idea too make an exemple more brief, go on.

  And if someone have an idea about this issue, there is my output :

  9 - 10 - 12 - 4 - 10 - 14 - 11 - 8 - 9 - 10

  But i want :

  1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10

  PS :
  get fps and video size are copy paste code of opencv

• Reverse Engineering Radius VideoVision

  3 avril 2011, par Multimedia Mike — Reverse Engineering

  I was called upon to help reverse engineer an old video codec called VideoVision (FourCC : PGVV), ostensibly from a company named Radius. I’m not sure of the details exactly but I think a game developer has a bunch of original FMV data from an old game locked up in this format. The name of the codec sounded familiar. Indeed, we have had a sample in the repository since 2002. Alex B. did some wiki work on the codec some years ago. The wiki mentions that there existed a tool to transcode PGVV data into MJPEG-B data, which is already known and supported by FFmpeg.

  The Software
  My contacts were able to point me to some software, now safely archived in the PGVV samples directory. There is StudioPlayer2.6.2.sit.hqx which is supposed to be a QuickTime component for working with PGVV data. I can’t even remember how to deal with .sit or .hqx data. Then there is RadiusVVTranscoder101.zip which is the tool that transcodes to MJPEG-B.

  Disassembling for Reverse Engineering
  Since I could actually unpack the transcoder, I set my sights on that. Unpacking the archive sets up a directory structure for a component. There is a binary called RadiusVVTranscoder under RadiusVVTranscoder.component/Contents/MacOS/. Basic deadlisting disassembly is performed via ’otool’ as shown :

    otool -tV RadiusVVTranscoder | c++filt
  

  This results in a deadlisting of both PowerPC and 32-bit x86 code, as the binary is a "fat" Mac OS X binary designed to run on both architectures. The command line also demangles C++ function signatures which gives useful insight into the parameters passed to a function.

  Pretty Pictures
  The binary had a lot of descriptive symbols. As a basis for reverse engineering, I constructed call graphs using these symbols. Here are the 2 most relevant portions (click for larger images).

  The codec initialization generates Huffman tables relevant to the codec :

  
  
  

  The main decode function calls AddMJPGFrame which apparently does the heavy lifting for the transcode process :

  
  
  

  Based on this tree, I’m guessing that luma blocks can be losslessly transcoded (perhaps with different Huffman tables) which chroma blocks may rely on a different quantization method.

  Assembly Constructs
  I started looking at the instructions (the x86 ones, of course). The binary uses a calling convention I haven’t seen before, at least not for the x86 : Rather than pushing function arguments onto the stack, the code manually subtracts, e.g., 12 from the ESP register, loads 3 32-bit arguments into memory relative to ESP, and then proceeds with the function call.

  I’m also a little unclear on constructs such as "call ___i686.get_pc_thunk.bx" seen throughout relevant functions such as MakeRadiusQuantizationTables().

  I’m just presenting what I have so far in case anyone else wants to try their hand.