Recherche avancée

Sur d’autres sites (7758)

• configure : Detect msvcrt libc with a CPP check instead of a link check

  4 décembre 2013, par Diego Biurrun

  configure : Detect msvcrt libc with a CPP check instead of a link check
  Simplifies host/target libc detection splitting.
  

  • [DH] configure

• Cannot encode vp9 video with alpha to ivf container

  28 juillet 2022, par Jakob Košir

  I'm trying to convert a vp8/webm video with transparency to vp9 and ivf container. I can encode the video to vp9 into webm container with the following command which correctly produces a vp9 video with transparency :

  


  ffmpeg -c:v libvpx -i dancer1.webm -c:v libvpx-vp9 dancer_vp9.webm


  


  So basically forcing libvpx encoders instead of ffmpeg native ones to support alpha.

  


  However if I try to use ivf container instead of webm the resulting video does not have transparency :

  


  ffmpeg -c:v libvpx -i dancer1.webm -c:v libvpx-vp9 dancer_vp9.ivf


  


  Does not have transparency when played with VLC, when converting frames to PNG using ffmpeg (ffmpeg -c:v libvpx-vp9 -i dancer_vp9.ivf -vf "select=eq(n\,0)" frame.png) and when played in Chrome (using webcodecs API). Does ivf not support alpha channel somehow or am I doing something wrong ?

  


  I also tried copying the stream with alpha from webm container to ivf (ffmpeg -i dancer1_vp9.webm -c copy dancer1_vp9_copy.ivf) which produces the same result, no transparency.

  


  Curiously if I force or don't force libvpx decoder (which is required to support transparency, ffmpeg native one seems to just discard the alpha channel) when reading vp8/vp9 webm video it produces the same result when outputting to ivf container, while when outputting to webm container the resulting video has alpha when using libvpx decoder and not when using native ffmepg decoder.

  


  ffprobe output of created ivf file :

  


  ffprobe version 5.0.1 Copyright (c) 2007-2022 the FFmpeg developers
  built with Apple clang version 13.1.6 (clang-1316.0.21.2.5)
  configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/5.0.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-neon
  libavutil      57. 17.100 / 57. 17.100
  libavcodec     59. 18.100 / 59. 18.100
  libavformat    59. 16.100 / 59. 16.100
  libavdevice    59.  4.100 / 59.  4.100
  libavfilter     8. 24.100 /  8. 24.100
  libswscale      6.  4.100 /  6.  4.100
  libswresample   4.  3.100 /  4.  3.100
  libpostproc    56.  3.100 / 56.  3.100
Input #0, ivf, from 'dancer_vp9.ivf':
  Duration: 00:01:02.87, start: 0.000000, bitrate: 249 kb/s
  Stream #0:0: Video: vp9 (Profile 0) (VP90 / 0x30395056), yuv420p(tv), 640x360, 30 tbr, 30 tbn


  


• Dreamcast Archival

  24 mai 2011, par Multimedia Mike — Sega Dreamcast

  Console homebrew communities have always had a precarious relationship with console pirates. The same knowledge and skills useful for creating homebrew programs can usually be parlayed into ripping games and cajoling a console into honoring ripped copies. For this reason, the Dreamcast homebrew community tried hard to distance itself from pirates, rippers, and other unsavory characters.

  
  
  

  Funny how times change. While I toed the same line while I was marginally a part of the community back in the day, now I think I’m performing a service for video game archivists and historians by openly publishing the same information. I know of at least one solution already. But I think it’s possible to do much better.

  Pre-existing Art
  Famed Japanese game hacker BERO (FFmpeg contributors should recognize his name from a number of Dreamcast-related multimedia contributions including CRI ADX and SH-4 optimizations) crafted a program called dreamrip based on KOS’s precursor called libdream. This is the program I used to extract 4XM multimedia files from Alone in the Dark : The New Nightmare.

  Fun facts : The Sega Dreamcast used special optical discs called GD-ROMs. The GD stands for ‘GigaDisc’ which implied that they could hold roughly a gigabyte of data. How long do you think it takes to transfer that much data over a serial cable operating at 115,200 bits/second (on the order of 11 Kbytes/sec) ? I seem to recall entire discs requiring on the order of 27-28 hours to archive.

  If only I possessed some expertise in data compression which might expedite this process.

  KallistiOS’ Unwitting Help
  The KallistiOS (KOS) console-oriented RTOS provides all the software infrastructure necessary for archiving (that’s what we’ll call it in this post) Dreamcast games. KOS exposes the optical disc’s filesystem via the /cd mount point on the VFS. From there, KOS provides functions for communicating with a host computer via ethernet (broadband adapter) or serial line (DC coder’s cable). To this end, KOS exposes another mount point on the VFS named /pc which allows direct access to the host PC’s filesystem.

  Thus, it’s pretty straightforward to use KOS to access the files (or raw sectors) of the Dreamcast disc and then send them over the communication line to the host PC. Simple.

  Compressing Before Transfer
  Right away, I wonder about compiling 3 different compression libraries : libz, libbz2, and liblzma. The latter 2 are exceptionally CPU-intensive to compress. Then again, it doesn’t really matter how long the compressor takes to do its job as long as it can average better than 11 Kbytes/sec on a 200MHz Hitachi SH-4 CPU. KOS can be set up in a preemptive threading mode which means it should be possible to read sectors and compress them while keeping the UART operating at full tilt.

  A 4th compression algorithm should be in play here as well : FLAC. Since some of these discs contain red book CD audio tracks that need archival, lossless audio compression should be useful.

  This post serves as a rough overview for possible future experiments. Readers might have further brainstorms.