Recherche avancée

Sur d’autres sites (4907)

• Reducing the bit rate is dropping the audio stream [closed]

  19 février 2013, par user977505

  I'm a newbie to the ffmpeg, x264 commands and conversion. So please bear w/ me.

  I've a H.264 content w/ very high bit rate and I'm using ffmepg, x264 commands to reduce the bit rate. The bit rate is getting reduced but the problem is the output doesn't have the audio stream anymore.

  Here are the commands, I'm using :

  ffmpeg.exe  -i King_Maker_Leader.mp4 -pix_fmt yuv420p -vf scale=1024:576 -r 24 \
    -f yuv4mpegpipe - | x264.exe  —bitrate 1664 —demuxer y4m \
    —preset slow —ref 3 —threads 6 —thread-input —no-scenecut \
    —no-interlaced —stats King_Maker_Leader.stats —vbv-bufsize 3328000 \
    —vbv-maxrate 1996 —pass 1 —output NUL —profile main —level 3.1 —sar 1:1 \
    —tune film —keyint 96 -
  ffmpeg.exe  -i King_Maker_Leader.mp4 -pix_fmt yuv420p -vf scale=1024:576 \
  
    -r 24 -f yuv4mpegpipe - | x264.exe  —bitrate 1664 —demuxer y4m \
  
    —preset slow —ref 3 —threads 6 —thread-input —no-scenecut \
  
    —no-interlaced —stats King_Maker_Leader.stats —vbv-bufsize 3328000 \
  
    —vbv-maxrate 1996 —pass 2 —output King_Maker_Leader_generated.mp4 \
  
    —profile main —level 3.1 —sar 1:1 —tune film —keyint 96 -
  

  I cannot figure out what is wrong with the above commands.

  I'm attaching the partial logs from pass 2 command that show the input has two streams (video and audio) and the output has only video stream.

  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '..\yathrakkarude_sathruka.mp4':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 512
  
      compatible_brands: isomiso2avc1mp41
  
      encoder         : Lavf54.6.101
  
    Duration: 00:01:00.37, start: 0.000000, bitrate: 8587 kb/s
  
      Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 720x576 [
  
  SAR 16:11 DAR 20:11], 8073 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc
  
      Metadata:
  
        handler_name    : VideoHandler
  
      Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 508
  
   kb/s
  
      Metadata:
  
        handler_name    : SoundHandler
  
  Output #0, yuv4mpegpipe, to 'pipe:':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 512
  
      compatible_brands: isomiso2avc1mp41
  
      encoder         : Lavf54.25.104
  
      Stream #0:0(eng): Video: rawvideo (I420 / 0x30323449), yuv420p, 1024x576 [SA
  
  R 45:44 DAR 20:11], q=2-31, 200 kb/s, 90k tbn, 24 tbc
  
      Metadata:
  
        handler_name    : VideoHandler
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (h264 -> rawvideo)
  
  Press [q] to stop, [?] for help
  
  [yuv4mpegpipe @ 016d5800] Encoder did not produce proper pts, making some up.
  
  y4m [info]: 1024x576p 45:44 @ 24/1 fps (cfr)
  
  x264 [info]: using SAR=1/1
  
  x264 [warning]: VBV buffer (2000000) > level limit (14000)
  
  x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT

