Recherche avancée

Sur d’autres sites (7017)

• Call to avformat_find_stream_info prevents decoding of simple PNG image ?

  10 avril 2014, par kloffy

  I am running into a problem decoding a simple PNG image with libav. The decode_ok flag after the call to avcodec_decode_video2 is set to 0, even though the packet contains the entire image. Through some experimentation, I have managed to pinpoint the issue and it seems related to calling avformat_find_stream_info. If the call is removed, the example runs successfully. However, I would like to use the same code for other media, and calling avformat_find_stream_info is recommended in the documentation.

  The following minimal example illustrates the behavior (unfortunately still a bit lengthy) :

  #include <iostream>
  
  
  
  extern "C"
  
  {
  
  #include <libavformat></libavformat>avformat.h>
  
  #include <libavcodec></libavcodec>avcodec.h>
  
  }
  
  
  
  // Nothing to see here, it&#39;s just a helper function
  
  AVCodecContext* open(AVMediaType mediaType, AVFormatContext* formatContext)
  
  {
  
      auto ret = 0;
  
      if ((ret = av_find_best_stream(formatContext, mediaType, -1, -1, nullptr, 0)) &lt; 0)
  
      {
  
          std::cerr &lt;&lt; "Failed to find video stream." &lt;&lt; std::endl;
  
          return nullptr;
  
      }
  
  
  
      auto codecContext = formatContext->streams[ret]->codec;
  
      auto codec = avcodec_find_decoder(codecContext->codec_id);
  
      if (!codec)
  
      {
  
          std::cerr &lt;&lt; "Failed to find codec." &lt;&lt; std::endl;
  
          return nullptr;
  
      }
  
  
  
      if ((ret = avcodec_open2(codecContext, codec, nullptr)) != 0)
  
      {
  
          std::cerr &lt;&lt; "Failed to open codec context." &lt;&lt; std::endl;
  
          return nullptr;
  
      }
  
  
  
      return codecContext;
  
  }
  
  
  
  // All the interesting bits are here
  
  int main(int argc, char* argv[])
  
  {
  
      auto path = "/path/to/test.png"; // Replace with valid path to PNG
  
      auto ret = 0;
  
  
  
      av_log_set_level(AV_LOG_DEBUG);
  
  
  
      av_register_all();
  
      avcodec_register_all();
  
  
  
      auto formatContext = avformat_alloc_context();
  
      if ((ret = avformat_open_input(&amp;formatContext, path, NULL, NULL)) != 0)
  
      {
  
          std::cerr &lt;&lt; "Failed to open input." &lt;&lt; std::endl;
  
          return -1;
  
      }
  
      av_dump_format(formatContext, 0, path, 0);
  
  
  
  //*/ Info is successfully found, but interferes with decoding
  
      if((ret = avformat_find_stream_info(formatContext, nullptr)) &lt; 0)
  
      {
  
          std::cerr &lt;&lt; "Failed to find stream info." &lt;&lt; std::endl;
  
          return -1;
  
      }
  
      av_dump_format(formatContext, 0, path, 0);
  
  //*/
  
  
  
      auto codecContext = open(AVMEDIA_TYPE_VIDEO, formatContext);
  
  
  
      AVPacket packet;
  
      av_init_packet(&amp;packet);
  
  
  
      if ((ret = av_read_frame(formatContext, &amp;packet)) &lt; 0)
  
      {
  
          std::cerr &lt;&lt; "Failed to read frame." &lt;&lt; std::endl;
  
          return -1;
  
      }
  
  
  
      auto frame = av_frame_alloc();
  
      auto decode_ok = 0;
  
      if ((ret = avcodec_decode_video2(codecContext, frame, &amp;decode_ok, &amp;packet)) &lt; 0 || !decode_ok)
  
      {
  
          std::cerr &lt;&lt; "Failed to decode frame." &lt;&lt; std::endl;
  
          return -1;
  
      }
  
  
  
      av_frame_free(&amp;frame);
  
      av_free_packet(&amp;packet);
  
  
  
      avcodec_close(codecContext);
  
  
  
      avformat_close_input(&amp;formatContext);
  
      av_free(formatContext);
  
  
  
      return 0;
  
  }
  
  </iostream>

  The format dump before avformat_find_stream_info prints :

  Input #0, image2, from '/path/to/test.png' :
    Duration : N/A, bitrate : N/A
      Stream #0:0, 0, 1/25 : Video : png, 25 tbn

  The format dump after avformat_find_stream_info prints :

  Input #0, image2, from '/path/to/test.png' :
    Duration : 00:00:00.04, start : 0.000000, bitrate : N/A
      Stream #0:0, 1, 1/25 : Video : png, rgba, 512x512 [SAR 3780:3780 DAR 1:1], 1/25, 25 tbr, 25 tbn, 25 tbc

  So it looks like the search yields potentially useful information. Can anybody shed some light on this problem ? Other image formats seem to work fine. I assume that this is a simple user error rather than a bug.

  Edit : Debug logging was already enabled, but the PNG decoder does not produce a lot of output. I have also tried setting a custom logging callback.

  Here is what I get without the call to avformat_find_stream_info, when decoding succeeds :

  Statistics : 52125 bytes read, 0 seeks

  And here is what I get with the call to avformat_find_stream_info, when decoding fails :

  Statistics : 52125 bytes read, 0 seeks
  detected 8 logical cores
  

  The image is 52125 bytes, so the whole file is read. I am not sure what the logical cores are referring to.

