Recherche avancée

Sur d’autres sites (4996)

• Xuggler encoding and muxing

  18 décembre 2012, par HeineyBehinds

  I'm trying to use Xuggler (which I believe uses ffmpeg under the hood) to do the following :

  • Accept a raw MPJPEG video bitstream (from a small TTL serial camera) and encode/transcode it to h.264 ; and
  • Accept a raw audio bitsream (from a microphone) and encode it to AAC ; then
  • Mux the two (audio and video) bitsreams together into a MPEG-TS container

  I've watched/read some of their excellent tutorials, and so far here's what I've got :

  // I'll worry about implementing this functionality later, but
  
  // involves querying native device drivers.
  
  byte[] nextMjpeg = getNextMjpegFromSerialPort();
  
  
  
  // I'll also worry about implementing this functionality as well;
  
  // I'm simply providing these for thoroughness.
  
  BufferedImage mjpeg = MjpegFactory.newMjpeg(nextMjpeg);
  
  
  
  // Specify a h.264 video stream (how?)
  
  String h264Stream = "???";
  
  
  
  IMediaWriter writer = ToolFactory.makeWriter(h264Stream);
  
  writer.addVideoStream(0, 0, ICodec.ID.CODEC_ID_H264);
  
  writer.encodeVideo(0, mjpeg);

  For one, I think I'm close here, but it's still not correct ; and I've only gotten this far by reading the video code examples (not the audio - I can't find any good audio examples).

  Literally, I'll be getting byte-level access to the raw video and audio feeds coming into my Xuggler implementation. But for the life of me I can't figure out how to get them into an h.264/AAC/MPEG-TS format. Thanks in advance for any help here.

• Integrate necessary ffmpeg libraries in own project for MCU (microcontrolers) [closed]

  16 septembre 2023, par Borel Kamnang

  I use two ffmpeg commands here :

  


  ffmpeg -i BigBuckBunny_320x180.mp4 -vf scale=192:96,setsar=1:1 outputBBB.mp4
ffmpeg -i outputBBB.mp4 -vf "fps=12,scale=-1:96:flags=lanczos,crop=192:in_h:(in_w-192)/2:0" -c:v rawvideo -pix_fmt rgb565be BigBuckBunny_192x96_12fps.rgb


  


  The first is to downscale an original video and the second is to convert the scaled video to a .rgb format.

  


  As anew user of ffmpeg, I would like to know what are libraries used for that two command to just integrate them in my Arduino IDE C++ project an just call the necessary functions to do the downscale and the conversion.

  


  And another of my concerns is knowing how I can run any ffmpeg in an Raspberry Pi Pico W (RP2040) or ESP32 microcontroller ?

  


  I tried to include the ffmpeg libraries folder in a created Arduino IDE project for Raspberry pico w and the link for files doesn't work. In addition to having the config.h and config components.h files missing in the folder downloaded from the ffmpeg site, there are too many dependencies between .h and .c files.

  


  extern "C" {
  #include "src/ffmpeg/libavcodec/avcodec.h"       
  #include "src/ffmpeg/libavutil/mathematics.h"
}
void setup() {
   Serial.begin(115200);
   delay(10000);
 }
 loop(){
 }


  


  It's been three days today that I've been trying to compile from Arduino IDE, and correct the links in the files.
The problem is also that I don't even have the certainty of what it will work in the Raspberry Pi PicoW or ESP32 afterwards.

  


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