Recherche avancée

Sur d’autres sites (8470)

• ffmpeg - How to determine if -movflags faststart is enabled ? PHP

  3 juin 2015, par IIIOXIII

  While I am able to encode an mp4 file which I can play on my local windows machine, I am having trouble encoding files to mp4 which are readable when streaming by safari, etc.

  After a bit of reading, I believe my issue is that I must move the metadata from the end of the file to the beginning in order for the converted mp4 files to be streamable.

  To that end, I am trying to find out if the build of ffmpeg that I am currently using is able to use the -movflags faststart option through php - as my current outputted mp4 files are not working when streamed online.

  This is the way I am now echoing the -help, -formats, -codecs, but I am not seeing anything about -movflags faststart in any of the lists :

  exec($ffmpegPath." -help", $codecArr);
  
  for($ii=0;$iibr>';
  
  }

  Is there a similar method of determining if -movflags fastart is available to my ffmpeg build ? Any other way ? Should it be listed with any of the previously suggested commands ? -help/-formats ?

  Can someone that knows it is enabled in their version of ffmpeg check to see if it is listed under -help or -formats, etc.?

  TIA.

  EDIT : COMPLETE CONSOLE OUTPUT FOR BOTH THE CONVERSION COMMAND AND -MOVFLAGS COMMAND BELOW :

  COMMAND :

  ffmpeg -i C:\vidtests\Wildlife.wmv -s 640x480 C:\vidtests\Wildlife.mp4 

  OUTPUT :

  ffmpeg version N-54207-ge59fb3f Copyright (c) 2000-2013 the FFmpeg developers
  
    built on Jun 25 2013 21:55:00 with gcc 4.7.3 (GCC)
  
    configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
  
  isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
  
  le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
  
  e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena
  
  ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l
  
  ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp
  
  eex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-
  
  amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --
  
  enable-libxvid --enable-zlib
  
    libavutil      52. 37.101 / 52. 37.101
  
    libavcodec     55. 17.100 / 55. 17.100
  
    libavformat    55. 10.100 / 55. 10.100
  
    libavdevice    55.  2.100 / 55.  2.100
  
    libavfilter     3. 77.101 /  3. 77.101
  
    libswscale      2.  3.100 /  2.  3.100
  
    libswresample   0. 17.102 /  0. 17.102
  
    libpostproc    52.  3.100 / 52.  3.100
  
  [asf @ 00000000002ed760] Stream #0: not enough frames to estimate rate; consider
  
   increasing probesize
  
  Guessed Channel Layout for  Input Stream #0.0 : stereo
  
  Input #0, asf, from 'C:\vidtests\Wildlife.wmv'
  
  :
  
    Metadata:
  
      SfOriginalFPS   : 299700
  
      WMFSDKVersion   : 11.0.6001.7000
  
      WMFSDKNeeded    : 0.0.0.0000
  
      comment         : Footage: Small World Productions, Inc; Tourism New Zealand
  
   | Producer: Gary F. Spradling | Music: Steve Ball
  
      title           : Wildlife in HD
  
      copyright       : ┬⌐ 2008 Microsoft Corporation
  
      IsVBR           : 0
  
      DeviceConformanceTemplate: AP@L3
  
    Duration: 00:00:30.09, start: 0.000000, bitrate: 6977 kb/s
  
      Stream #0:0(eng): Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, stereo, fltp
  
  , 192 kb/s
  
      Stream #0:1(eng): Video: vc1 (Advanced) (WVC1 / 0x31435657), yuv420p, 1280x7
  
  20, 5942 kb/s, 29.97 tbr, 1k tbn, 1k tbc
  
  [libx264 @ 00000000002e6980] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
  
  
  
  [libx264 @ 00000000002e6980] profile High, level 3.0
  
  [libx264 @ 00000000002e6980] 264 - core 133 r2334 a3ac64b - H.264/MPEG-4 AVC cod
  
  ec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=1 r
  
  ef=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed
  
  _ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pski
  
  p=1 chroma_qp_offset=-2 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 deci
  
  mate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_
  
  adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=2
  
  5 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.6
  
  0 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  
  Output #0, mp4, to 'C:\vidtests\Wildlife.mp4':
  
  
  
    Metadata:
  
      SfOriginalFPS   : 299700
  
      WMFSDKVersion   : 11.0.6001.7000
  
      WMFSDKNeeded    : 0.0.0.0000
  
      comment         : Footage: Small World Productions, Inc; Tourism New Zealand
  
   | Producer: Gary F. Spradling | Music: Steve Ball
  
      title           : Wildlife in HD
  
      copyright       : ┬⌐ 2008 Microsoft Corporation
  
      IsVBR           : 0
  
      DeviceConformanceTemplate: AP@L3
  
      encoder         : Lavf55.10.100
  
      Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 6
  
  40x480, q=-1--1, 30k tbn, 29.97 tbc
  
      Stream #0:1(eng): Audio: aac (libvo_aacenc) ([64][0][0][0] / 0x0040), 44100
  
  Hz, stereo, s16, 128 kb/s
  
  Stream mapping:
  
    Stream #0:1 -> #0:0 (vc1 -> libx264)
  
    Stream #0:0 -> #0:1 (wmav2 -> libvo_aacenc)
  
  Press [q] to stop, [?] for help
  
  frame=   53 fps= 49 q=29.0 size=       0kB time=00:00:00.13 bitrate=   2.9kbits/
  
  frame=   63 fps= 40 q=29.0 size=       0kB time=00:00:00.46 bitrate=   0.8kbits/
  
  frame=   74 fps= 35 q=29.0 size=       0kB time=00:00:00.83 bitrate=   0.5kbits/
  
  frame=   85 fps= 32 q=29.0 size=       0kB time=00:00:01.20 bitrate=   0.3kbits/
  
  frame=   95 fps= 30 q=29.0 size=       0kB time=00:00:01.53 bitrate=   0.3kbits/
  
  frame=  107 fps= 28 q=29.0 size=       0kB time=00:00:01.93 bitrate=   0.2kbits/
  
  Queue input is backward in time
  
  [mp4 @ 00000000003ef800] Non-monotonous DTS in output stream 0:1; previous: 7616
  
  , current: 7063; changing to 7617. This may result in incorrect timestamps in th
  
  e output file.
  
  frame=  118 fps= 28 q=29.0 size=     113kB time=00:00:02.30 bitrate= 402.6kbits/
  
  frame=  129 fps= 26 q=29.0 size=     219kB time=00:00:02.66 bitrate= 670.7kbits/
  
  frame=  141 fps= 26 q=29.0 size=     264kB time=00:00:03.06 bitrate= 704.2kbits/
  
  frame=  152 fps= 25 q=29.0 size=     328kB time=00:00:03.43 bitrate= 782.2kbits/
  
  frame=  163 fps= 25 q=29.0 size=     431kB time=00:00:03.80 bitrate= 928.1kbits/
  
  frame=  174 fps= 24 q=29.0 size=     568kB time=00:00:04.17 bitrate=1116.3kbits/
  
  frame=  190 fps= 25 q=29.0 size=     781kB time=00:00:04.70 bitrate=1359.9kbits/
  
  frame=  204 fps= 25 q=29.0 size=    1006kB time=00:00:05.17 bitrate=1593.1kbits/
  
  frame=  218 fps= 25 q=29.0 size=    1058kB time=00:00:05.63 bitrate=1536.8kbits/
  
  frame=  229 fps= 25 q=29.0 size=    1093kB time=00:00:06.00 bitrate=1490.9kbits/
  
  frame=  239 fps= 24 q=29.0 size=    1118kB time=00:00:06.33 bitrate=1444.4kbits/
  
  frame=  251 fps= 24 q=29.0 size=    1150kB time=00:00:06.74 bitrate=1397.9kbits/
  
  frame=  265 fps= 24 q=29.0 size=    1234kB time=00:00:07.20 bitrate=1402.3kbits/
  
  frame=  278 fps= 25 q=29.0 size=    1332kB time=00:00:07.64 bitrate=1428.3kbits/
  
  frame=  294 fps= 25 q=29.0 size=    1403kB time=00:00:08.17 bitrate=1405.7kbits/
  
  frame=  308 fps= 25 q=29.0 size=    1547kB time=00:00:08.64 bitrate=1466.4kbits/
  
  frame=  323 fps= 25 q=29.0 size=    1595kB time=00:00:09.14 bitrate=1429.5kbits/
  
  frame=  337 fps= 25 q=29.0 size=    1702kB time=00:00:09.60 bitrate=1450.7kbits/
  
  frame=  351 fps= 25 q=29.0 size=    1755kB time=00:00:10.07 bitrate=1427.1kbits/
  
  frame=  365 fps= 25 q=29.0 size=    1820kB time=00:00:10.54 bitrate=1414.1kbits/
  
  frame=  381 fps= 25 q=29.0 size=    1852kB time=00:00:11.07 bitrate=1369.6kbits/
  
  frame=  396 fps= 26 q=29.0 size=    1893kB time=00:00:11.57 bitrate=1339.5kbits/
  
  frame=  409 fps= 26 q=29.0 size=    1923kB time=00:00:12.01 bitrate=1311.8kbits/
  
  frame=  421 fps= 25 q=29.0 size=    1967kB time=00:00:12.41 bitrate=1298.3kbits/
  
  frame=  434 fps= 25 q=29.0 size=    1998kB time=00:00:12.84 bitrate=1274.0kbits/
  
  frame=  445 fps= 25 q=29.0 size=    2018kB time=00:00:13.21 bitrate=1251.3kbits/
  
  frame=  458 fps= 25 q=29.0 size=    2048kB time=00:00:13.64 bitrate=1229.5kbits/
  
  frame=  471 fps= 25 q=29.0 size=    2067kB time=00:00:14.08 bitrate=1202.3kbits/
  
  frame=  484 fps= 25 q=29.0 size=    2189kB time=00:00:14.51 bitrate=1235.5kbits/
  
  frame=  497 fps= 25 q=29.0 size=    2260kB time=00:00:14.94 bitrate=1238.3kbits/
  
  frame=  509 fps= 25 q=29.0 size=    2311kB time=00:00:15.34 bitrate=1233.3kbits/
  
  frame=  523 fps= 25 q=29.0 size=    2429kB time=00:00:15.81 bitrate=1258.1kbits/
  
  frame=  535 fps= 25 q=29.0 size=    2541kB time=00:00:16.21 bitrate=1283.5kbits/
  
  frame=  548 fps= 25 q=29.0 size=    2718kB time=00:00:16.64 bitrate=1337.5kbits/
  
  frame=  560 fps= 25 q=29.0 size=    2845kB time=00:00:17.05 bitrate=1367.1kbits/
  
  frame=  571 fps= 25 q=29.0 size=    2965kB time=00:00:17.41 bitrate=1394.6kbits/
  
  frame=  580 fps= 25 q=29.0 size=    3025kB time=00:00:17.71 bitrate=1398.7kbits/
  
  frame=  588 fps= 25 q=29.0 size=    3098kB time=00:00:17.98 bitrate=1411.1kbits/
  
  frame=  597 fps= 25 q=29.0 size=    3183kB time=00:00:18.28 bitrate=1426.1kbits/
  
  frame=  606 fps= 24 q=29.0 size=    3279kB time=00:00:18.58 bitrate=1445.2kbits/
  
  frame=  616 fps= 24 q=29.0 size=    3441kB time=00:00:18.91 bitrate=1489.9kbits/
  
  frame=  626 fps= 24 q=29.0 size=    3650kB time=00:00:19.25 bitrate=1553.0kbits/
  
  frame=  638 fps= 24 q=29.0 size=    3826kB time=00:00:19.65 bitrate=1594.7kbits/
  
  frame=  649 fps= 24 q=29.0 size=    3950kB time=00:00:20.02 bitrate=1616.3kbits/
  
  frame=  660 fps= 24 q=29.0 size=    4067kB time=00:00:20.38 bitrate=1634.1kbits/
  
  frame=  669 fps= 24 q=29.0 size=    4121kB time=00:00:20.68 bitrate=1631.8kbits/
  
  frame=  682 fps= 24 q=29.0 size=    4274kB time=00:00:21.12 bitrate=1657.9kbits/
  
  frame=  696 fps= 24 q=29.0 size=    4446kB time=00:00:21.58 bitrate=1687.1kbits/
  
  frame=  709 fps= 24 q=29.0 size=    4590kB time=00:00:22.02 bitrate=1707.3kbits/
  
  frame=  719 fps= 24 q=29.0 size=    4772kB time=00:00:22.35 bitrate=1748.5kbits/
  
  frame=  732 fps= 24 q=29.0 size=    4852kB time=00:00:22.78 bitrate=1744.3kbits/
  
  frame=  744 fps= 24 q=29.0 size=    4973kB time=00:00:23.18 bitrate=1756.9kbits/
  
  frame=  756 fps= 24 q=29.0 size=    5099kB time=00:00:23.59 bitrate=1770.8kbits/
  
  frame=  768 fps= 24 q=29.0 size=    5149kB time=00:00:23.99 bitrate=1758.4kbits/
  
  frame=  780 fps= 24 q=29.0 size=    5227kB time=00:00:24.39 bitrate=1755.7kbits/
  
  frame=  797 fps= 24 q=29.0 size=    5377kB time=00:00:24.95 bitrate=1765.0kbits/
  
  frame=  813 fps= 24 q=29.0 size=    5507kB time=00:00:25.49 bitrate=1769.5kbits/
  
  frame=  828 fps= 24 q=29.0 size=    5634kB time=00:00:25.99 bitrate=1775.5kbits/
  
  frame=  843 fps= 24 q=29.0 size=    5701kB time=00:00:26.49 bitrate=1762.9kbits/
  
  frame=  859 fps= 24 q=29.0 size=    5830kB time=00:00:27.02 bitrate=1767.0kbits/
  
  frame=  872 fps= 24 q=29.0 size=    5926kB time=00:00:27.46 bitrate=1767.7kbits/
  
  frame=  888 fps= 24 q=29.0 size=    6014kB time=00:00:27.99 bitrate=1759.7kbits/
  
  frame=  900 fps= 24 q=29.0 size=    6332kB time=00:00:28.39 bitrate=1826.9kbits/
  
  frame=  901 fps= 24 q=-1.0 Lsize=    6717kB time=00:00:30.10 bitrate=1828.0kbits
  
  /s
  
  video:6211kB audio:472kB subtitle:0 global headers:0kB muxing overhead 0.513217%
  
  
  
  [libx264 @ 00000000002e6980] frame I:8     Avg QP:21.77  size: 39744
  
  [libx264 @ 00000000002e6980] frame P:433   Avg QP:25.69  size: 11490
  
  [libx264 @ 00000000002e6980] frame B:460   Avg QP:29.25  size:  2319
  
  [libx264 @ 00000000002e6980] consecutive B-frames:  5.4% 78.6%  2.7% 13.3%
  
  [libx264 @ 00000000002e6980] mb I  I16..4: 21.8% 48.8% 29.5%
  
  [libx264 @ 00000000002e6980] mb P  I16..4:  0.7%  4.0%  1.3%  P16..4: 37.1% 22.2
  
  % 15.5%  0.0%  0.0%    skip:19.2%
  
  [libx264 @ 00000000002e6980] mb B  I16..4:  0.1%  0.5%  0.2%  B16..8: 43.5%  7.0
  
  %  2.1%  direct: 2.2%  skip:44.5%  L0:36.4% L1:52.7% BI:10.9%
  
  [libx264 @ 00000000002e6980] 8x8 transform intra:62.8% inter:56.2%
  
  [libx264 @ 00000000002e6980] coded y,uvDC,uvAC intra: 74.2% 78.8% 44.0% inter: 2
  
  3.6% 14.5% 1.0%
  
  [libx264 @ 00000000002e6980] i16 v,h,dc,p: 48% 24%  9% 20%
  
  [libx264 @ 00000000002e6980] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 17% 15%  7%  8%
  
  11%  8% 10%  8%
  
  [libx264 @ 00000000002e6980] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 17% 15%  7% 10%
  
  11%  8%  7%  7%
  
  [libx264 @ 00000000002e6980] i8c dc,h,v,p: 53% 21% 18%  7%
  
  [libx264 @ 00000000002e6980] Weighted P-Frames: Y:0.7% UV:0.0%
  
  [libx264 @ 00000000002e6980] ref P L0: 62.4% 19.0% 12.0%  6.6%  0.0%
  
  [libx264 @ 00000000002e6980] ref B L0: 90.5%  8.9%  0.7%
  
  [libx264 @ 00000000002e6980] ref B L1: 97.9%  2.1%
  
  [libx264 @ 00000000002e6980] kb/s:1692.37

  AND THE –MOVFLAGS COMMAND :

  ffmpeg -i C:\vidtests\Wildlife.mp4 -movflags faststart C:\vidtests\Wildlife_fs.mp4

  AND THE –MOVFLAGS OUTPUT

  ffmpeg version N-54207-ge59fb3f Copyright (c) 2000-2013 the FFmpeg developers
  
    built on Jun 25 2013 21:55:00 with gcc 4.7.3 (GCC)
  
    configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
  
  isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
  
  le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
  
  e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena
  
  ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l
  
  ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp
  
  eex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-
  
  amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --
  
  enable-libxvid --enable-zlib
  
    libavutil      52. 37.101 / 52. 37.101
  
    libavcodec     55. 17.100 / 55. 17.100
  
    libavformat    55. 10.100 / 55. 10.100
  
    libavdevice    55.  2.100 / 55.  2.100
  
    libavfilter     3. 77.101 /  3. 77.101
  
    libswscale      2.  3.100 /  2.  3.100
  
    libswresample   0. 17.102 /  0. 17.102
  
    libpostproc    52.  3.100 / 52.  3.100
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\vidtests\Wildlife.mp4':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 512
  
      compatible_brands: isomiso2avc1mp41
  
      title           : Wildlife in HD
  
      encoder         : Lavf55.10.100
  
      comment         : Footage: Small World Productions, Inc; Tourism New Zealand
  
   | Producer: Gary F. Spradling | Music: Steve Ball
  
      copyright       : ┬⌐ 2008 Microsoft Corporation
  
    Duration: 00:00:30.13, start: 0.036281, bitrate: 1826 kb/s
  
      Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x480,
  
  1692 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc
  
      Metadata:
  
        handler_name    : VideoHandler
  
      Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 12
  
  8 kb/s
  
      Metadata:
  
        handler_name    : SoundHandler
  
  [libx264 @ 0000000004360620] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
  
  
  
  [libx264 @ 0000000004360620] profile High, level 3.0
  
  [libx264 @ 0000000004360620] 264 - core 133 r2334 a3ac64b - H.264/MPEG-4 AVC cod
  
  ec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=1 r
  
  ef=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed
  
  _ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pski
  
  p=1 chroma_qp_offset=-2 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 deci
  
  mate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_
  
  adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=2
  
  5 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.6
  
  0 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  
  Output #0, mp4, to 'C:\vidtests\Wildlife_fs.mp4':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 512
  
      compatible_brands: isomiso2avc1mp41
  
      title           : Wildlife in HD
  
      copyright       : ┬⌐ 2008 Microsoft Corporation
  
      comment         : Footage: Small World Productions, Inc; Tourism New Zealand
  
   | Producer: Gary F. Spradling | Music: Steve Ball
  
      encoder         : Lavf55.10.100
  
      Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 6
  
  40x480, q=-1--1, 30k tbn, 29.97 tbc
  
      Metadata:
  
        handler_name    : VideoHandler
  
      Stream #0:1(eng): Audio: aac (libvo_aacenc) ([64][0][0][0] / 0x0040), 44100
  
  Hz, stereo, s16, 128 kb/s
  
      Metadata:
  
        handler_name    : SoundHandler
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (h264 -> libx264)
  
    Stream #0:1 -> #0:1 (aac -> libvo_aacenc)
  
  Press [q] to stop, [?] for help
  
  frame=   52 fps=0.0 q=29.0 size=      29kB time=00:00:01.76 bitrate= 133.9kbits/
  
  frame=   63 fps= 60 q=29.0 size=     104kB time=00:00:02.14 bitrate= 397.2kbits/
  
  frame=   74 fps= 47 q=29.0 size=     176kB time=00:00:02.51 bitrate= 573.2kbits/
  
  frame=   87 fps= 41 q=29.0 size=     265kB time=00:00:02.93 bitrate= 741.2kbits/
  
  frame=  101 fps= 37 q=29.0 size=     358kB time=00:00:03.39 bitrate= 862.8kbits/
  
  frame=  113 fps= 34 q=29.0 size=     437kB time=00:00:03.79 bitrate= 943.7kbits/
  
  frame=  125 fps= 33 q=29.0 size=     520kB time=00:00:04.20 bitrate=1012.2kbits/
  
  frame=  138 fps= 32 q=29.0 size=     606kB time=00:00:04.64 bitrate=1069.8kbits/
  
  frame=  151 fps= 31 q=29.0 size=     696kB time=00:00:05.06 bitrate=1124.3kbits/
  
  frame=  163 fps= 30 q=29.0 size=     780kB time=00:00:05.47 bitrate=1166.4kbits/
  
  frame=  176 fps= 30 q=29.0 size=     919kB time=00:00:05.90 bitrate=1273.9kbits/
  
  frame=  196 fps= 31 q=29.0 size=     994kB time=00:00:06.57 bitrate=1237.4kbits/
  
  frame=  213 fps= 31 q=29.0 size=    1097kB time=00:00:07.13 bitrate=1258.8kbits/
  
  frame=  225 fps= 30 q=29.0 size=    1204kB time=00:00:07.53 bitrate=1309.8kbits/
  
  frame=  236 fps= 30 q=29.0 size=    1323kB time=00:00:07.91 bitrate=1369.4kbits/
  
  frame=  249 fps= 29 q=29.0 size=    1451kB time=00:00:08.34 bitrate=1424.6kbits/
  
  frame=  263 fps= 29 q=29.0 size=    1574kB time=00:00:08.82 bitrate=1461.3kbits/
  
  frame=  278 fps= 29 q=29.0 size=    1610kB time=00:00:09.30 bitrate=1416.9kbits/
  
  frame=  296 fps= 30 q=29.0 size=    1655kB time=00:00:09.91 bitrate=1368.0kbits/
  
  frame=  313 fps= 30 q=29.0 size=    1697kB time=00:00:10.48 bitrate=1326.4kbits/
  
  frame=  330 fps= 30 q=29.0 size=    1737kB time=00:00:11.05 bitrate=1286.5kbits/
  
  frame=  345 fps= 30 q=29.0 size=    1776kB time=00:00:11.54 bitrate=1260.4kbits/
  
  frame=  361 fps= 30 q=29.0 size=    1813kB time=00:00:12.07 bitrate=1230.3kbits/
  
  frame=  377 fps= 30 q=29.0 size=    1847kB time=00:00:12.59 bitrate=1201.4kbits/
  
  frame=  395 fps= 30 q=29.0 size=    1880kB time=00:00:13.22 bitrate=1165.0kbits/
  
  frame=  410 fps= 30 q=29.0 size=    1993kB time=00:00:13.72 bitrate=1190.2kbits/
  
  frame=  424 fps= 30 q=29.0 size=    2080kB time=00:00:14.18 bitrate=1201.4kbits/
  
  frame=  439 fps= 30 q=29.0 size=    2166kB time=00:00:14.67 bitrate=1209.4kbits/
  
  frame=  455 fps= 30 q=29.0 size=    2262kB time=00:00:15.21 bitrate=1217.5kbits/
  
  frame=  469 fps= 30 q=29.0 size=    2341kB time=00:00:15.68 bitrate=1223.0kbits/
  
  frame=  484 fps= 30 q=29.0 size=    2430kB time=00:00:16.19 bitrate=1229.1kbits/
  
  frame=  500 fps= 30 q=29.0 size=    2523kB time=00:00:16.71 bitrate=1236.3kbits/
  
  frame=  515 fps= 30 q=29.0 size=    2607kB time=00:00:17.21 bitrate=1240.4kbits/
  
  frame=  531 fps= 30 q=29.0 size=    2681kB time=00:00:17.73 bitrate=1238.2kbits/
  
  frame=  546 fps= 30 q=29.0 size=    2758kB time=00:00:18.24 bitrate=1238.2kbits/
  
  frame=  561 fps= 30 q=29.0 size=    2824kB time=00:00:18.75 bitrate=1233.4kbits/
  
  frame=  576 fps= 30 q=29.0 size=    2955kB time=00:00:19.25 bitrate=1256.8kbits/
  
  frame=  586 fps= 29 q=29.0 size=    3061kB time=00:00:19.59 bitrate=1279.6kbits/
  
  frame=  598 fps= 29 q=29.0 size=    3217kB time=00:00:19.99 bitrate=1318.4kbits/
  
  frame=  610 fps= 29 q=29.0 size=    3354kB time=00:00:20.39 bitrate=1347.2kbits/
  
  frame=  622 fps= 29 q=29.0 size=    3483kB time=00:00:20.78 bitrate=1372.6kbits/
  
  frame=  634 fps= 29 q=29.0 size=    3593kB time=00:00:21.19 bitrate=1388.6kbits/
  
  frame=  648 fps= 29 q=29.0 size=    3708kB time=00:00:21.66 bitrate=1402.3kbits/
  
  frame=  661 fps= 29 q=29.0 size=    3811kB time=00:00:22.08 bitrate=1413.5kbits/
  
  frame=  674 fps= 29 q=29.0 size=    3978kB time=00:00:22.53 bitrate=1446.3kbits/
  
  frame=  690 fps= 29 q=29.0 size=    4133kB time=00:00:23.05 bitrate=1468.4kbits/
  
  frame=  706 fps= 29 q=29.0 size=    4263kB time=00:00:23.58 bitrate=1480.4kbits/
  
  frame=  721 fps= 29 q=29.0 size=    4391kB time=00:00:24.08 bitrate=1493.8kbits/
  
  frame=  735 fps= 29 q=29.0 size=    4524kB time=00:00:24.55 bitrate=1509.4kbits/
  
  frame=  748 fps= 29 q=29.0 size=    4661kB time=00:00:24.98 bitrate=1528.2kbits/
  
  frame=  763 fps= 29 q=29.0 size=    4835kB time=00:00:25.50 bitrate=1553.1kbits/
  
  frame=  778 fps= 29 q=29.0 size=    4993kB time=00:00:25.99 bitrate=1573.6kbits/
  
  frame=  795 fps= 29 q=29.0 size=    5149kB time=00:00:26.56 bitrate=1588.1kbits/
  
  frame=  814 fps= 29 q=29.0 size=    5258kB time=00:00:27.18 bitrate=1584.4kbits/
  
  frame=  833 fps= 29 q=29.0 size=    5368kB time=00:00:27.82 bitrate=1580.2kbits/
  
  frame=  851 fps= 29 q=29.0 size=    5469kB time=00:00:28.43 bitrate=1575.9kbits/
  
  frame=  870 fps= 29 q=29.0 size=    5567kB time=00:00:29.05 bitrate=1569.5kbits/
  
  frame=  889 fps= 29 q=29.0 size=    5688kB time=00:00:29.70 bitrate=1568.4kbits/
  
  Starting second pass: moving header on top of the file
  
  frame=  902 fps= 28 q=-1.0 Lsize=    6109kB time=00:00:30.14 bitrate=1659.8kbits
  
  /s dup=1 drop=0
  
  video:5602kB audio:472kB subtitle:0 global headers:0kB muxing overhead 0.566600%
  
  
  
  [libx264 @ 0000000004360620] frame I:8     Avg QP:20.52  size: 39667
  
  [libx264 @ 0000000004360620] frame P:419   Avg QP:25.06  size: 10524
  
  [libx264 @ 0000000004360620] frame B:475   Avg QP:29.03  size:  2123
  
  [libx264 @ 0000000004360620] consecutive B-frames:  3.2% 79.6%  0.3% 16.9%
  
  [libx264 @ 0000000004360620] mb I  I16..4: 20.7% 52.3% 26.9%
  
  [libx264 @ 0000000004360620] mb P  I16..4:  0.7%  4.2%  1.1%  P16..4: 39.4% 21.4
  
  % 13.8%  0.0%  0.0%    skip:19.3%
  
  [libx264 @ 0000000004360620] mb B  I16..4:  0.1%  0.9%  0.3%  B16..8: 41.8%  6.4
  
  %  1.7%  direct: 1.7%  skip:47.1%  L0:36.4% L1:53.3% BI:10.3%
  
  [libx264 @ 0000000004360620] 8x8 transform intra:65.7% inter:58.8%
  
  [libx264 @ 0000000004360620] coded y,uvDC,uvAC intra: 71.2% 76.6% 35.7% inter: 2
  
  0.7% 13.0% 0.5%
  
  [libx264 @ 0000000004360620] i16 v,h,dc,p: 48% 24%  8% 20%
  
  [libx264 @ 0000000004360620] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 18% 15%  6%  8%
  
  11%  8% 10%  8%
  
  [libx264 @ 0000000004360620] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 16% 15%  7% 10%
  
  11%  8%  8%  7%
  
  [libx264 @ 0000000004360620] i8c dc,h,v,p: 51% 22% 19%  9%
  
  [libx264 @ 0000000004360620] Weighted P-Frames: Y:0.7% UV:0.0%
  
  [libx264 @ 0000000004360620] ref P L0: 63.4% 19.7% 11.0%  5.9%  0.0%
  
  [libx264 @ 0000000004360620] ref B L0: 90.7%  8.7%  0.7%
  
  [libx264 @ 0000000004360620] ref B L1: 98.4%  1.6%
  
  [libx264 @ 0000000004360620] kb/s:1524.54