• FFMPEG to create an MPEG-DASH stream with VP8

  24 avril 2017, par Kenneth Worden

  I’m trying to use FFMPEG to stream a live video feed from my webcam /dev/video0. Following scattered tutorials and scarce documentation (is this a known problem for the encoding community ?) I arrived at the following bash script :

  #!/bin/bash
  
  
  
  ffmpeg \
  
      -y \
  
      -f v4l2 \
  
          -i /dev/video0 \
  
          -s 640x480 \
  
          -input_format mjpeg \
  
          -r 24 \
  
      -map 0:0 \
  
      -pix_fmt yuv420p \
  
      -codec:v libvpx \
  
          -s 640x480 \
  
          -threads 4 \
  
          -b:v 50k \
  
          -tile-columns 4 \
  
          -frame-parallel 1 \
  
          -keyint_min 24 -g 24 \
  
      -f webm_chunk \
  
          -header "stream.hdr" \
  
          -chunk_start_index 1 \
  
      stream_%d.chk &
  
  
  
  sleep 2
  
  
  
  ffmpeg \
  
      -f webm_dash_manifest -live 1 \
  
      -i stream.hdr \
  
      -c copy \
  
      -map 0 \
  
      -f webm_dash_manifest -live 1 \
  
          -adaptation_sets "id=0,streams=0" \
  
          -chunk_start_index 1 \
  
          -chunk_duration_ms 1000 \
  
          -time_shift_buffer_depth 30000 \
  
          -minimum_update_period 60000 \
  
      stream_manifest.mpd

  When I run this script, my webcam light turns on, the stream.hdr and stream_manifest.mpd files are written, and chunks start to be created (i.e. stream_1.chk, stream_2.chk, etc...). However, FFMPEG throws the following error :

  Could not write header for output file #0 (incorrect codec parameters
   ?) : Invalid data found when processing input

  I will explain what I think I am doing with this script, and hopefully this will expose any errors in my thinking.

  First, we invoke FFMPEG to use Video for Linux 2 (v4l2) to read from my webcam (/dev/video0) of a resolution 640x480. The input format is mjpeg with a framerate of 24fps.

  I then declare that FFMPEG should "map" (copy) the video stream output by v4l2 to a file. I specify the pixel format (YUV420P) and use libvpx (VP8 encoding) to encode the video stream. I set the size to be 640x480, use 4 threads, set the bitrate to be 50kbps, do some magic with tile-columns and frame-parallel options, and set the I-frames to be 24 frames apart.

  I then create a stream.hdr file. The starting index is 1. This command continues to run infinitely until I kill it, grabbing new video from my webcam and outputting it into chunks.

  I then sleep for 2 seconds to give the previous command time to generate a header file.

  And that’s really it. The next invocation of FFMPEG simply creates the MPEG-DASH manifest file given the header generated in the previous step.

  So what’s going on ? Why can I not view the video in a web browser (I’m using Dash.js) ? I serve the manifest, header, and chunks on a Node.js server so that trivial issue is not the problem.

  ---

  Edit : Here is my full console output.

  ffmpeg version 3.0.7-0ubuntu0.16.10.1 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 6.2.0 (Ubuntu 6.2.0-5ubuntu12) 20161005
  
    configuration: --prefix=/usr --extra-version=0ubuntu0.16.10.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librubberband --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-chromaprint --enable-libx264
  
    libavutil      55. 17.103 / 55. 17.103
  
    libavcodec     57. 24.102 / 57. 24.102
  
    libavformat    57. 25.100 / 57. 25.100
  
    libavdevice    57.  0.101 / 57.  0.101
  
    libavfilter     6. 31.100 /  6. 31.100
  
    libavresample   3.  0.  0 /  3.  0.  0
  
    libswscale      4.  0.100 /  4.  0.100
  
    libswresample   2.  0.101 /  2.  0.101
  
    libpostproc    54.  0.100 / 54.  0.100
  
  [video4linux2,v4l2 @ 0x55847e244ea0] The driver changed the time per frame from 1/24 to 1/30
  
  [mjpeg @ 0x55847e245c00] Changing bps to 8
  
  Input #0, video4linux2,v4l2, from '/dev/video0':
  
    Duration: N/A, start: 64305.102081, bitrate: N/A
  
      Stream #0:0: Video: mjpeg, yuvj422p(pc, bt470bg/unknown/unknown), 640x480, -5 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
  
  Codec AVOption frame-parallel (Enable frame parallel decodability features) specified for output file #0 (stream_%d.chk) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
  
  Codec AVOption tile-columns (Number of tile columns to use, log2) specified for output file #0 (stream_%d.chk) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
  
  [swscaler @ 0x55847e24b720] deprecated pixel format used, make sure you did set range correctly
  
  [libvpx @ 0x55847e248a20] v1.5.0
  
  Output #0, webm_chunk, to 'stream_%d.chk':
  
    Metadata:
  
      encoder         : Lavf57.25.100
  
      Stream #0:0: Video: vp8 (libvpx), yuv420p, 640x480, q=-1--1, 50 kb/s, 30 fps, 30 tbn, 30 tbc
  
      Metadata:
  
        encoder         : Lavc57.24.102 libvpx
  
      Side data:
  
        unknown side data type 10 (24 bytes)
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (mjpeg (native) -> vp8 (libvpx))
  
  Press [q] to stop, [?] for help
  
  frame=   21 fps=0.0 q=0.0 size=N/A time=00:00:00.70 bitrate=N/A dup=5 drop=frame=   36 fps= 35 q=0.0 size=N/A time=00:00:01.20 bitrate=N/A dup=5 drop=frame=   51 fps= 33 q=0.0 size=N/A time=00:00:01.70 bitrate=N/A dup=5 drop=ffmpeg version 3.0.7-0ubuntu0.16.10.1 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 6.2.0 (Ubuntu 6.2.0-5ubuntu12) 20161005
  
    configuration: --prefix=/usr --extra-version=0ubuntu0.16.10.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librubberband --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-chromaprint --enable-libx264
  
    libavutil      55. 17.103 / 55. 17.103
  
    libavcodec     57. 24.102 / 57. 24.102
  
    libavformat    57. 25.100 / 57. 25.100
  
    libavdevice    57.  0.101 / 57.  0.101
  
    libavfilter     6. 31.100 /  6. 31.100
  
    libavresample   3.  0.  0 /  3.  0.  0
  
    libswscale      4.  0.100 /  4.  0.100
  
    libswresample   2.  0.101 /  2.  0.101
  
    libpostproc    54.  0.100 / 54.  0.100
  
  Input #0, webm_dash_manifest, from 'stream.hdr':
  
    Metadata:
  
      encoder         : Lavf57.25.100
  
    Duration: N/A, bitrate: N/A
  
      Stream #0:0: Video: vp8, yuv420p, 640x480, SAR 1:1 DAR 4:3, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
  
      Metadata:
  
        webm_dash_manifest_file_name: stream.hdr
  
        webm_dash_manifest_track_number: 1
  
  Output #0, webm_dash_manifest, to 'stream_manifest.mpd':
  
    Metadata:
  
      encoder         : Lavf57.25.100
  
      Stream #0:0: Video: vp8, yuv420p, 640x480 [SAR 1:1 DAR 4:3], q=2-31, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
  
      Metadata:
  
        webm_dash_manifest_file_name: stream.hdr
  
        webm_dash_manifest_track_number: 1
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
  Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input
  
  frame=   67 fps= 33 q=0.0 size
  
  frame=   82 fps= 32 q=0.0 size=N/A time=00:00:02.73 bitrate=N/A dup=5 drop=
  
  frame=   97 fps= 32 q=0.0 size=N/A time=00:00:03.23 bitrate=N/A dup=5 drop=
  
  frame=  112 fps= 32 q=0.0 size=N/A time=00:00:03.73 bitrate=N/A dup=5 ...