• Summary Video Accessibility Talk

  23 avril 2013, par silvia

  I’ve just got off a call to the UK Digital TV Group, for which I gave a talk on HTML5 video accessibility (slides best viewed in Google Chrome).

  The slide provide a high-level summary of the accessibility features that we’ve developed in the W3C for HTML5, including :

  • Subtitles & Captions with WebVTT and the track element
  • Video Descriptions with WebVTT, the track element and speech synthesis
  • Chapters with WebVTT for semantic navigation
  • Audio Descriptions through synchronising an audio track with a video
  • Sign Language video synchronized with a main video

  I received some excellent questions.

  The obvious one was about why WebVTT and not TTML. While for anyone who has tried to implement TTML support, the advantages of WebVTT should be clear, for some the decision of the browsers to go with WebVTT still seems to be bothersome. The advantages of CSS over XSL-FO in a browser-context are obvious, but not as much outside browsers. So, the simplicity of WebVTT and the clear integration with HTML have to speak for themselves. Conversion between TTML and WebVTT was a feature that was being asked for.

  I received a question about how to support ducking (reduce the volume of the main audio track) when using video descriptions. My reply was to either use video descriptions with WebVTT and do ducking during the times that a cue is active, or when using audio descriptions (i.e. actual audio tracks) to add an additional WebVTT file of kind=metadata to mark the intervals in which to do ducking. In both cases some JavaScript will be necessary.

  I received another question about how to do clean audio, which I had almost forgotten was a requirement from our earlier media accessibility document. “Clean audio” consists of isolating the audio channel containing the spoken dialog and important non-speech information that can then be amplified or otherwise modified, while other channels containing music or ambient sounds are attenuated. I suggested using the mediagroup attribute to provide a main video element (without an audio track) and then the other channels as parallel audio tracks that can be turned on and off and attenuated individually. There is some JavaScript coding involved on top of the APIs that we have defined in HTML, but it can be implemented in browsers that support the mediagroup attribute.

  Another question was about the possibilities to extend the list of @kind attribute values. I explained that right now we have a proposal for a new text track kind=”forced” so as to provide forced subtitles for sections of video with foreign language. These would be on when no other subtitle or caption tracks are activated. I also explained that if there is a need for application-specific text tracks, the kind=”metadata” would be the correct choice.

  I received some further questions, in particular about how to apply styling to captions (e.g. color changes to text) and about how closely the browser are able to keep synchronization across multiple media elements. The earlier was easily answered with the ::cue pseudo-element, but the latter is a quality of implementation feature, so I had to defer to individual browsers.

  Overall it was a good exercise to summarize the current state of HTML5 video accessibility and I was excited to show off support in Chrome for all the features that we designed into the standard.

• FFmpeg Has A Native VP8 Decoder

  24 juin 2010, par Multimedia Mike — VP8

  Thanks to David Conrad and Ronald Bultje who committed their native VP8 video decoder to the FFmpeg codebase yesterday. At this point, it can decode 14/17 of the VP8 test vectors that Google released during the initial open sourcing event. Work is ongoing on those 3 non-passing samples (missing bilinear filter). Meanwhile, FFmpeg’s optimization-obsessive personalities are hard at work optimizing the native decoder. The current decoder is already profiled to be faster than Google/On2’s official libvpx.

  Testing
  So it falls to FATE to test this on the ridiculous diversity of platforms that FFmpeg supports. I staged individual test specs for each of the 17 test vectors : vp8-test-vector-001 ... vp8-test-vector-017. After the samples have propagated through to the various FATE installations, I’ll activate the 14 test specs that are currently passing.

  Initial Testing Methodology
  Inspired by Ronald Bultje’s idea, I built the latest FFmpeg-SVN with libvpx enabled. Then I selected between the reference and native decoders as such :

  $ for i in 001 002 003 004 005 006 007 008 009 \
   010 011 012 013 014 015 016 017
  do
    echo vp80-00-comprehensive-$i.ivf
    ffmpeg -vcodec libvpx -i \
      /path/to/vp8-test-vectors-r1/vp80-00-comprehensive-$i.ivf \
      -f framemd5 - 2> /dev/null
  done > refs.txt
  $ for i in 001 002 003 004 005 006 007 008 009 \
  
   010 011 012 013 014 015 016 017
  
  do
  
    echo vp80-00-comprehensive-$i.ivf
  
    ffmpeg -vcodec vp8 -i \
  
      /path/to/vp8-test-vectors-r1/vp80-00-comprehensive-$i.ivf \
  
      -f framemd5 - 2> /dev/null
  
  done > native.txt
  $ diff -u refs.txt native.txt
  

  That reveals precisely which files differ.