• Revision 450c7b57a8 : Only do metrics on cropped (visible) area of picture. The part where we align i

  10 juin 2013, par Ronald S. Bultje

  Changed Paths :
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_ssim.c

  
   Modify /vpx_scale/generic/yv12config.c

  
   Modify /vpx_scale/yv12config.h

  
  
  Only do metrics on cropped (visible) area of picture.

  The part where we align it by 8 or 16 is an implementation detail that
  shouldn't matter to the outside world.

  Change-Id : I9edd6f08b51b31c839c0ea91f767640bccb08d53

• Developing A Shader-Based Video Codec

  22 juin 2013, par Multimedia Mike — Outlandish Brainstorms

  Early last month, this thing called ORBX.js was in the news. It ostensibly has something to do with streaming video and codec technology, which naturally catches my interest. The hype was kicked off by Mozilla honcho Brendan Eich when he posted an article asserting that HD video decoding could be entirely performed in JavaScript. We’ve seen this kind of thing before using Broadway– an H.264 decoder implemented entirely in JS. But that exposes some very obvious limitations (notably CPU usage).

  But this new video codec promises 1080p HD playback directly in JavaScript which is a lofty claim. How could it possibly do this ? I got the impression that performance was achieved using WebGL, an extension which allows JavaScript access to accelerated 3D graphics hardware. Browsing through the conversations surrounding the ORBX.js announcement, I found this confirmation from Eich himself :

  You’re right that WebGL does heavy lifting.

  As of this writing, ORBX.js remains some kind of private tech demo. If there were a public demo available, it would necessarily be easy to reverse engineer the downloadable JavaScript decoder.

  But the announcement was enough to make me wonder how it could be possible to create a video codec which effectively leverages 3D hardware.

  Prior Art
  In theorizing about this, it continually occurs to me that I can’t possibly be the first person to attempt to do this (or the ORBX.js people, for that matter). In googling on the matter, I found various forums and Q&A posts where people asked if it were possible to, e.g., accelerate JPEG decoding and presentation using 3D hardware, with no answers. I also found a blog post which describes a plan to use 3D hardware to accelerate VP8 video decoding. It was a project done under the banner of Google’s Summer of Code in 2011, though I’m not sure which open source group mentored the effort. The project did not end up producing the shader-based VP8 codec originally chartered but mentions that “The ‘client side’ of the VP8 VDPAU implementation is working and is currently being reviewed by the libvdpau maintainers.” I’m not sure what that means. Perhaps it includes modifications to the public API that supports VP8, but is waiting for the underlying hardware to actually implement VP8 decoding blocks in hardware.

  What’s So Hard About This ?
  Video decoding is a computationally intensive task. GPUs are known to be really awesome at chewing through computationally intensive tasks. So why aren’t GPUs a natural fit for decoding video codecs ?

  Generally, it boils down to parallelism, or lack of opportunities thereof. GPUs are really good at doing the exact same operations over lots of data at once. The problem is that decoding compressed video usually requires multiple phases that cannot be parallelized, and the individual phases often cannot be parallelized. In strictly mathematical terms, a compressed data stream will need to be decoded by applying a function f(x) over each data element, x₀ .. x_n. However, the function relies on having applied the function to the previous data element, i.e. :

  f(xn) = f(f(xn-1))
  

  What happens when you try to parallelize such an algorithm ? Temporal rifts in the space/time continuum, if you’re in a Star Trek episode. If you’re in the real world, you’ll get incorrect, unusuable data as the parallel computation is seeded with a bunch of invalid data at multiple points (which is illustrated in some of the pictures in the aforementioned blog post about accelerated VP8).

  Example : JPEG
  Let’s take a very general look at the various stages involved in decoding the ubiquitous JPEG format :

  
  
  

  What are the opportunities to parallelize these various phases ?
  

  • Huffman decoding (run length decoding and zig-zag reordering is assumed to be rolled into this phase) : not many opportunities for parallelizing the various Huffman formats out there, including this one. Decoding most Huffman streams is necessarily a sequential operation. I once hypothesized that it would be possible to engineer a codec to achieve some parallelism during the entropy decoding phase, and later found that On2′s VP8 codec employs the scheme. However, such a scheme is unlikely to break down to such a fine level that WebGL would require.
  • Reverse DC prediction : JPEG — and many other codecs — doesn’t store full DC coefficients. It stores differences in successive DC coefficients. Reversing this process can’t be parallelized. See the discussion in the previous section.
  • Dequantize coefficients : This could be very parallelized. It should be noted that software decoders often don’t dequantize all coefficients. Many coefficients are 0 and it’s a waste of a multiplication operation to dequantize. Thus, this phase is sometimes rolled into the Huffman decoding phase.
  • Invert discrete cosine transform : This seems like it could be highly parallelizable. I will be exploring this further in this post.
  • Convert YUV -> RGB for final display : This is a well-established use case for 3D acceleration.

  Crash Course in 3D Shaders and Humility
  So I wanted to see if I could accelerate some parts of JPEG decoding using something called shaders. I made an effort to understand 3D programming and its associated math throughout the 1990s but 3D technology left me behind a very long time ago while I got mixed up in this multimedia stuff. So I plowed through a few books concerning WebGL (thanks to my new Safari Books Online subscription). After I learned enough about WebGL/JS to be dangerous and just enough about shader programming to be absolutely lethal, I set out to try my hand at optimizing IDCT using shaders.

  Here’s my extremely high level (and probably hopelessly naive) view of the modern GPU shader programming model :

  
  
  

  The WebGL program written in JavaScript drives the show. It sends a set of vertices into the WebGL system and each vertex is processed through a vertex shader. Then, each pixel that falls within a set of vertices is sent through a fragment shader to compute the final pixel attributes (R, G, B, and alpha value). Another consideration is textures : This is data that the program uploads to GPU memory which can be accessed programmatically by the shaders).

  These shaders (vertex and fragment) are key to the GPU’s programmability. How are they programmed ? Using a special C-like shading language. Thought I : “C-like language ? I know C ! I should be able to master this in short order !” So I charged forward with my assumptions and proceeded to get smacked down repeatedly by the overall programming paradigm. I came to recognize this as a variation of the scientific method : Develop a hypothesis– in my case, a mental model of how the system works ; develop an experiment (short program) to prove or disprove the model ; realize something fundamental that I was overlooking ; formulate new hypothesis and repeat.

  First Approach : Vertex Workhorse
  My first pitch goes like this :

  • Upload DCT coefficients to GPU memory in the form of textures
  • Program a vertex mesh that encapsulates 16×16 macroblocks
  • Distribute the IDCT effort among multiple vertex shaders
  • Pass transformed Y, U, and V blocks to fragment shader which will convert the samples to RGB

  So the idea is that decoding of 16×16 macroblocks is parallelized. A macroblock embodies 6 blocks :

  
  
  

  It would be nice to process one of these 6 blocks in each vertex. But that means drawing a square with 6 vertices. How do you do that ? I eventually realized that drawing a square with 6 vertices is the recommended method for drawing a square on 3D hardware. Using 2 triangles, each with 3 vertices (0, 1, 2 ; 3, 4, 5) :

  
  
  

  A vertex shader knows which (x, y) coordinates it has been assigned, so it could figure out which sections of coefficients it needs to access within the textures. But how would a vertex shader know which of the 6 blocks it should process ? Solution : Misappropriate the vertex’s z coordinate. It’s not used for anything else in this case.

  So I set all of that up. Then I hit a new roadblock : How to get the reconstructed Y, U, and V samples transported to the fragment shader ? I have found that communicating between shaders is quite difficult. Texture memory ? WebGL doesn’t allow shaders to write back to texture memory ; shaders can only read it. The standard way to communicate data from a vertex shader to a fragment shader is to declare variables as “varying”. Up until this point, I knew about varying variables but there was something I didn’t quite understand about them and it nagged at me : If 3 different executions of a vertex shader set 3 different values to a varying variable, what value is passed to the fragment shader ?

  It turns out that the varying variable varies, which means that the GPU passes interpolated values to each fragment shader invocation. This completely destroys this idea.

  Second Idea : Vertex Workhorse, Take 2
  The revised pitch is to work around the interpolation issue by just having each vertex shader invocation performs all 6 block transforms. That seems like a lot of redundant. However, I figured out that I can draw a square with only 4 vertices by arranging them in an ‘N’ pattern and asking WebGL to draw a TRIANGLE_STRIP instead of TRIANGLES. Now it’s only doing the 4x the extra work, and not 6x. GPUs are supposed to be great at this type of work, so it shouldn’t matter, right ?

  I wired up an experiment and then ran into a new problem : While I was able to transform a block (or at least pretend to), and load up a varying array (that wouldn’t vary since all vertex shaders wrote the same values) to transmit to the fragment shader, the fragment shader can’t access specific values within the varying block. To clarify, a WebGL shader can use a constant value — or a value that can be evaluated as a constant at compile time — to index into arrays ; a WebGL shader can not compute an index into an array. Per my reading, this is a WebGL security consideration and the limitation may not be present in other OpenGL(-ES) implementations.

  Not Giving Up Yet : Choking The Fragment Shader
  You might want to be sitting down for this pitch :

  • Vertex shader only interpolates texture coordinates to transmit to fragment shader
  • Fragment shader performs IDCT for a single Y sample, U sample, and V sample
  • Fragment shader converts YUV -> RGB

  Seems straightforward enough. However, that step concerning IDCT for Y, U, and V entails a gargantuan number of operations. When computing the IDCT for an entire block of samples, it’s possible to leverage a lot of redundancy in the math which equates to far fewer overall operations. If you absolutely have to compute each sample individually, for an 8×8 block, that requires 64 multiplication/accumulation (MAC) operations per sample. For 3 color planes, and including a few extra multiplications involved in the RGB conversion, that tallies up to about 200 MACs per pixel. Then there’s the fact that this approach means a 4x redundant operations on the color planes.

  It’s crazy, but I just want to see if it can be done. My approach is to pre-compute a pile of IDCT constants in the JavaScript and transmit them to the fragment shader via uniform variables. For a first order optimization, the IDCT constants are formatted as 4-element vectors. This allows computing 16 dot products rather than 64 individual multiplication/addition operations. Ideally, GPU hardware executes the dot products faster (and there is also the possibility of lining these calculations up as matrices).

  I can report that I actually got a sample correctly transformed using this approach. Just one sample, through. Then I ran into some new problems :

  Problem #1 : Computing sample #1 vs. sample #0 requires a different table of 64 IDCT constants. Okay, so create a long table of 64 * 64 IDCT constants. However, this suffers from the same problem as seen in the previous approach : I can’t dynamically compute the index into this array. What’s the alternative ? Maintain 64 separate named arrays and implement 64 branches, when branching of any kind is ill-advised in shader programming to begin with ? I started to go down this path until I ran into…

  Problem #2 : Shaders can only be so large. 64 * 64 floats (4 bytes each) requires 16 kbytes of data and this well exceeds the amount of shader storage that I can assume is allowed. That brings this path of exploration to a screeching halt.

  Further Brainstorming
  I suppose I could forgo pre-computing the constants and directly compute the IDCT for each sample which would entail lots more multiplications as well as 128 cosine calculations per sample (384 considering all 3 color planes). I’m a little stuck with the transform idea right now. Maybe there are some other transforms I could try.

  Another idea would be vector quantization. What little ORBX.js literature is available indicates that there is a method to allow real-time streaming but that it requires GPU assistance to yield enough horsepower to make it feasible. When I think of such severe asymmetry between compression and decompression, my mind drifts towards VQ algorithms. As I come to understand the benefits and limitations of GPU acceleration, I think I can envision a way that something similar to SVQ1, with its copious, hierarchical vector tables stored as textures, could be implemented using shaders.

  So far, this all pertains to intra-coded video frames. What about opportunities for inter-coded frames ? The only approach that I can envision here is to use WebGL’s readPixels() function to fetch the rasterized frame out of the GPU, and then upload it again as a new texture which a new frame processing pipeline could reference. Whether this idea is plausible would require some profiling.

  Using interframes in such a manner seems to imply that the entire codec would need to operate in RGB space and not YUV.

  Conclusions
  The people behind ORBX.js have apparently figured out a way to create a shader-based video codec. I have yet to even begin to reason out a plausible approach. However, I’m glad I did this exercise since I have finally broken through my ignorance regarding modern GPU shader programming. It’s nice to have a topic like multimedia that allows me a jumping-off point to explore other areas.