Recherche avancée

Sur d’autres sites (9041)

• VP8 : a retrospective

  13 juillet 2010, par Dark Shikari — DCT, speed, VP8

  I’ve been working the past few weeks to help finish up the ffmpeg VP8 decoder, the first community implementation of On2′s VP8 video format. Now that I’ve written a thousand or two lines of assembly code and optimized a good bit of the C code, I’d like to look back at VP8 and comment on a variety of things — both good and bad — that slipped the net the first time, along with things that have changed since the time of that blog post.

  These are less-so issues related to compression — that issue has been beaten to death, particularly in MSU’s recent comparison, where x264 beat the crap out of VP8 and the VP8 developers pulled a Pinocchio in the developer comments. But that was expected and isn’t particularly interesting, so I won’t go into that. VP8 doesn’t have to be the best in the world in order to be useful.

  When the ffmpeg VP8 decoder is complete (just a few more asm functions to go), we’ll hopefully be able to post some benchmarks comparing it to libvpx.

  1. The spec, er, I mean, bitstream guide.

  Google has reneged on their claim that a spec existed at all and renamed it a “bitstream guide”. This is probably after it was found that — not merely was it incomplete — but at least a dozen places in the spec differed wildly from what was actually in their own encoder and decoder software ! The deblocking filter, motion vector clamping, probability tables, and many more parts simply disagreed flat-out with the spec. Fortunately, Ronald Bultje, one of the main authors of the ffmpeg VP8 decoder, is rather skilled at reverse-engineering, so we were able to put together a matching implementation regardless.

  Most of the differences aren’t particularly important — they don’t have a huge effect on compression or anything — but make it vastly more difficult to implement a “working” VP8 decoder, or for that matter, decide what “working” really is. For example, Google’s decoder will, if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN. Is this a bug ? Or is this how it’s supposed to work ? It’s hard to tell — there isn’t a spec to say so. Google says that whatever libvpx does is right, but I doubt they intended this.

  I expect a spec will eventually be written, but it was a bit obnoxious of Google — both to the community and to their own developers — to release so early that they didn’t even have their own documentation ready.

  2. The TM intra prediction mode.

  One thing I glossed over in the original piece was that On2 had added an extra intra prediction mode to the standard batch that H.264 came with — they replaced Planar with “TM pred”. For i4x4, which didn’t have a Planar mode, they just added it without replacing an old one, resulting in a total of 10 modes to H.264′s 9. After understanding and writing assembly code for TM pred, I have to say that it is quite a cool idea. Here’s how it works :

  1. Let us take a block of size 4×4, 8×8, or 16×16.

  2. Define the pixels bordering the top of this block (starting from the left) as T[0], T[1], T[2]…

  3. Define the pixels bordering the left of this block (starting from the top) as L[0], L[1], L[2]…

  4. Define the pixel above the top-left of the block as TL.

  5. Predict every pixel <X,Y> in the block to be equal to clip3( T[X] + L[Y] – TL, 0, 255).

  It’s effectively a generalization of gradient prediction to the block level — predict each pixel based on the gradient between its top and left pixels, and the topleft. According to the VP8 devs, it’s chosen by the encoder quite a lot of the time, which isn’t surprising ; it seems like a pretty good idea. As just one more intra pred mode, it’s not going to do magic for compression, but it’s a cool idea and elegantly simple.

  3. Performance and the deblocking filter.
  

  On2 advertised for quite some that VP8′s goal was to be significantly faster to decode than H.264. When I saw the spec, I waited for the punchline, but apparently they were serious. There’s nothing wrong with being of similar speed or a bit slower — but I was rather confused as to the fact that their design didn’t match their stated goal at all. What apparently happened is they had multiple profiles of VP8 — high and low complexity profiles. They marketed the performance of the low complexity ones while touting the quality of the high complexity ones, a tad dishonest. More importantly though, practically nobody is using the low complexity modes, so anyone writing a decoder has to be prepared to handle the high complexity ones, which are the default.

  The primary time-eater here is the deblocking filter. VP8, being an H.264 derivative, has much the same problem as H.264 does in terms of deblocking — it spends an absurd amount of time there. As I write this post, we’re about to finish some of the deblocking filter asm code, but before it’s committed, up to 70% or more of total decoding time is spent in the deblocking filter ! Like H.264, it suffers from the 4×4 transform problem : a 4×4 transform requires a total of 8 length-16 and 8 length-8 loopfilter calls per macroblock, while Theora, with only an 8×8 transform, requires half that.

  This problem is aggravated in VP8 by the fact that the deblocking filter isn’t strength-adaptive ; if even one 4×4 block in a macroblock contains coefficients, every single edge has to be deblocked. Furthermore, the deblocking filter itself is quite complicated ; the “inner edge” filter is a bit more complex than H.264′s and the “macroblock edge” filter is vastly more complicated, having two entirely different codepaths chosen on a per-pixel basis. Of course, in SIMD, this means you have to do both and mask them together at the end.

  There’s nothing wrong with a good-but-slow deblocking filter. But given the amount of deblocking one needs to do in a 4×4-transform-based format, it might have been a better choice to make the filter simpler. It’s pretty difficult to beat H.264 on compression, but it’s certainly not hard to beat it on speed — and yet it seems VP8 missed a perfectly good chance to do so. Another option would have been to pick an 8×8 transform instead of 4×4, reducing the amount of deblocking by a factor of 2.

  And yes, there’s a simple filter available in the low complexity profile, but it doesn’t help if nobody uses it.

  4. Tree-based arithmetic coding.

  Binary arithmetic coding has become the standard entropy coding method for a wide variety of compressed formats, ranging from LZMA to VP6, H.264 and VP8. It’s simple, relatively fast compared to other arithmetic coding schemes, and easy to make adaptive. The problem with this is that you have to come up with a method for converting non-binary symbols into a list of binary symbols, and then choosing what probabilities to use to code each one. Here’s an example from H.264, the sub-partition mode symbol, which is either 8×8, 8×4, 4×8, or 4×4. encode_decision( context, bit ) writes a binary decision (bit) into a numbered context (context).

  8×8 : encode_decision( 21, 0 ) ;

  8×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 0 ) ;

  4×8 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 1 ) ;

  4×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 0 ) ;

  As can be seen, this is clearly like a Huffman tree. Wouldn’t it be nice if we could represent this in the form of an actual tree data structure instead of code ? On2 thought so — they designed a simple system in VP8 that allowed all binarization schemes in the entire format to be represented as simple tree data structures. This greatly reduces the complexity — not speed-wise, but implementation-wise — of the entropy coder. Personally, I quite like it.

  5. The inverse transform ordering.

  I should at some point write a post about common mistakes made in video formats that everyone keeps making. These are not issues that are patent worries or huge issues for compression — just stupid mistakes that are repeatedly made in new video formats, probably because someone just never asked the guy next to him “does this look stupid ?” before sticking it in the spec.

  One common mistake is the problem of transform ordering. Every sane 2D transform is “separable” — that is, it can be done by doing a 1D transform vertically and doing the 1D transform again horizontally (or vice versa). The original iDCT as used in JPEG, H.263, and MPEG-1/2/4 was an “idealized” iDCT — nobody had to use the exact same iDCT, theirs just had to give very close results to a reference implementation. This ended up resulting in a lot of practical problems. It was also slow ; the only way to get an accurate enough iDCT was to do all the intermediate math in 32-bit.

  Practically every modern format, accordingly, has specified an exact iDCT. This includes H.264, VC-1, RV40, Theora, VP8, and many more. Of course, with an exact iDCT comes an exact ordering — while the “real” iDCT can be done in any order, an exact iDCT usually requires an exact order. That is, it specifies horizontal and then vertical, or vertical and then horizontal.

  All of these transforms end up being implemented in SIMD. In SIMD, a vertical transform is generally the only option, so a transpose is added to the process instead of doing a horizontal transform. Accordingly, there are two ways to do it :

  1. Transpose, vertical transform, transpose, vertical transform.

  2. Vertical transform, transpose, vertical transform, transpose.

  These may seem to be equally good, but there’s one catch — if the transpose is done first, it can be completely eliminated by merging it into the coefficient decoding process. On many modern CPUs, particularly x86, transposes are very expensive, so eliminating one of the two gives a pretty significant speed benefit.

  H.264 did it way 1).

  VC-1 did it way 1).

  Theora (inherited from VP3) did it way 1).

  But no. VP8 has to do it way 2), where you can’t eliminate the transpose. Bah. It’s not a huge deal ; probably only 1-2% overall at most speed-wise, but it’s just a needless waste. What really bugs me is that VP3 got it right — why in the world did they screw it up this time around if they got it right beforehand ?

  RV40 is the other modern format I know that made this mistake.

  (NB : You can do transforms without a transpose, but it’s generally not worth it unless the intermediate needs 32-bit math, as in the case of the “real” iDCT.)

  6. Not supporting interlacing.

  THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU.

  Interlacing was the scourge of H.264. It weaseled its way into every nook and cranny of the spec, making every decoder a thousand lines longer. H.264 even included a highly complicated — and effective — dedicated interlaced coding scheme, MBAFF. The mere existence of MBAFF, despite its usefulness for broadcasters and others still stuck in the analog age with their 1080i, 576i , and 480i content, was a blight upon the video format.

  VP8 has once and for all avoided it.

  And if anyone suggests adding interlaced support to the experimental VP8 branch, find a straightjacket and padded cell for them before they cause any real damage.

