Recherche avancée

Sur d’autres sites (5019)

• Further Dreamcast Hacking

  3 février 2011, par Multimedia Mike — Sega Dreamcast

  I’m still haunted by Sega Dreamcast programming, specifically the fact that I used to be able to execute custom programs on the thing (roughly 8-10 years ago) and now I cannot. I’m going to compose a post to describe my current adventures on this front. There are 3 approaches I have been using : Raw, Kallistios, and the almighty Linux.

  
  

  Raw
  What I refer to as "raw" is an assortment of programs that lived in a small number of source files (sometimes just one ASM file) and could be compiled with the most basic SH-4 toolchain. The advantage here is that there aren’t many moving parts and not many things that can possibly go wrong, so it provides a good functional baseline.

  One of the original Dreamcast hackers was Marcus Comstedt, who still has his original DC material hosted at the reasonably easy-to-remember URL mc.pp.se/dc. I can get some of these simple demos to work, but not others.

  I also successfully assembled and ran a pair of 256-byte (!!) demos from this old DC scene page.

  KallistiOS
  KallistiOS (or just KOS) was a real-time OS developed for the DC and was popular among the DC homebrew community. All the programming I did back in the day was based around KOS. Now I can’t get any of it to work. More specifically, KOS can’t seem to make it past a certain point in its system initialization.

  The Linux Option
  I was never that excited about running Linux on my Dreamcast. For some hackers, running Linux on a given piece of consumer electronics is the highest attainable goal. Back in the day, I looked at it from a much more pragmatic perspective— I didn’t see much use in running Linux on the DC, not as much as running KOS which was developed to be a much more appropriate fit.

  However, I was able to burn a CD-R of an old binary image of Linux 2.4.5 compiled for the Dreamcast and boot it some months ago. So I at least have a feeling that this should work. I have never cross-compiled a kernel of my own (though I have compiled many, many x86 kernels in my time, so I’m not a total n00b in this regard). I figured this might be a good time to start.

  The first item that worries me is getting a functional cross-compiling toolchain. Fortunately, a little digging in the Linux kernel documentation pointed me in the direction of a bunch of ready-made toolchains hosted at kernel.org. So I grabbed one of the SH toolchains (gcc-4.3.3-nolibc) and got rolling.

  I’m well familiar with the cycle of 'make menuconfig' in order to pick configuration options, and then 'make' to build a kernel (or usually 'make zImage' or 'make bzImage' to create compressed images). For cross compiling, the primary difference seems to be editing the root Makefile in the Linux source code tree (I’m using 2.6.37, the latest stable as of this writing) and setting a value for the CROSS_COMPILE variable. Then, run 'make menuconfig' followed by 'make' as normal.

  The Linux 2.6 series is supposed to support a range of Renesas (formerly Hitachi) SH processors and board configurations. This includes reasonable defaults for the Sega Dreamcast hardware. I got it all compiling except for a series of .S files. Linus Torvalds once helped me debug a program I work on so I thought I’d see if there was something I could help debug here.

  The first issue was with ASM statements of a form similar to :

  mov #0xffffffe0, r1
  

  Now, the DC’s SH-4 is a RISC CPU. A lot of RISC architectures adopt a fixed instruction size of 32 bits. You can’t encode an entire 32-bit immediate value inside of a 32-bit instruction (there would be no room for the instruction encoding). Further, the SH series encoded instructions with a mere 16 bits. The move immediate data instruction only allows for an 8-bit, sign-extended value.

  I decided that the above statement is equivalent to :

  mov #-32, r1
  

  I’ll give this statement the benefit of the doubt that it used to work with the gcc toolchain somewhere along the line. I assume that the assembler is supposed to know enough to substitute the first form with the second.

  The next problem is that an ’sti’ instruction shows up in a number of spots. Using Intel x86 conventions, this is a "set interrupt flag" instruction (I remember that the 6502 CPU had the same instruction mnemonic, though its interrupt flag’s operation was opposite that of the x86). The SH-4 reference manual lists no ’sti’ instruction. When it gets to these lines, the assembler complains about immediate move instructions with too large data, like the instructions above. I’m guessing they must be macro’d to something else but I failed to find where. I commented out those lines for the time being. Probably not that smart, but I want to keep this moving for now.

  So I got the code to compile into a kernel file called ’vmlinux’. I’ve seen this file many times before but never thought about how to get it to run directly. The process has usually been to compress it and send it over to lilo or grub for loading, as that is the job of the bootloader. I have never even wondered what format the vmlinux file takes until now. It seems that ’vmlinux’ is just a plain old ELF file :

  $ file vmlinux
  vmlinux : ELF 32-bit LSB executable, Renesas SH,
  version 1 (SYSV), statically linked, not stripped
  

  The ’dc-tool’ program that uploads executables to the waiting bootloader on the Dreamcast is perfectly cool accepting ELF files (and S-record files, and raw binary files). After a very lengthy upload process, execution fails (resets the system).

  For the sake of comparison, I dusted off that Linux 2.4.5 bootable Dreamcast CD-ROM and directly uploaded the vmlinux file from that disc. That works just fine (until it’s time to go to the next loading phase, i.e., finding a filesystem). Possible issues here could include the commented ’sti’ instructions (could be that they aren’t just decoration). I’m also trying to understand the memory organization— perhaps the bootloader wants the ELF to be based at a different address. Or maybe the kernel and the bootloader don’t like each other in the first place— in this case, I need to study the bootable Linux CD-ROM to see how it’s done.

  Optimism
  Even though I’m meeting with rather marginal success, this is tremendously educational. I greatly enjoy these exercises if only for the deeper understanding they bring for the lowest-level system details.

