Recherche avancée

Sur d’autres sites (9422)

• Availability of WebM (VP8) Video Hardware IP Designs

  10 janvier 2011, par noreply@blogger.com (John Luther)

  Hello from the frigid city of Oulu, in the far north of Finland. Our WebM hardware development team, formerly part of On2 Technologies, is now up-to-speed and working hard on a number of video efforts for WebM.
  

  • VP8 (the video codec used in WebM) hardware decoder IP is available from Google for semiconductor companies who want to support high-quality WebM playback in their chipsets.
  • The Oulu team will release the first VP8 video hardware encoder IP in the first quarter of 2011. We have the IP running in an FPGA environment, and rigorous testing is underway. Once all features have been tested and implemented, the encoder will be launched as well.

  WebM video hardware IPs are implemented and delivered as RTL (VHDL/Verilog) source code, which is a register-level hardware description language for creating digital circuit designs. The code is based on the Hantro brand video IP from On2, which has been successfully deployed by numerous chipset companies around the world. Our designs support VP8 up to 1080p resolution and can run 30 or 60fps, depending on the foundry process and hardware clock frequency.

  The WebM/VP8 hardware decoder implementation has already been licensed to over twenty partners and is proven in silicon. We expect the first commercial chips to integrate our VP8 decoder IP to be available in the first quarter of 2011. For example, Chinese semiconductor maker Rockchip last week demonstrated full WebM hardware playback on their new RK29xx series processor at CES in Las Vegas (video below).
  

  
  Note : To view the video in WebM format, ensure that you’ve enrolled in the YouTube HTML5 trial and are using a WebM-compatible browser. You can also view the video on YouTube.

  Hardware implementations of the VP8 encoder also bring exciting possibilities for WebM in portable devices. Not only can hardware-accelerated devices play high-quality WebM content, but hardware encoding also enables high-resolution, real-time video communications apps on the same devices. For example, when VP8 video encoding is fully off-loaded to a hardware accelerator, you can run 720p or even 1080p video conferencing at full framerate on a portable device with minimal battery use.

  The WebM hardware video IP team will be focusing on further developing the VP8 hardware designs while also helping our semiconductor partners to implement WebM video compression in their chipsets. If you have any questions, please visit our Hardware page.

  Happy New Year to the WebM community !

  Jani Huoponen, Product Manager
  Aki Kuusela, Engineering Manager

  

• ffmpeg : -copyts makes -t stop at timestamps, not duration

  30 juillet 2017, par arielCo

  From

  -t duration (input/output)

  When used as an input option (before -i), limit the duration of data read from the input file.

  When used as an output option (before an output url), stop writing the output after its duration reaches duration.

  So this should yield a 1-minute file with timestamps starting at 1:49, right ?

  ffmpeg -y -copyts -ss 1:49 -i ~/Videos/input.mkv -c copy -t 1:00 timing-1m49s.mkv 
  
  ffmpeg version 3.3.2 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 7 (SUSE Linux)
  
    configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include/ffmpeg --extra-cflags='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g' --optflags='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --disable-openssl --enable-avresample --enable-libcdio --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libcelt --enable-libcdio --enable-libdc1394 --enable-libfreetype --enable-libgsm --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-netcdf --enable-vaapi --enable-vdpau --enable-libfdk_aac --enable-nonfree --enable-libmp3lame --enable-libtwolame --enable-libx264 --enable-libx265 --enable-libxvid
  
    libavutil      55. 58.100 / 55. 58.100
  
    libavcodec     57. 89.100 / 57. 89.100
  
    libavformat    57. 71.100 / 57. 71.100
  
    libavdevice    57.  6.100 / 57.  6.100
  
    libavfilter     6. 82.100 /  6. 82.100
  
    libavresample   3.  5.  0 /  3.  5.  0
  
    libswscale      4.  6.100 /  4.  6.100
  
    libswresample   2.  7.100 /  2.  7.100
  
    libpostproc    54.  5.100 / 54.  5.100
  
  Input #0, matroska,webm, from '/home/ariel/Videos/input.mkv':
  
    Metadata:
  
      encoder         : libebml v0.7.7 + libmatroska v0.8.0
  
      creation_time   : 2006-07-20T03:07:03.000000Z
  
    Duration: 00:23:57.06, start: 0.000000, bitrate: 1983 kb/s
  
      Stream #0:0: Video: h264 (High), yuv420p(progressive), 720x480, SAR 37:30 DAR 37:20, 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
  
      Stream #0:1(eng): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default)
  
      Stream #0:2(jpn): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
  
      Stream #0:3(eng): Subtitle: dvd_subtitle, 720x480 (default)
  
      Metadata:
  
        title           : English Audio
  
      Stream #0:4(eng): Subtitle: dvd_subtitle, 720x480
  
      Metadata:
  
        title           : Japanese Audio
  
  Output #0, matroska, to 'timing-1m49s.mkv':
  
    Metadata:
  
      encoder         : Lavf57.71.100
  
      Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p(progressive), 720x480 [SAR 37:30 DAR 37:20], q=2-31, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
  
      Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, fltp, 192 kb/s (default)
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
    Stream #0:1 -> #0:1 (copy)
  
  Press [q] to stop, [?] for help
  
  frame=    0 fps=0.0 q=-1.0 Lsize=       1kB time=00:00:00.00 bitrate=N/A speed=   0x    
  
  video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

  Wrong. It outputs a file with no frames :

  -rwxrwx--- 1 root users 805 Jul 30 01:36 timing-1m49s.mkv

  I have to specify -t 1:49 or more, and e.g. -t 1:55 produces a 6-second file that starts at 0:00 and according to the metadata should last 1:55.

  I arrived at this point trying to extract a clip and add subtitles in the same command, but this minimal case looks to me contrary to the documentation.

