Recherche avancée

Sur d’autres sites (9889)

• avformat/rtpdec_jpeg : fix low contrast image on low quality setting

  24 mars 2016, par Ico Doornekamp

  avformat/rtpdec_jpeg : fix low contrast image on low quality setting
  Original mail and my own followup on ffmpeg-user earlier today :
  I have a device sending out a MJPEG/RTP stream on a low quality setting.
  
  Decoding and displaying the video with libavformat results in a washed
  
  out, low contrast, greyish image. Playing the same stream with VLC results
  
  in proper color representation.
  Screenshots for comparison :
    http://zevv.nl/div/libav/shot-ffplay.jpg
  
    http://zevv.nl/div/libav/shot-vlc.jpg
  A pcap capture of a few seconds of video and SDP file for playing the
  
  stream are available at
    http://zevv.nl/div/libav/mjpeg.pcap
  
    http://zevv.nl/div/libav/mjpeg.sdp
  I believe the problem might be in the calculation of the quantization
  
  tables in the function create_default_qtables(), the attached patch
  
  solves the issue for me.
  The problem is that the argument ’q’ is of the type uint8_t. According to the
  
  JPEG standard, if 1 <= q <= 50, the scale factor ’S’ should be 5000 / Q.
  
  Because the create_default_qtables() reuses the variable ’q’ to store the
  
  result of this calculation, for small values of q < 19, q wil subsequently
  
  overflow and give wrong results in the calculated quantization tables. The
  
  patch below uses a new variable ’S’ (same name as in RFC2435) with the proper
  
  range to store the result of the division.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/rtpdec_jpeg.c

• test_streams : Use fopen instead of flac_fopen

  1er février 2016, par Erik de Castro Lopo

  test_streams : Use fopen instead of flac_fopen
  test_streams doesn’t create/open files with non-ascii filenames,
  
  so there’s no need in unicode support.
  Patch-from : lvqcl <lvqcl.mail@gmail.com>
  

  • [DH] FLAC-vs2005.sln
  • [DH] src/test_streams/Makefile.am
  • [DH] src/test_streams/Makefile.lite
  • [DH] src/test_streams/main.c
  • [DH] src/test_streams/test_streams.vcxproj

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.