• Does H.264 encoded video with BT.709 matrix include any gamma adjustment ?

  27 janvier 2019, par MoDJ

  I have read the BT.709 spec a number of times and the thing that is just not clear is should an encoded H.264 bitstream actually apply any gamma curve to the encoded data ? Note the specific mention of a gamma like formula in the BT.709 spec. Apple provided examples of OpenGL or Metal shaders that read YUV data from CoreVideo provided buffers do not do any sort of gamma adjustment. YUV values are being read and processed as though they are simple linear values. I also examined the source code of ffmpeg and found no gamma adjustments being applied after the BT.709 scaling step. I then created a test video with just two linear grayscale colors 5 and 26 corresponding to 2% and 10% levels. When converted to H.264 with both ffmpeg and iMovie, the output BT.709 values are (YCbCr) (20 128 128) and (38 128 128) and these values exactly match the output of the BT.709 conversion matrix without any gamma adjustment.

  A great piece of background on this topic can be found at Quicktime Gamma Bug. It seems that some historical issues with Quicktime and Adobe encoders were improperly doing different gamma adjustments and the results made video streams look awful on different players. This is really confusing because if you compare to sRGB, it clearly indicates how to apply a gamma encoding and then decode it to convert between sRGB and linear. Why does BT.709 go into so much detail about the same sort of gamma adjustment curve if no gamma adjustment is applied after the matrix step when creating a h.264 data stream ? Are all the color steps in a h.264 stream meant to be coded as straight linear (gamma 1.0) values ?

  In case specific example input would make things more clear, I am attaching 3 color bar images, the exact values of different colors can be displayed in an image editor with these image files.

  This first image is in the sRGB colorspace and is tagged as sRGB.

  

  This second image has been converted to the linear RGB colorspace and is tagged with a linear RGB profile.

  

  This third image has been converted to REC.709 profile levels with Rec709-elle-V4-rec709.icc from elles_icc_profiles
  . This seems to be what one would need to do to simulate "camera" gamma as described in BT.709.

  

  Note how the sRGB value in the lower right corner (0x555555) becomes linear RGB (0x171717) and the BT.709 gamma encoded value becomes (0x464646). What is unclear is if I should be passing a linear RGB value into ffmpeg or if I should be passing an already BT.709 gamma encoded value which would then need to be decoded in the client before the linear conversion Matrix step to get back to RGB.

  Update :

  Based on the feedback, I have updated my C based implementation and Metal shader and uploaded to github as an iOS example project MetalBT709Decoder.

  Encoding a normalized linear RGB value is implemented like this :

  static inline
  
  int BT709_convertLinearRGBToYCbCr(
  
                              float Rn,
  
                              float Gn,
  
                              float Bn,
  
                              int *YPtr,
  
                              int *CbPtr,
  
                              int *CrPtr,
  
                              int applyGammaMap)
  
  {
  
    // Gamma adjustment to non-linear value
  
  
  
    if (applyGammaMap) {
  
      Rn = BT709_linearNormToNonLinear(Rn);
  
      Gn = BT709_linearNormToNonLinear(Gn);
  
      Bn = BT709_linearNormToNonLinear(Bn);
  
    }
  
  
  
    // https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf
  
  
  
    float Ey = (Kr * Rn) + (Kg * Gn) + (Kb * Bn);
  
    float Eb = (Bn - Ey) / Eb_minus_Ey_Range;
  
    float Er = (Rn - Ey) / Er_minus_Ey_Range;
  
  
  
    // Quant Y to range [16, 235] (inclusive 219 values)
  
    // Quant Eb, Er to range [16, 240] (inclusive 224 values, centered at 128)
  
  
  
    float AdjEy = (Ey * (YMax-YMin)) + 16;
  
    float AdjEb = (Eb * (UVMax-UVMin)) + 128;
  
    float AdjEr = (Er * (UVMax-UVMin)) + 128;
  
  
  
    *YPtr = (int) round(AdjEy);
  
    *CbPtr = (int) round(AdjEb);
  
    *CrPtr = (int) round(AdjEr);
  
  
  
    return 0;
  
  }

  Decoding from YCbCr to linear RGB is implemented like so :

  static inline
  
  int BT709_convertYCbCrToLinearRGB(
  
                               int Y,
  
                               int Cb,
  
                               int Cr,
  
                               float *RPtr,
  
                               float *GPtr,
  
                               float *BPtr,
  
                               int applyGammaMap)
  
  {
  
    // https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.709_conversion
  
    // http://www.niwa.nu/2013/05/understanding-yuv-values/
  
  
  
    // Normalize Y to range [0 255]
  
    //
  
    // Note that the matrix multiply will adjust
  
    // this byte normalized range to account for
  
    // the limited range [16 235]
  
  
  
    float Yn = (Y - 16) * (1.0f / 255.0f);
  
  
  
    // Normalize Cb and CR with zero at 128 and range [0 255]
  
    // Note that matrix will adjust to limited range [16 240]
  
  
  
    float Cbn = (Cb - 128) * (1.0f / 255.0f);
  
    float Crn = (Cr - 128) * (1.0f / 255.0f);
  
  
  
    const float YScale = 255.0f / (YMax-YMin);
  
    const float UVScale = 255.0f / (UVMax-UVMin);
  
  
  
    const
  
    float BT709Mat[] = {
  
      YScale,   0.000f,  (UVScale * Er_minus_Ey_Range),
  
      YScale, (-1.0f * UVScale * Eb_minus_Ey_Range * Kb_over_Kg),  (-1.0f * UVScale * Er_minus_Ey_Range * Kr_over_Kg),
  
      YScale, (UVScale * Eb_minus_Ey_Range),  0.000f,
  
    };
  
  
  
    // Matrix multiply operation
  
    //
  
    // rgb = BT709Mat * YCbCr
  
  
  
    // Convert input Y, Cb, Cr to normalized float values
  
  
  
    float Rn = (Yn * BT709Mat[0]) + (Cbn * BT709Mat[1]) + (Crn * BT709Mat[2]);
  
    float Gn = (Yn * BT709Mat[3]) + (Cbn * BT709Mat[4]) + (Crn * BT709Mat[5]);
  
    float Bn = (Yn * BT709Mat[6]) + (Cbn * BT709Mat[7]) + (Crn * BT709Mat[8]);
  
  
  
    // Saturate normalzied linear (R G B) to range [0.0, 1.0]
  
  
  
    Rn = saturatef(Rn);
  
    Gn = saturatef(Gn);
  
    Bn = saturatef(Bn);
  
  
  
    // Gamma adjustment for RGB components after matrix transform
  
  
  
    if (applyGammaMap) {
  
      Rn = BT709_nonLinearNormToLinear(Rn);
  
      Gn = BT709_nonLinearNormToLinear(Gn);
  
      Bn = BT709_nonLinearNormToLinear(Bn);
  
    }
  
  
  
    *RPtr = Rn;
  
    *GPtr = Gn;
  
    *BPtr = Bn;
  
  
  
    return 0;
  
  }

  I believe this logic is implemented correctly, but I am having a very difficult time validating the results. When I generate a .m4v file that contains gamma adjusted color values (osxcolor_test_image_24bit_BT709.m4v), the result come out as expected. But a test case like (bars_709_Frame01.m4v) that I found here does not seem to work as the color bar values seem to be encoded as linear (no gamma adjustment).

  For a SMPTE test pattern, the 0.75 graylevel is linear RGB (191 191 191), should this RGB be encoded with no gamma adjustment as (Y Cb Cr) (180 128 128) or should the value in the bitstream appear as the gamma adjusted (Y Cb Cr) (206 128 128) ?

  (follow up)
  After doing additional research into this gamma issue, it has become clear that what Apple is actually doing in AVFoundation is using a 1.961 gamma function. This is the case when encoding with AVAssetWriterInputPixelBufferAdaptor, when using vImage, or with CoreVideo APIs. This piecewise gamma function is defined as follows :

  #define APPLE_GAMMA_196 (1.960938f)
  
  
  
  static inline
  
  float Apple196_nonLinearNormToLinear(float normV) {
  
    const float xIntercept = 0.05583828f;
  
  
  
    if (normV < xIntercept) {
  
      normV *= (1.0f / 16.0f);
  
    } else {
  
      const float gamma = APPLE_GAMMA_196;
  
      normV = pow(normV, gamma);
  
    }
  
  
  
    return normV;
  
  }
  
  
  
  static inline
  
  float Apple196_linearNormToNonLinear(float normV) {
  
    const float yIntercept = 0.00349f;
  
  
  
    if (normV < yIntercept) {
  
      normV *= 16.0f;
  
    } else {
  
      const float gamma = 1.0f / APPLE_GAMMA_196;
  
      normV = pow(normV, gamma);
  
    }
  
  
  
    return normV;
  
  }