• VP8 : a retrospective

  13 juillet 2010, par Dark Shikari — DCT, VP8, speed

  I’ve been working the past few weeks to help finish up the ffmpeg VP8 decoder, the first community implementation of On2′s VP8 video format. Now that I’ve written a thousand or two lines of assembly code and optimized a good bit of the C code, I’d like to look back at VP8 and comment on a variety of things — both good and bad — that slipped the net the first time, along with things that have changed since the time of that blog post.

  These are less-so issues related to compression — that issue has been beaten to death, particularly in MSU’s recent comparison, where x264 beat the crap out of VP8 and the VP8 developers pulled a Pinocchio in the developer comments. But that was expected and isn’t particularly interesting, so I won’t go into that. VP8 doesn’t have to be the best in the world in order to be useful.

  When the ffmpeg VP8 decoder is complete (just a few more asm functions to go), we’ll hopefully be able to post some benchmarks comparing it to libvpx.

  1. The spec, er, I mean, bitstream guide.

  Google has reneged on their claim that a spec existed at all and renamed it a “bitstream guide”. This is probably after it was found that — not merely was it incomplete — but at least a dozen places in the spec differed wildly from what was actually in their own encoder and decoder software ! The deblocking filter, motion vector clamping, probability tables, and many more parts simply disagreed flat-out with the spec. Fortunately, Ronald Bultje, one of the main authors of the ffmpeg VP8 decoder, is rather skilled at reverse-engineering, so we were able to put together a matching implementation regardless.

  Most of the differences aren’t particularly important — they don’t have a huge effect on compression or anything — but make it vastly more difficult to implement a “working” VP8 decoder, or for that matter, decide what “working” really is. For example, Google’s decoder will, if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN. Is this a bug ? Or is this how it’s supposed to work ? It’s hard to tell — there isn’t a spec to say so. Google says that whatever libvpx does is right, but I doubt they intended this.

  I expect a spec will eventually be written, but it was a bit obnoxious of Google — both to the community and to their own developers — to release so early that they didn’t even have their own documentation ready.

  2. The TM intra prediction mode.

  One thing I glossed over in the original piece was that On2 had added an extra intra prediction mode to the standard batch that H.264 came with — they replaced Planar with “TM pred”. For i4x4, which didn’t have a Planar mode, they just added it without replacing an old one, resulting in a total of 10 modes to H.264′s 9. After understanding and writing assembly code for TM pred, I have to say that it is quite a cool idea. Here’s how it works :

  1. Let us take a block of size 4×4, 8×8, or 16×16.

  2. Define the pixels bordering the top of this block (starting from the left) as T[0], T[1], T[2]…

  3. Define the pixels bordering the left of this block (starting from the top) as L[0], L[1], L[2]…

  4. Define the pixel above the top-left of the block as TL.

  5. Predict every pixel <X,Y> in the block to be equal to clip3( T[X] + L[Y] – TL, 0, 255).

  It’s effectively a generalization of gradient prediction to the block level — predict each pixel based on the gradient between its top and left pixels, and the topleft. According to the VP8 devs, it’s chosen by the encoder quite a lot of the time, which isn’t surprising ; it seems like a pretty good idea. As just one more intra pred mode, it’s not going to do magic for compression, but it’s a cool idea and elegantly simple.

  3. Performance and the deblocking filter.
  

  On2 advertised for quite some that VP8′s goal was to be significantly faster to decode than H.264. When I saw the spec, I waited for the punchline, but apparently they were serious. There’s nothing wrong with being of similar speed or a bit slower — but I was rather confused as to the fact that their design didn’t match their stated goal at all. What apparently happened is they had multiple profiles of VP8 — high and low complexity profiles. They marketed the performance of the low complexity ones while touting the quality of the high complexity ones, a tad dishonest. More importantly though, practically nobody is using the low complexity modes, so anyone writing a decoder has to be prepared to handle the high complexity ones, which are the default.

  The primary time-eater here is the deblocking filter. VP8, being an H.264 derivative, has much the same problem as H.264 does in terms of deblocking — it spends an absurd amount of time there. As I write this post, we’re about to finish some of the deblocking filter asm code, but before it’s committed, up to 70% or more of total decoding time is spent in the deblocking filter ! Like H.264, it suffers from the 4×4 transform problem : a 4×4 transform requires a total of 8 length-16 and 8 length-8 loopfilter calls per macroblock, while Theora, with only an 8×8 transform, requires half that.

  This problem is aggravated in VP8 by the fact that the deblocking filter isn’t strength-adaptive ; if even one 4×4 block in a macroblock contains coefficients, every single edge has to be deblocked. Furthermore, the deblocking filter itself is quite complicated ; the “inner edge” filter is a bit more complex than H.264′s and the “macroblock edge” filter is vastly more complicated, having two entirely different codepaths chosen on a per-pixel basis. Of course, in SIMD, this means you have to do both and mask them together at the end.

  There’s nothing wrong with a good-but-slow deblocking filter. But given the amount of deblocking one needs to do in a 4×4-transform-based format, it might have been a better choice to make the filter simpler. It’s pretty difficult to beat H.264 on compression, but it’s certainly not hard to beat it on speed — and yet it seems VP8 missed a perfectly good chance to do so. Another option would have been to pick an 8×8 transform instead of 4×4, reducing the amount of deblocking by a factor of 2.

  And yes, there’s a simple filter available in the low complexity profile, but it doesn’t help if nobody uses it.

  4. Tree-based arithmetic coding.

  Binary arithmetic coding has become the standard entropy coding method for a wide variety of compressed formats, ranging from LZMA to VP6, H.264 and VP8. It’s simple, relatively fast compared to other arithmetic coding schemes, and easy to make adaptive. The problem with this is that you have to come up with a method for converting non-binary symbols into a list of binary symbols, and then choosing what probabilities to use to code each one. Here’s an example from H.264, the sub-partition mode symbol, which is either 8×8, 8×4, 4×8, or 4×4. encode_decision( context, bit ) writes a binary decision (bit) into a numbered context (context).

  8×8 : encode_decision( 21, 0 ) ;

  8×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 0 ) ;

  4×8 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 1 ) ;

  4×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 0 ) ;

  As can be seen, this is clearly like a Huffman tree. Wouldn’t it be nice if we could represent this in the form of an actual tree data structure instead of code ? On2 thought so — they designed a simple system in VP8 that allowed all binarization schemes in the entire format to be represented as simple tree data structures. This greatly reduces the complexity — not speed-wise, but implementation-wise — of the entropy coder. Personally, I quite like it.

  5. The inverse transform ordering.

  I should at some point write a post about common mistakes made in video formats that everyone keeps making. These are not issues that are patent worries or huge issues for compression — just stupid mistakes that are repeatedly made in new video formats, probably because someone just never asked the guy next to him “does this look stupid ?” before sticking it in the spec.

  One common mistake is the problem of transform ordering. Every sane 2D transform is “separable” — that is, it can be done by doing a 1D transform vertically and doing the 1D transform again horizontally (or vice versa). The original iDCT as used in JPEG, H.263, and MPEG-1/2/4 was an “idealized” iDCT — nobody had to use the exact same iDCT, theirs just had to give very close results to a reference implementation. This ended up resulting in a lot of practical problems. It was also slow ; the only way to get an accurate enough iDCT was to do all the intermediate math in 32-bit.

  Practically every modern format, accordingly, has specified an exact iDCT. This includes H.264, VC-1, RV40, Theora, VP8, and many more. Of course, with an exact iDCT comes an exact ordering — while the “real” iDCT can be done in any order, an exact iDCT usually requires an exact order. That is, it specifies horizontal and then vertical, or vertical and then horizontal.

  All of these transforms end up being implemented in SIMD. In SIMD, a vertical transform is generally the only option, so a transpose is added to the process instead of doing a horizontal transform. Accordingly, there are two ways to do it :

  1. Transpose, vertical transform, transpose, vertical transform.

  2. Vertical transform, transpose, vertical transform, transpose.

  These may seem to be equally good, but there’s one catch — if the transpose is done first, it can be completely eliminated by merging it into the coefficient decoding process. On many modern CPUs, particularly x86, transposes are very expensive, so eliminating one of the two gives a pretty significant speed benefit.

  H.264 did it way 1).

  VC-1 did it way 1).

  Theora (inherited from VP3) did it way 1).

  But no. VP8 has to do it way 2), where you can’t eliminate the transpose. Bah. It’s not a huge deal ; probably only 1-2% overall at most speed-wise, but it’s just a needless waste. What really bugs me is that VP3 got it right — why in the world did they screw it up this time around if they got it right beforehand ?

  RV40 is the other modern format I know that made this mistake.

  (NB : You can do transforms without a transpose, but it’s generally not worth it unless the intermediate needs 32-bit math, as in the case of the “real” iDCT.)

  6. Not supporting interlacing.

  THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU.

  Interlacing was the scourge of H.264. It weaseled its way into every nook and cranny of the spec, making every decoder a thousand lines longer. H.264 even included a highly complicated — and effective — dedicated interlaced coding scheme, MBAFF. The mere existence of MBAFF, despite its usefulness for broadcasters and others still stuck in the analog age with their 1080i, 576i , and 480i content, was a blight upon the video format.

  VP8 has once and for all avoided it.

  And if anyone suggests adding interlaced support to the experimental VP8 branch, find a straightjacket and padded cell for them before they cause any real damage.