• Glitchy audio or broken video in fragmented MP4

  6 septembre 2022, par PookyFan

  I'm working on small C++ library for muxing audio and video. This is basically a facade for FFMPEG functions and structures. The code is here with minimal reproduction testing code here and as of now it seems like it's working fine... almost.

  


  For the record - my MP4 file is so-called "fragmented MP4", with headers moved at the beginning of the file in a way that would allow to stream that file (ie. play it in a browser while it's being buffered). That's what these movflags I'm setting in Mp4Muxer::writeHeader() are for.

  


  While testing this library with raw H264 video stream and MP3 file (video is <1 min long, MP3 - a few minutes long), I observed that :

  &#xA;

  &#xA;
  • if I don't limit muxing audio stream when it's way "ahead" of the video (and it will be since MP3 is longer, so eventually video frames stop coming but audio frames still come in), all muxes just fine with no errors, but playing output MP4 with ffplay after just a few seconds results in the following log (and also frozen video, while audio keeps playing) :

  &#xA;

  &#xA;

  [h264 @ 0x7f90a40ae2c0] Invalid NAL unit size (2162119 > 76779).0
[h264 @ 0x7f90a40ae2c0] Error splitting the input into NAL units.
[mp3float @ 0x7f90a4009540] Header missing  515KB sq=    0B f=0/0
[h264 @ 0x7f90a40cb0c0] Invalid NAL unit size (-860010620 > 17931).
[h264 @ 0x7f90a40cb0c0] Error splitting the input into NAL units.
[h264 @ 0x7f90a42bf440] Invalid NAL unit size (-168012642 > 8000).
[h264 @ 0x7f90a42bf440] Error splitting the input into NAL units.
[h264 @ 0x7f90a42fa780] Invalid NAL unit size (-1843711407 > 5683).
[ and it repeats...]


  &#xA;

  &#xA;
  • even if I limit how much a stream can be "ahead" of the other, limiting it too much results in no muxed data in the output

  &#xA;

  • any other intermediate level of limiting how much one stream can be buffered in muxer relative to the other stream results in glitchy audio, with the following errors popping out every now and then in ffplay (the more strict limit is, the more often they are printed) :

  &#xA;

  &#xA;

  [mp3float @ 0x7f744c01b640] overread, skip -6 enddists: -1 -1=0/0 


  &#xA;

  Not limitting muxed audio (at all or enough) relative to muxed video also results in following messages in my muxing application :

  &#xA;

  [mp4 @ 0x55d0c6c21940] Delay between the first packet and last packet in the muxing queue is 10004898 > 10000000: forcing output


  &#xA;

  For now, the fix is quite ugly and I don't even understand why it works, but before writting MP4 header I manually set a limit for frames buffered by muxer, like so :

  &#xA;

  formatCtxt->max_interleave_delta = 10000000LL * 10LL;


  &#xA;

  This way the muxer can store more packets of one stream that's way "ahead" of the other (maximum difference between DTS of the packets at the beginning and at the end of queue is set to 10x larger than default ; it also gets rid of information log mentioned above). Obviously, I'd like to resolve it more properly, without hacking things like that.

  &#xA;

  I was trying various things, including manual skipping of ID3 tags in MP3 file (but seems like FFMPEG handles them just fine and it didn't change anything). I was also experimenting with FLAC in MP4 instead of MP3. and while I know it's rather experimental thing, I encountered very similar problems with glitching audio (no problem with video being frozen when lots of audio data gets muxed, though). It also seems that problem with glitching audio or frozen video varies in scale depending on how large are input data chunks that I feed muxer with. For now, honestly, I'm out of ideas.

  &#xA;