• Dreamcast SD Adapter and DreamShell

  31 décembre 2014, par Multimedia Mike — Sega Dreamcast

  Nope ! I’m never going to let go of the Sega Dreamcast hacking. When I was playing around with Dreamcast hacking early last year, I became aware that there is such a thing as an SD card adapter for the DC that plugs into the port normally reserved for the odd DC link cable. Of course I wanted to see what I could do with it.

  The primary software that leverages the DC SD adapter is called DreamShell. Working with this adapter and the software requires some skill and guesswork. Searching for these topics tends to turn up results from various forums where people are trying to cargo-cult their way to solutions. I have a strange feeling that this post might become the unofficial English-language documentation on the matter.

  Use Cases
  What can you do with this thing ? Undoubtedly, the primary use is for backing up (ripping) the contents of GD-ROMs (the custom optical format used for the DC) and playing those backed up (ripped) copies. Presumably, users of this device leverage the latter use case more than the former, i.e., download ripped games, load them on the SD card, and launch them using DreamShell.

  However, there are other uses such as multimedia playback, system exploration, BIOS reprogramming, high-level programming, and probably a few other things I haven’t figured out yet.

  Delivery
  I put in an order via the dc-sd.com website and in about 2 short months, the item arrived from China. This marked my third lifetime delivery from China and curiously, all 3 of the shipments have pertained to the Sega Dreamcast.

  
  

  

  Click for larger image

  
  

  I thought it was very interesting that this adapter came in such complete packaging. The text is all in Chinese, though the back states “Windows 98 / ME / 2000 / XP, Mac OS 9.1, LINUX2.4”. That’s what tipped me off that they must have just cannibalized some old USB SD card readers and packaging in order to create these. Closer inspection of the internals through the translucent pink case confirms this.

  Usage
  According to its change log, DreamShell has been around for a long time with version 1.0.0 released in February of 2004. The current version is 4.0.0 RC3. There are several downloads available :

  1. DreamShell 4.0 RC 3 CDI Image
  2. DreamShell 4.0 RC 3 + Boot Loader
  3. DreamShell 4.0 RC 3 + Core CDI image

  Option #2 worked for me. It contains a CDI disc image and the DreamShell files in a directory named DS/.

  Burn the CDI to a CD-R in the normal way you would burn a bootable Dreamcast disc from a CDI image. This is open-ended and left as an exercise to the reader, since there are many procedures depending on platform. On Linux, I used a small script I found once called burncdi-dc.sh.

  Then, copy the contents of the DS/ folder to an SD card. As for filesystem, FAT16 and FAT32 are both known to work. The files in DS/ should land in the root of the SD card ; the folder DS/ should not be in the root.

  Plug the SD card into the DC SD adapter and plug the adapter in the link cable port on the back of the Dreamcast. Then, boot the disc. If it works, you will see this minor corruption of the usual Sega licensing screen :

  
  
  

  Then, there will be a brief white-on-black text screen that explains the booting process :
  

  
  
  

  Then, there will be the main DreamShell logo :

  
  
  

  Finally, you will land on the DreamShell main desktop :

  
  
  

  Skepticism
  At first, I was supremely skeptical of the idea that this SD adapter could perform speedily enough to play games reasonably. This was predicated on the observation that my DC coder’s cable that I used to use for homebrew development could not transfer faster than 115200 bits/second, amounting to about 11 kbytes/sec. I assumed that this was a fundamental limitation of the link port.

  In fact, I ripped a few of my Dreamcast discs over a decade ago and still have those rips lying around. So I copied the ISO image of Resident Evil : Code Veronica — the game I personally played most on the DC — to the SD card (anywhere works) and used the “ISO loader” icon seen on the desktop above to launch the game.

  It works :

  
  
  

  The opening FMV plays at full speed. Everything loads as fast as I remember. I was quite surprised.

  Digression : My assumptions about serial speeds have often been mistaken. 10 years ago, I heard stories about how we would soon be able to watch streaming video on our cell phones. I scoffed because I thought the 56K limitation of dialup modems was some sort of fundamental speed-of-light type of limitation for telephony bandwidth, wired or wireless.

  The desktop menu also includes a ‘speedtest’ tool that profiles the write and read performance of your preferred storage medium. For my fastest SD card (a PNY 2 GB card) :

  
  
  

  This is probably more representative of the true adapter bandwidth as reading and writing is a good deal faster through more modern interfaces on PC and Mac with this same card.

  Look at the other options on the speedtest console. Hard drive ? Apparently, it’s possible, but it requires a good deal more hardware hacking than just purchasing this SD adapter.

  Ripping
  As you can see from the Resident Evil screenshot, playing games works quite nicely. How about ripping ? I’m pleased to say that DreamShell has a beautiful ripping interface :

  
  
  

  Enter a name for the disc (or read the disc label), select the storage medium, and let it, well, rip. It indicates which track it’s working on and the Sega logo acts as a progress bar, shading blue as the track rip progresses.

  I’m finally, efficiently, archiving that collection of Sega Dreamcast demo discs ; I’m hoping they’ll eventually find a home at the Internet Archive. How is overall ripping performance ? Usually about 38-40 minutes to rip a full 900-1000 MB. That certainly beats the 27-28 hours that were required when I performed the ripping at 11 kbytes/sec via the DC coders cable.

  All is well until I get a sector reading error :

  
  
  

  That’s when it can come in handy to have 3 DC consoles (see ?! not crazy !).

  Other Uses
  There’s a file explorer. You can browse the filesystem of the SD card, visual memory unit, or the CD portion of the GD-ROM (would be more useful if it accessed the GD area). There are FFmpeg files included. So I threw a random Cinepak file and random MPEG-1 file at it to see what happens. MPEG-1 didn’t do anything, but this Cinepak file from some Sierra game played handily :

  
  
  

  If you must enter strings, it helps to have a Dreamcast keyboard (which I do). Failing that, here’s a glimpse of the onscreen keyboard that DreamShell equips :

  
  
  

  Learning to use it is a game in itself.

  There is an option of installing DreamShell in the BIOS. I did not attempt this. I don’t know if it’s possible (not like there’s a lot of documentation)– perhaps a custom BIOS modchip is needed. But here’s what the screen looks like :

  
  
  

  There is also a plain console to interact with (better have a physical keyboard). There are numerous file manipulation commands and custom system interaction commands. I see one interesting command called ‘addr’ that looks useful for dumping memory regions to a file.

  A Lua language interpreter is also built in. I would love to play with this if I could ascertain whether DreamShell provided Dreamcast-specific APIs.

  Tips And Troubleshooting
  I have 3 Dreamcast consoles, affectionately named Terran, Protoss, and Zerg after the StarCraft II stickers with which they are adorned. Some seem to work better than others. Protoss seemed to be able to boot the DreamShell disc more reliably than the others. However, I was alarmed when it couldn’t boot one morning when it was churning the previous day.

  I think the problem is that it was just cold. That seemed to be the issue. I put in a normal GD-ROM and let it warm up on that disc for awhile and then DreamShell booted fine. So that’s my piece of cargo-culting troubleshooting advice.