• FFmpeg black screen using mpeg2video

  16 juin 2020, par Konata

  I have a proprietary piece of hardware for broadcasting, that accepts extremely specific video format.
The software that we use for it is extremely slow and outdated.

  



  I was looking at adapting FFmpeg to convert .avi/.mp4/etc to the specific format which in our case is

  



  


  .mpg ( 720*576 16:9, 25FPS, MPEG Video PAL v.2 (Main@High) BVOP)
 acceptable bitrate is 9000k - 15000k.

  


  



  So I have constructed this FFmpeg command :

  



  -i input.avi -codec:a mp2 -b:a 384k -c:v mpeg2video -aspect 16:9 -bf 2 -b:v 10000k -maxrate 10000k -minrate 10000k -bufsize 5000k  -profile:v main -level:v 4.0 output.mpg

  



  The audio is working fine, but instead of video I get a black screen, this is the conversion log

  



  "E:\auto_video\ffmpeg\bin\ffmpeg.exe" -i input.avi -codec:a mp2 -b:a 384k -c:v mpeg2video -aspect 16:9 -bf 2 -b:v 10000k -maxrate 10000k -minrate 10000k -bufsize 5000k -r 25  -profile:v main -level:v 4.0 output.mpg
ffmpeg version git-2020-06-12-38737b3 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 9.3.1 (GCC) 20200523
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --disable-w32threads --enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 54.100 / 56. 54.100
  libavcodec     58. 92.100 / 58. 92.100
  libavformat    58. 46.101 / 58. 46.101
  libavdevice    58. 11.100 / 58. 11.100
  libavfilter     7. 86.100 /  7. 86.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avi, from 'input.avi':
  Metadata:
    date            : 2020-06-04T14:11:03+06:00
  Duration: 00:00:10.00, start: 0.000000, bitrate: 30465 kb/s
    Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28915 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
    Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
