Recherche avancée

Sur d’autres sites (11501)

• Bye Bye FATE Machine

  4 septembre 2010, par Multimedia Mike — FATE Server

  This is the computer that performed the lion’s share of FATE cycles for the past 1.5 years before Mans put a new continuous integration system into service. I’ve now decided to let the machine go. I can’t get over how odd this feels since this thing is technically the best machine I own.

  
  
  

  It’s a small form factor Shuttle PC (SD37P2 v2) ; Core 2 Duo 2.13 GHz ; 2 GB RAM ; 400 GB SATA HD ; equipped with the only consistently functional optical drive in my house (uh oh). I used it as my primary desktop from March 2007 – November 2008, at which point I repurposed it for FATE cycles.

  As mentioned, the craziest part is that this is technically the best computer in my house. My new EeePC 1201PN isn’t at quite the same level ; my old EeePC can’t touch it, of course ; the Mac Mini has a little more RAM but doesn’t stack up in nearly all other areas. But the Shuttle just isn’t seeing that much use since the usurpation. I had it running automated backup duty for multimedia.cx but that’s easy enough to move to another, lower-powered system.

  Maybe the prognosticators are correct and the PC industry has matured to the point where raw computing power simply doesn’t matter anymore. I fancy myself as someone who knows how to put CPU power to work but even I don’t know what to do with the computing capacity I purchased over 3 years ago.

  Where will the Shuttle go ? A good home, I trust– I know a family that just arrived in the country and could use a computer.

• Merge commit ’5a0e953c2465be9d449d5f523c3d3e2b886910b2’

  13 mars 2015, par Michael Niedermayer

  Merge commit ’5a0e953c2465be9d449d5f523c3d3e2b886910b2’
  * commit ’5a0e953c2465be9d449d5f523c3d3e2b886910b2’ :
  
    mjpeg : Mark decoder family as thread safe
  Conflicts :
  
  	libavcodec/mjpegbdec.c
  
  	libavcodec/mjpegdec.c
  
  	libavcodec/mxpegdec.c
  
  	libavcodec/sp5xdec.c
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/jpeglsdec.c
  • [DH] libavcodec/mjpegbdec.c
  • [DH] libavcodec/mjpegdec.c
  • [DH] libavcodec/mxpegdec.c
  • [DH] libavcodec/sp5xdec.c

• How to decode in C a stream from this noname almost-UVC grayscale camera

  18 janvier 2019, par scriptfoo

  Edit : I found the cause. The stream always begins with something which is not a JPEG. Only after it there is a normal MJPEG stream. Interestingly, not all of the small examples of using V4L2/MJPEG decoders can divide what the camera produces properly into frames. Something called capturev4l2.c is a rare example of doing it properly. Possibly there is some detail, which decides if the camera’s bugginess is worked around or not.

  I have a noname almost-UVC-compliant camera (it fails several compatibility tests). This is a relatively cheap global shutter camera, and thus I would like to use it instead of something properly documented. It outputs what is reported (and properly played) by mplayer as

  Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
  
  libavcodec version 57.107.100 (external)
  
  Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG)

  ffprobe shows the following :

  [mjpeg @ 0x55c086dcc080] Format mjpeg detected only with low score of 25, misdetection possible!
  
  Input #0, mjpeg, from '/home/sc/Desktop/a.raw':
  
    Duration: N/A, bitrate: N/A
  
      Stream #0:0: Video: mjpeg, yuvj422p(pc, bt470bg/unknown/unknown), 640x480, 25 tbr, 1200k tbn, 25 tbc

  But as opposed to mplayer, it is unable to play it.

  I tried decode_jpeg_raw from mjpegtools, it complains about the header, which seems to change with each captured stream. So does not look like an unwrapped stream of JPEG images.

  I thus tried 0_hello_world.c from libavcodec/libavformat, but its stops at avformat_open_input() with an error Invalid data found when processing input. A 100-frame sample file is sitting here a.raw. Do you have any idea how to determine a method of decoding it in C into anything plain bitmap ?

  The file is grayscale, does not begin with a constant value, guvcview and mplayer are the only players I know, which can decode it without artifacts...