• ffmpeg converting .vob to .mp4 --- colors are washed out

  28 mai 2021, par Blattla

  I am very new to ffmpeg. Currently I am trying to convert old family movies from vob to mp4.&#xA;After getting some help I used this command :

  &#xA;

  ffmpeg -i 1998.vob -codec:v libx264 -crf 17 -pix_fmt yuv420p -codec:a aac -movflags +faststart 1998.mp4


  &#xA;

  Two things that still bug me. The output is almost 20% larger than the input and the colors are washed out. Although the movies are old and of low quality (grainy, rather flat colors, ...) the colors in the output movie are less intense than in the original one. Larger file size would be ok for me but do you have any idea which part of my command might cause the color issue ?

  &#xA;

  ffmpeg version 4.4 Copyright (c) 2000-2021 the FFmpeg developers
  built with Apple clang version 12.0.0 (clang-1200.0.32.29)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/4.4_1 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox
  libavutil      56. 70.100 / 56. 70.100
  libavcodec     58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter     7.110.100 /  7.110.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
Input #0, mpeg, from '1995.vob':
  Duration: 00:00:14.64, start: 0.232178, bitrate: 1676252 kb/s
  Stream #0:0[0x1bf]: Data: dvd_nav_packet
  Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Side data:
      cpb: bitrate max/min/avg: 9548800/0/0 buffer size: 1835008 vbv_delay: N/A
  Stream #0:2[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s