File 'output.mpg' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (dvvideo (native) -> mpeg2video (native))
  Stream #0:1 -> #0:1 (pcm_s16le (native) -> mp2 (native))
Press [q] to stop, [?] for help
Output #0, mpeg, to 'output.mpg':
  Metadata:
    date            : 2020-06-04T14:11:03+06:00
    encoder         : Lavf58.46.101
    Stream #0:0: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 10000 kb/s, 25 fps, 90k tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.92.100 mpeg2video
    Side data:
      cpb: bitrate max/min/avg: 10000000/10000000/10000000 buffer size: 5000000 vbv_delay: N/A
    Stream #0:1: Audio: mp2, 48000 Hz, stereo, s16, 384 kb/s
    Metadata:
      encoder         : Lavc58.92.100 mp2
frame=  250 fps=0.0 q=2.5 Lsize=   12574kB time=00:00:09.99 bitrate=10302.7kbits/s speed=16.8x
video:12054kB audio:469kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.402694%"E:\auto_video\ffmpeg\bin\ffmpeg.exe" -i input.avi -codec:a mp2 -b:a 384k -c:v mpeg2video -aspect 16:9 -bf 2 -b:v 10000k -maxrate 10000k -minrate 10000k -bufsize 5000k -r 25  -profile:v main -level:v 4.0 output.mpg
ffmpeg version git-2020-06-12-38737b3 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 9.3.1 (GCC) 20200523
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --disable-w32threads --enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 54.100 / 56. 54.100
  libavcodec     58. 92.100 / 58. 92.100
  libavformat    58. 46.101 / 58. 46.101
  libavdevice    58. 11.100 / 58. 11.100
  libavfilter     7. 86.100 /  7. 86.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avi, from 'input.avi':
  Metadata:
    date            : 2020-06-04T14:11:03+06:00
  Duration: 00:00:10.00, start: 0.000000, bitrate: 30465 kb/s
    Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28915 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
    Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
File 'output.mpg' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (dvvideo (native) -> mpeg2video (native))
  Stream #0:1 -> #0:1 (pcm_s16le (native) -> mp2 (native))
Press [q] to stop, [?] for help
Output #0, mpeg, to 'output.mpg':
  Metadata:
    date            : 2020-06-04T14:11:03+06:00
    encoder         : Lavf58.46.101
    Stream #0:0: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 10000 kb/s, 25 fps, 90k tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.92.100 mpeg2video
    Side data:
      cpb: bitrate max/min/avg: 10000000/10000000/10000000 buffer size: 5000000 vbv_delay: N/A
    Stream #0:1: Audio: mp2, 48000 Hz, stereo, s16, 384 kb/s
    Metadata:
      encoder         : Lavc58.92.100 mp2
frame=  250 fps=0.0 q=2.5 Lsize=   12574kB time=00:00:09.99 bitrate=10302.7kbits/s speed=16.8x
video:12054kB audio:469kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.402694%


  



  Additional info that might help, I get black screen in MPC-HC, Windows Media Player, and the actual hardware that I converted it for. But it plays fine in VLC