Recherche avancée

Sur d’autres sites (9230)

• h264 lossless coding

  29 septembre 2014, par cloudraven

  Is it possible to do completely lossless encoding in h264 ? By lossless, I mean that if I feed it a series of frames and encode them, and then if I extract all the frames from the encoded video, I will get the exact same frames as in the input, pixel by pixel, frame by frame. Is that actually possible ?
  Take this example :

  I generate a bunch of frames, then I encode the image sequence to an uncompressed AVI (with something like virtualdub), I then apply lossless h264 (the help files claim that setting —qp 0 makes lossless compression, but I am not sure if that means that there is no loss at any point of the process or that just the quantization is lossless). I can then extract the frames from the resulting h264 video with something like mplayer.

  I tried with Handbrake first, but it turns out it doesn’t support lossless encoding. I tried x264 but it crashes. It may be because my source AVI file is in RGB colorspace instead of YV12. I don’t know how to feed a series of YV12 bitmaps and in what format to x264 anyway, so I cannot even try.

  In summary what I want to know if that is there a way to go from

  Series of lossless bitmaps (in any colorspace) -> some transformation -> h264 encode -> h264 decode -> some transformation -> the original series of lossless bitmaps

  If there a way to achieve this ?

  EDIT : There is a VERY valid point about lossless H264 not making too much sense. I am well aware that there is no way I could tell (with just my eyes) the difference between and uncompressed clip and another compressed at a high rate in H264, but I don’t think it is not without uses. For example, it may be useful for storing video for editing without taking huge amounts of space and not losing quality and spending too much encoding time every time the file is saved.

  UPDATE 2 : Now x264 doesn’t crash. I can use as sources either avisynth or lossless yv12 lagarith (to avoid the colorspace compression warning). Howerver, even with —qp 0 and a rgb or yv12 source I still get some differences, minimal but present. This is troubling, because all the information I have found on lossless predictive coding (—qp 0) claims that the whole encoding should be lossless, but I am unable to verifiy this.

• Notes on Linux for Dreamcast

  23 février 2011, par Multimedia Mike — Sega Dreamcast, VP8

  I wanted to write down some notes about compiling Linux on Dreamcast (which I have yet to follow through to success). But before I do, allow me to follow up on my last post where I got Google’s libvpx library decoding VP8 video on the DC. Remember when I said the graphics hardware could only process variations of RGB color formats ? I was mistaken. Reading over some old documentation, I noticed that the DC’s PowerVR hardware can also handle packed YUV textures (UYVY, specifically) :

  
  
  

  The video looks pretty sharp in the small photo. Up close, less so, due to the low resolution and high quantization of the test vector combined with the naive chroma upscaling. For the curious, the grey box surrounding the image highlights the 256-square texture that the video frame gets plotted on. Texture dimensions have to be powers of 2.

  Notes on Linux for Dreamcast
  I’ve occasionally dabbled with Linux on my Dreamcast. There’s an ancient (circa 2001) distro based around a build of kernel 2.4.5 out there. But I wanted to try to get something more current compiled. Thus far, I have figured out how to cross compile kernels pretty handily but have been unsuccessful in making them run.

  Here are notes are the compilation portion :
  

  • kernel.org provides a very useful set of cross compiling toolchains
  • get the gcc 4.5.1 cross toolchain for SH-4 (the gcc 4.3.3 one won’t work because the binutils is too old ; it will fail to assemble certain instructions as described in this post)
  • working off of Linux kernel 2.6.37, edit the top-level Makefile ; find the ARCH and CROSS_COMPILE variables and set appropriately :

    ARCH ?= sh
    CROSS_COMPILE ?= /path/to/gcc-4.5.1-nolibc/sh4-linux/bin/sh4-linux-
    

  • $ make dreamcast_defconfig
  • $ make menuconfig ... if any changes to the default configuration are desired
  • manually edit arch/sh/Makefile, changing :

    cflags-$(CONFIG_CPU_SH4) := $(call cc-option,-m4,) \
            $(call cc-option,-mno-implicit-fp,-m4-nofpu)
    

    to :

    cflags-$(CONFIG_CPU_SH4) := $(call cc-option,-m4,) \
            $(call cc-option,-mno-implicit-fp)
    

    I.e., remove the '-m4-nofpu' option. According to the gcc man page, this will "Generate code for the SH4 without a floating-point unit." Why this is a default is a mystery since the DC’s SH-4 has an FPU and compilation fails when enabling this option.

  • On that note, I was always under the impression that the DC sported an SH-4 CPU with the model number SH7750. According to this LinuxSH wiki page as well as the Linux kernel help, it actually has an SH7091 variant. This photo of the physical DC hardware corroborates the model number.
  • $ make ... to build a Linux kernel for the Sega Dreamcast

  Running
  So I can compile the kernel but running the kernel (the resulting vmlinux ELF file) gives me trouble. The default kernel ELF file reports an entry point of 0x8c002000. Attempting to upload this through the serial uploading facility I have available to me triggers a system reset almost immediately, probably because that’s the same place that the bootloader calls home. I have attempted to alter the starting address via ’make menuconfig’ -> System type -> Memory management options -> Physical memory start address. This allows the upload to complete but it still does not run. It’s worth noting that the 2.4.5 vmlinux file from the old distribution can be executed when uploaded through the serial loader, and it begins at 0x8c210000.

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