File '999.mp4' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:1 -> #0:0 (mpeg2video (native) -> h264 (libx264))
  Stream #0:2 -> #0:1 (ac3 (native) -> aac (native))
Press [q] to stop, [?] for help
[libx264 @ 0x7ff666814400] using SAR=12/11
[libx264 @ 0x7ff666814400] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x7ff666814400] profile High, level 3.0, 4:2:0, 8-bit
[libx264 @ 0x7ff666814400] 264 - core 161 r3049 55d517b - H.264/MPEG-4 AVC codec - Copyleft 2003-2021 - http://www.videolan.org/x264.html - options: cabac=1 ref=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_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=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=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=17.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to '999.mp4':
  Metadata:
    encoder         : Lavf58.76.100
  Stream #0:0: Video: h264 (avc1 / 0x31637661), yuv420p(tv, bt470bg, top coded first (swapped)), 704x576 [SAR 12:11 DAR 4:3], q=2-31, 25 fps, 12800 tbn
    Metadata:
      encoder         : Lavc58.134.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
  Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
    Metadata:
      encoder         : Lavc58.134.100 aac
frame=    1 fps=0.0 q=0.0 size=       0kB time=00:00:00.00 bitrate=N/A speed=   frame=   59 fps=0.0 q=22.0 size=     256kB time=00:00:02.04 bitrate=1024.2kbits/frame=   75 fps= 72 q=22.0 size=    1024kB time=00:00:02.68 bitrate=3120.9kbits/frame=   95 fps= 61 q=22.0 size=    2048kB time=00:00:03.45 bitrate=4854.6kbits/frame=  112 fps= 54 q=22.0 size=    2816kB time=00:00:04.18 bitrate=5517.2kbits/frame=  131 fps= 51 q=22.0 size=    4096kB time=00:00:04.92 bitrate=6809.0kbits/frame=  149 fps= 48 q=22.0 size=    4864kB time=00:00:05.65 bitrate=7048.3kbits/frame=  169 fps= 47 q=22.0 size=    6144kB time=00:00:06.42 bitrate=7838.3kbits/frame=  183 fps= 44 q=22.0 size=    6912kB time=00:00:07.04 bitrate=8043.1kbits/frame=  203 fps= 43 q=22.0 size=    7936kB time=00:00:07.80 bitrate=8326.3kbits/frame=  221 fps= 42 q=22.0 size=    8960kB time=00:00:08.51 bitrate=8623.2kbits/frame=  240 fps= 42 q=22.0 size=    9984kB time=00:00:09.28 bitrate=8813.5kbits/frame=  261 fps= 41 q=22.0 size=   11264kB time=00:00:10.06 bitrate=9164.0kbits/frame=  278 fps= 40 q=22.0 size=   12288kB time=00:00:10.81 bitrate=9306.9kbits/frame=  294 fps= 40 q=22.0 size=   13568kB time=00:00:11.45 bitrate=9702.3kbits/frame=  311 fps= 39 q=22.0 size=   14592kB time=00:00:12.09 bitrate=9882.4kbits/frame=  329 fps= 39 q=22.0 size=   15616kB time=00:00:12.86 bitrate=9944.5kbits/frame=  347 fps= 39 q=22.0 size=   16640kB time=00:00:13.56 bitrate=10046.8kbitsframe=  366 fps= 38 q=22.0 size=   17920kB time=00:00:14.33 bitrate=10240.0kbitsframe=  385 fps= 38 q=22.0 size=   19200kB time=00:00:15.12 bitrate=10398.9kbitsframe=  400 fps= 38 q=22.0 size=   20224kB time=00:00:15.63 bitrate=10594.9kbitsframe=  418 fps= 38 q=22.0 size=   21504kB time=00:00:16.34 bitrate=10780.1kbitsframe=  431 fps= 37 q=22.0 size=   22528kB time=00:00:16.89 bitrate=10922.7kbitsframe=  447 fps= 37 q=22.0 size=   23808kB time=00:00:17.53 bitrate=11122.0kbitsframe=  466 fps= 37 q=22.0 size=   25088kB time=00:00:18.26 bitrate=11254.5kbitsframe=  479 fps= 36 q=22.0 size=   25856kB time=00:00:18.81 bitrate=11257.1kbitsframe=  497 fps= 36 q=22.0 size=   27136kB time=00:00:19.54 bitrate=11375.8kbitsframe=  513 fps= 36 q=22.0 size=   28416kB time=00:00:20.16 bitrate=11546.8kbitsframe=  530 fps= 36 q=22.0 size=   29440kB time=00:00:20.92 bitrate=11523.9kbitsframe=  546 fps= 36 q=22.0 size=   30464kB time=00:00:21.56 bitrate=11570.9kbitsframe=  564 fps= 36 q=22.0 size=   31744kB time=00:00:22.10 bitrate=11766.1kbitsframe=  580 fps= 36 q=19.0 size=   32512kB time=00:00:22.80 bitrate=11678.8kbitsframe=  598 fps= 36 q=22.0 size=   33792kB time=00:00:23.57 bitrate=11743.1kbitsframe=  614 fps= 35 q=22.0 size=   34560kB time=00:00:24.25 bitrate=11672.0kbitsframe=  630 fps= 35 q=22.0 size=   35328kB time=00:00:24.85 bitrate=11644.6kbitsframe=  646 fps= 35 q=22.0 size=   36096kB time=00:00:25.42 bitrate=11628.3kbitsframe=  662 fps= 35 q=22.0 size=   37376kB time=00:00:26.17 bitrate=11697.1kbitsframe=  682 fps= 35 q=22.0 size=   38400kB time=00:00:26.90 bitrate=11693.6kbitsframe=  699 fps= 35 q=22.0 size=   39424kB time=00:00:27.66 bitrate=11672.2kbitsframe=  719 fps= 35 q=22.0 size=   40704kB time=00:00:28.41 bitrate=11734.5kbitsframe=  736 fps= 35 q=22.0 size=   41728kB time=00:00:29.14 bitrate=11730.3kbitsframe=  753 fps= 35 q=22.0 size=   42752kB time=00:00:29.71 bitrate=11785.2kbitsframe=  764 fps= 35 q=22.0 size=   43520kB time=00:00:30.20 bitrate=11802.0kbitsframe=  776 fps= 35 q=22.0 size=   44544kB time=00:00:30.72 bitrate=11878.4kbitsframe=  786 fps= 34 q=22.0 size=   45312kB time=00:00:31.06 bitrate=11950.4kbitsframe=  799 fps= 34 q=22.0 size=   46080kB time=00:00:31.57 bitrate=11955.9kbitsframe=  815 fps= 34 q=22.0 size=   47104kB time=00:00:32.14 bitrate=12002.6kbitsframe=  830 fps= 34 q=22.0 size=   48128kB time=00:00:32.78 bitrate=12024.2kbitsframe=  839 fps= 33 q=22.0 size=   48640kB time=00:00:33.15 bitrate=12019.2kbitsframe=  847 fps= 33 q=22.0 size=   49152kB time=00:00:33.49 bitrate=12021.9kbitsframe=  858 fps= 33 q=22.0 size=   49920kB time=00:00:33.98 bitrate=12033.5kbitsframe=  867 fps= 32 q=22.0 size=   50688kB time=00:00:34.30 bitrate=12104.6kbitsframe=  880 fps= 32 q=22.0 size=   51456kB time=00:00:34.88 bitrate=12085.1kbitsframe=  898 fps= 32 q=22.0 size=   52480kB time=00:00:35.54 bitrate=12096.2kbitsframe=  913 fps= 32 q=22.0 size=   53504kB time=00:00:36.18 bitrate=12114.1kbitsframe=  923 fps= 32 q=22.0 size=   54016kB time=00:00:36.54 bitrate=12108.7kbitsframe=  940 fps= 32 q=22.0 size=   55040kB time=00:00:37.20 bitrate=12118.9kbitsframe=  958 fps= 32 q=22.0 size=   55808kB time=00:00:37.90 bitrate=12059.8kbitsframe=  975 fps= 32 q=22.0 size=   56832kB time=00:00:38.61 bitrate=12057.2kbitsframe=  994 fps= 32 q=22.0 size=   58112kB time=00:00:39.38 bitrate=12088.3kbitsframe= 1012 fps= 32 q=22.0 size=   59136kB time=00:00:40.02 bitrate=12104.6kbitsframe= 1026 fps= 32 q=22.0 size=   59904kB time=00:00:40.64 bitrate=12075.1kbitsframe= 1038 fps= 31 q=22.0 size=   60928kB time=00:00:41.21 bitrate=12109.9kbitsframe= 1046 fps= 31 q=22.0 size=   61440kB time=00:00:41.53 bitrate=12117.6kbitsframe= 1057 fps= 31 q=22.0 size=   61952kB time=00:00:41.87 bitrate=12119.0kbitsframe= 1071 fps= 31 q=22.0 size=   62976kB time=00:00:42.45 bitrate=12152.2kbitsframe= 1083 fps= 31 q=22.0 size=   63488kB time=00:00:42.90 bitrate=12123.0kbitsframe= 1096 fps= 31 q=22.0 size=   64256kB time=00:00:43.41 bitrate=12125.0kbitsframe= 1110 fps= 31 q=22.0 size=   65280kB time=00:00:44.09 bitrate=12127.5kbitsframe= 1126 fps= 31 q=22.0 size=   66048kB time=00:00:44.62 bitrate=12123.5kbitsframe= 1131 fps= 30 q=19.0 size=   66560kB time=00:00:44.86 bitrate=12153.6kbitsframe= 1147 fps= 30 q=22.0 size=   67584kB time=00:00:45.46 bitrate=12178.4kbitsframe= 1155 fps= 30 q=22.0 size=   68096kB time=00:00:45.88 bitrate=12156.6kbitsframe= 1167 fps= 30 q=22.0 size=   68864kB time=00:00:46.33 bitrate=12174.9kbitsframe= 1175 fps= 30 q=22.0 size=   69376kB time=00:00:46.59 bitrate=12198.0kbitsframe= 1184 fps= 30 q=22.0 size=   70144kB time=00:00:46.93 bitrate=12243.3kbitsframe= 1196 fps= 30 q=22.0 size=   70912kB time=00:00:47.44 bitrate=12243.8kbitsframe= 1211 fps= 30 q=22.0 size=   71936kB time=00:00:48.06 bitrate=12260.7kbitsframe= 1226 fps= 30 q=22.0 size=   73216kB time=00:00:48.66 bitrate=12325.7kbitsframe= 1240 fps= 29 q=22.0 size=   73984kB time=00:00:49.17 bitrate=12325.3kbitsframe= 1256 fps= 29 q=22.0 size=   75264kB time=00:00:49.85 bitrate=12366.9kbitsframe= 1271 fps= 29 q=22.0 size=   76032kB time=00:00:50.43 bitrate=12350.4kbitsframe= 1280 fps= 29 q=22.0 size=   76800kB time=00:00:50.81 bitrate=12380.9kbitsframe= 1288 fps= 29 q=22.0 size=   77312kB time=00:00:51.13 bitrate=12385.4kbitsframe= 1295 fps= 29 q=22.0 size=   77824kB time=00:00:51.39 bitrate=12405.3kbitsframe= 1303 fps= 29 q=22.0 size=   78080kB time=00:00:51.73 bitrate=12364.0kbitsframe= 1316 fps= 29 q=22.0 size=   78848kB time=00:00:52.28 bitrate=12353.2kbitsframe= 1331 fps= 29 q=22.0 size=   79872kB time=00:00:52.86 bitrate=12377.3kbitsframe= 1349 fps= 29 q=22.0 size=   80896kB time=00:00:53.56 bitrate=12371.2kbitsframe= 1364 fps= 29 q=22.0 size=   81920kB time=00:00:54.14 bitrate=12394.5kbitsframe= 1379 fps= 29 q=22.0 size=   82944kB time=00:00:54.74 bitrate=12412.5kbitsframe= 1396 fps= 29 q=22.0 size=   83968kB time=00:00:55.38 bitrate=12420.5kbitsframe= 1417 fps= 29 q=22.0 size=   84992kB time=00:00:56.27 bitrate=12371.9kbitsframe= 1438 fps= 29 q=22.0 size=   86016kB time=00:00:57.10 bitrate=12338.5kbitsframe= 1458 fps= 29 q=22.0 size=   87040kB time=00:00:57.92 bitrate=12310.6kbitsframe= 1478 fps= 29 q=22.0 size=   88064kB time=00:00:58.64 bitrate=12301.4kbitsframe= 1498 fps= 29 q=22.0 size=   89088kB time=00:00:59.47 bitrate=12270.4kbits[mp4 @ 0x7ff666813200] Starting second pass: moving the moov atom to the beginning of the file
frame= 1500 fps= 28 q=-1.0 Lsize=   91853kB time=00:00:59.98 bitrate=12543.2kbits/s speed=1.13x    
video:90866kB audio:941kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.049858%
[libx264 @ 0x7ff666814400] frame I:12    Avg QP:18.57  size:116766
[libx264 @ 0x7ff666814400] frame P:426   Avg QP:20.52  size: 87768
[libx264 @ 0x7ff666814400] frame B:1062  Avg QP:23.56  size: 51088
[libx264 @ 0x7ff666814400] consecutive B-frames:  2.5%  6.4%  9.0% 82.1%
[libx264 @ 0x7ff666814400] mb I  I16..4:  1.0% 87.7% 11.3%
[libx264 @ 0x7ff666814400] mb P  I16..4:  0.5% 23.0%  4.2%  P16..4: 25.2% 30.8% 16.1%  0.0%  0.0%    skip: 0.1%
[libx264 @ 0x7ff666814400] mb B  I16..4:  0.1%  1.3%  0.6%  B16..8: 37.5% 21.2%  9.4%  direct:28.6%  skip: 1.4%  L0:31.5% L1:22.8% BI:45.8%
[libx264 @ 0x7ff666814400] 8x8 transform intra:80.8% inter:75.0%
[libx264 @ 0x7ff666814400] coded y,uvDC,uvAC intra: 97.5% 95.0% 63.3% inter: 90.0% 62.4% 12.3%
[libx264 @ 0x7ff666814400] i16 v,h,dc,p: 36% 46%  6% 12%
[libx264 @ 0x7ff666814400] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 16% 25%  5%  6%  7%  7%  8% 12%
[libx264 @ 0x7ff666814400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 29% 12%  6%  7%  6% 10%  7% 13%
[libx264 @ 0x7ff666814400] i8c dc,h,v,p: 36% 30% 20% 14%
[libx264 @ 0x7ff666814400] Weighted P-Frames: Y:29.3% UV:14.1%
[libx264 @ 0x7ff666814400] ref P L0: 39.8% 15.4% 21.2% 19.9%  3.8%
[libx264 @ 0x7ff666814400] ref B L0: 76.4% 19.1%  4.5%
[libx264 @ 0x7ff666814400] ref B L1: 90.7%  9.3%
[libx264 @ 0x7ff666814400] kb/s:12406.19
[aac @ 0x7ff666815c00] Qavg: 181.322


  &#xA;