Recherche avancée

Sur d’autres sites (3842)

• WebVTT as a W3C Recommendation

  1er janvier 2014, par silvia

  Three weeks ago I attended TPAC, the annual meeting of W3C Working Groups. One of the meetings was of the Timed Text Working Group (TT-WG), that has been specifying TTML, the Timed Text Markup Language. It is now proposed that WebVTT be also standardised through the same Working Group.

  How did that happen, you may ask, in particular since WebVTT and TTML have in the past been portrayed as rival caption formats ? How will the WebVTT spec that is currently under development in the Text Track Community Group (TT-CG) move through a Working Group process ?

  I’ll explain first why there is a need for WebVTT to become a W3C Recommendation, and then how this is proposed to be part of the Timed Text Working Group deliverables, and finally how I can see this working between the TT-CG and the TT-WG.

  Advantages of a W3C Recommendation

  TTML is a XML-based markup format for captions developed during the time that XML was all the hotness. It has become a W3C standard (a so-called “Recommendation”) despite not having been implemented in any browsers (if you ask me : that’s actually a flaw of the W3C standardisation process : it requires only two interoperable implementations of any kind – and that could be anyone’s JavaScript library or Flash demonstrator – it doesn’t actually require browser implementations. But I digress…). To be fair, a subpart of TTML is by now implemented in Internet Explorer, but all the other major browsers have thus far rejected proposals of implementation.

  Because of its Recommendation status, TTML has become the basis for several other caption standards that other SDOs have picked : the SMPTE’s SMPTE-TT format, the EBU’s EBU-TT format, and the DASH Industry Forum’s use of SMPTE-TT. SMPTE-TT has also become the “safe harbour” format for the US legislation on captioning as decided by the FCC. (Note that the FCC requirements for captions on the Web are actually based on a list of features rather than requiring a specific format. But that will be the topic of a different blog post…)

  WebVTT is much younger than TTML. TTML was developed as an interchange format among caption authoring systems. WebVTT was built for rendering in Web browsers and with HTML5 in mind. It meets the requirements of the <track> element and supports more than just captions/subtitles. WebVTT is popular with browser developers and has already been implemented in all major browsers (Firefox Nightly is the last to implement it – all others have support already released).

  As we can see and as has been proven by the HTML spec and multiple other specs : browsers don’t wait for specifications to have W3C Recommendation status before they implement them. Nor do they really care about the status of a spec – what they care about is whether a spec makes sense for the Web developer and user communities and whether it fits in the Web platform. WebVTT has obviously achieved this status, even with an evolving spec. (Note that the spec tries very hard not to break backwards compatibility, thus all past implementations will at least be compatible with the more basic features of the spec.)

  Given that Web browsers don’t need WebVTT to become a W3C standard, why then should we spend effort in moving the spec through the W3C process to become a W3C Recommendation ?

  The modern Web is now much bigger than just Web browsers. Web specifications are being used in all kinds of devices including TV set-top boxes, phone and tablet apps, and even unexpected devices such as white goods. Videos are increasingly omnipresent thus exposing deaf and hard-of-hearing users to ever-growing challenges in interacting with content on diverse devices. Some of these devices will not use auto-updating software but fixed versions so can’t easily adapt to new features. Thus, caption producers (both commercial and community) need to be able to author captions (and other video accessibility content as defined by the HTML5 element) towards a feature set that is clearly defined to be supported by such non-updating devices.

  Understandably, device vendors in this space have a need to build their technology on standardised specifications. SDOs for such device technologies like to reference fixed specifications so the feature set is not continually updating. To reference WebVTT, they could use a snapshot of the specification at any time and reference that, but that’s not how SDOs work. They prefer referencing an officially sanctioned and tested version of a specification – for a W3C specification that means creating a W3C Recommendation of the WebVTT spec.

  Taking WebVTT on a W3C recommendation track is actually advantageous for browsers, too, because a test suite will have to be developed that proves that features are implemented in an interoperable manner. In summary, I can see the advantages and personally support the effort to take WebVTT through to a W3C Recommendation.

  Choice of Working Group

  FAIK this is the first time that a specification developed in a Community Group is being moved into the recommendation track. This is something that has been expected when the W3C created CGs, but not something that has an established process yet.

  The first question of course is which WG would take it through to Recommendation ? Would we create a new Working Group or find an existing one to move the specification through ? Since WGs involve a lot of overhead, the preference was to add WebVTT to the charter of an existing WG. The two obvious candidates were the HTML WG and the TT-WG – the first because it’s where WebVTT originated and the latter because it’s the closest thematically.

  Adding a deliverable to a WG is a major undertaking. The TT-WG is currently in the process of re-chartering and thus a suggestion was made to add WebVTT to the milestones of this WG. TBH that was not my first choice. Since I’m already an editor in the HTML WG and WebVTT is very closely related to HTML and can be tested extensively as part of HTML, I preferred the HTML WG. However, adding WebVTT to the TT-WG has some advantages, too.

  Since TTML is an exchange format, lots of captions that will be created (at least professionally) will be in TTML and TTML-related formats. It makes sense to create a mapping from TTML to WebVTT for rendering in browsers. The expertise of both, TTML and WebVTT experts is required to develop a good mapping – as has been shown when we developed the mapping from CEA608/708 to WebVTT. Also, captioning experts are already in the TT-WG, so it helps to get a second set of eyes onto WebVTT.

  A disadvantage of moving a specification out of a CG into a WG is, however, that you potentially lose a lot of the expertise that is already involved in the development of the spec. People don’t easily re-subscribe to additional mailing lists or want the additional complexity of involving another community (see e.g. this email).

  So, a good process needs to be developed to allow everyone to contribute to the spec in the best way possible without requiring duplicate work. How can we do that ?

  The forthcoming process

  At TPAC the TT-WG discussed for several hours what the next steps are in taking WebVTT through the TT-WG to recommendation status (agenda with slides). I won’t bore you with the different views – if you are keen, you can read the minutes.

  What I came away with is the following process :

  1. Fix a few more bugs in the CG until we’re happy with the feature set in the CG. This should match the feature set that we realistically expect devices to implement for a first version of the WebVTT spec.
  2. Make a FSA (Final Specification Agreement) in the CG to create a stable reference and a clean IPR position.
  3. Assuming that the TT-WG’s charter has been approved with WebVTT as a milestone, we would next bring the FSA specification into the TT-WG as FPWD (First Public Working Draft) and immediately do a Last Call which effectively freezes the feature set (this is possible because there has already been wide community review of the WebVTT spec) ; in parallel, the CG can continue to develop the next version of the WebVTT spec with new features (just like it is happening with the HTML5 and HTML5.1 specifications).
  4. Develop a test suite and address any issues in the Last Call document (of course, also fix these issues in the CG version of the spec).
  5. As per W3C process, substantive and minor changes to Last Call documents have to be reported and raised issues addressed before the spec can progress to the next level : Candidate Recommendation status.
  6. For the next step – Proposed Recommendation status – an implementation report is necessary, and thus the test suite needs to be finalized for the given feature set. The feature set may also be reduced at this stage to just the ones implemented interoperably, leaving any other features for the next version of the spec.
  7. The final step is Recommendation status, which simply requires sufficient support and endorsement by W3C members.

  The first version of the WebVTT spec naturally has a focus on captioning (and subtitling), since this has been the dominant use case that we have focused on this far and it’s the part that is the most compatibly implemented feature set of WebVTT in browsers. It’s my expectation that the next version of WebVTT will have a lot more features related to audio descriptions, chapters and metadata. Thus, this seems a good time for a first version feature freeze.

  There are still several obstacles towards progressing WebVTT as a milestone of the TT-WG. Apart from the need to get buy-in from the TT-WG, the TT-CG, and the AC (Adivisory Committee who have to approve the new charter), we’re also looking at the license of the specification document.

  The CG specification has an open license that allows creating derivative work as long as there is attribution, while the W3C document license for documents on the recommendation track does not allow the creation of derivative work unless given explicit exceptions. This is an issue that is currently being discussed in the W3C with a proposal for a CC-BY license on the Recommendation track. However, my view is that it’s probably ok to use the different document licenses : the TT-WG will work on WebVTT 1.0 and give it a W3C document license, while the CG starts working on the next WebVTT version under the open CG license. It probably actually makes sense to have a less open license on a frozen spec.

  Making the best of a complicated world

  WebVTT is now proposed as part of the recharter of the TT-WG. I have no idea how complicated the process will become to achieve a W3C WebVTT 1.0 Recommendation, but I am hoping that what is outlined above will be workable in such a way that all of us get to focus on progressing the technology.

  At TPAC I got the impression that the TT-WG is committed to progressing WebVTT to Recommendation status. I know that the TT-CG is committed to continue developing WebVTT to its full potential for all kinds of media-time aligned content with new kinds already discussed at FOMS. Let’s enable both groups to achieve their goals. As a consequence, we will allow the two formats to excel where they do : TTML as an interchange format and WebVTT as a browser rendering format.

• WebVTT as a W3C Recommendation

  2 décembre 2013, par silvia

  Three weeks ago I attended TPAC, the annual meeting of W3C Working Groups. One of the meetings was of the Timed Text Working Group (TT-WG), that has been specifying TTML, the Timed Text Markup Language. It is now proposed that WebVTT be also standardised through the same Working Group.

  How did that happen, you may ask, in particular since WebVTT and TTML have in the past been portrayed as rival caption formats ? How will the WebVTT spec that is currently under development in the Text Track Community Group (TT-CG) move through a Working Group process ?

  I’ll explain first why there is a need for WebVTT to become a W3C Recommendation, and then how this is proposed to be part of the Timed Text Working Group deliverables, and finally how I can see this working between the TT-CG and the TT-WG.

  Advantages of a W3C Recommendation

  TTML is a XML-based markup format for captions developed during the time that XML was all the hotness. It has become a W3C standard (a so-called “Recommendation”) despite not having been implemented in any browsers (if you ask me : that’s actually a flaw of the W3C standardisation process : it requires only two interoperable implementations of any kind – and that could be anyone’s JavaScript library or Flash demonstrator – it doesn’t actually require browser implementations. But I digress…). To be fair, a subpart of TTML is by now implemented in Internet Explorer, but all the other major browsers have thus far rejected proposals of implementation.

  Because of its Recommendation status, TTML has become the basis for several other caption standards that other SDOs have picked : the SMPTE’s SMPTE-TT format, the EBU’s EBU-TT format, and the DASH Industry Forum’s use of SMPTE-TT. SMPTE-TT has also become the “safe harbour” format for the US legislation on captioning as decided by the FCC. (Note that the FCC requirements for captions on the Web are actually based on a list of features rather than requiring a specific format. But that will be the topic of a different blog post…)

  WebVTT is much younger than TTML. TTML was developed as an interchange format among caption authoring systems. WebVTT was built for rendering in Web browsers and with HTML5 in mind. It meets the requirements of the <track> element and supports more than just captions/subtitles. WebVTT is popular with browser developers and has already been implemented in all major browsers (Firefox Nightly is the last to implement it – all others have support already released).

  As we can see and as has been proven by the HTML spec and multiple other specs : browsers don’t wait for specifications to have W3C Recommendation status before they implement them. Nor do they really care about the status of a spec – what they care about is whether a spec makes sense for the Web developer and user communities and whether it fits in the Web platform. WebVTT has obviously achieved this status, even with an evolving spec. (Note that the spec tries very hard not to break backwards compatibility, thus all past implementations will at least be compatible with the more basic features of the spec.)

  Given that Web browsers don’t need WebVTT to become a W3C standard, why then should we spend effort in moving the spec through the W3C process to become a W3C Recommendation ?

  The modern Web is now much bigger than just Web browsers. Web specifications are being used in all kinds of devices including TV set-top boxes, phone and tablet apps, and even unexpected devices such as white goods. Videos are increasingly omnipresent thus exposing deaf and hard-of-hearing users to ever-growing challenges in interacting with content on diverse devices. Some of these devices will not use auto-updating software but fixed versions so can’t easily adapt to new features. Thus, caption producers (both commercial and community) need to be able to author captions (and other video accessibility content as defined by the HTML5
  element) towards a feature set that is clearly defined to be supported by such non-updating devices.

  Understandably, device vendors in this space have a need to build their technology on standardised specifications. SDOs for such device technologies like to reference fixed specifications so the feature set is not continually updating. To reference WebVTT, they could use a snapshot of the specification at any time and reference that, but that’s not how SDOs work. They prefer referencing an officially sanctioned and tested version of a specification – for a W3C specification that means creating a W3C Recommendation of the WebVTT spec.

  Taking WebVTT on a W3C recommendation track is actually advantageous for browsers, too, because a test suite will have to be developed that proves that features are implemented in an interoperable manner. In summary, I can see the advantages and personally support the effort to take WebVTT through to a W3C Recommendation.

  Choice of Working Group

  FAIK this is the first time that a specification developed in a Community Group is being moved into the recommendation track. This is something that has been expected when the W3C created CGs, but not something that has an established process yet.

  The first question of course is which WG would take it through to Recommendation ? Would we create a new Working Group or find an existing one to move the specification through ? Since WGs involve a lot of overhead, the preference was to add WebVTT to the charter of an existing WG. The two obvious candidates were the HTML WG and the TT-WG – the first because it’s where WebVTT originated and the latter because it’s the closest thematically.

  Adding a deliverable to a WG is a major undertaking. The TT-WG is currently in the process of re-chartering and thus a suggestion was made to add WebVTT to the milestones of this WG. TBH that was not my first choice. Since I’m already an editor in the HTML WG and WebVTT is very closely related to HTML and can be tested extensively as part of HTML, I preferred the HTML WG. However, adding WebVTT to the TT-WG has some advantages, too.

  Since TTML is an exchange format, lots of captions that will be created (at least professionally) will be in TTML and TTML-related formats. It makes sense to create a mapping from TTML to WebVTT for rendering in browsers. The expertise of both, TTML and WebVTT experts is required to develop a good mapping – as has been shown when we developed the mapping from CEA608/708 to WebVTT. Also, captioning experts are already in the TT-WG, so it helps to get a second set of eyes onto WebVTT.

  A disadvantage of moving a specification out of a CG into a WG is, however, that you potentially lose a lot of the expertise that is already involved in the development of the spec. People don’t easily re-subscribe to additional mailing lists or want the additional complexity of involving another community (see e.g. this email).

  So, a good process needs to be developed to allow everyone to contribute to the spec in the best way possible without requiring duplicate work. How can we do that ?

  The forthcoming process

  At TPAC the TT-WG discussed for several hours what the next steps are in taking WebVTT through the TT-WG to recommendation status (agenda with slides). I won’t bore you with the different views – if you are keen, you can read the minutes.

  What I came away with is the following process :

  1. Fix a few more bugs in the CG until we’re happy with the feature set in the CG. This should match the feature set that we realistically expect devices to implement for a first version of the WebVTT spec.
  2. Make a FSA (Final Specification Agreement) in the CG to create a stable reference and a clean IPR position.
  3. Assuming that the TT-WG’s charter has been approved with WebVTT as a milestone, we would next bring the FSA specification into the TT-WG as FPWD (First Public Working Draft) and immediately do a Last Call which effectively freezes the feature set (this is possible because there has already been wide community review of the WebVTT spec) ; in parallel, the CG can continue to develop the next version of the WebVTT spec with new features (just like it is happening with the HTML5 and HTML5.1 specifications).
  4. Develop a test suite and address any issues in the Last Call document (of course, also fix these issues in the CG version of the spec).
  5. As per W3C process, substantive and minor changes to Last Call documents have to be reported and raised issues addressed before the spec can progress to the next level : Candidate Recommendation status.
  6. For the next step – Proposed Recommendation status – an implementation report is necessary, and thus the test suite needs to be finalized for the given feature set. The feature set may also be reduced at this stage to just the ones implemented interoperably, leaving any other features for the next version of the spec.
  7. The final step is Recommendation status, which simply requires sufficient support and endorsement by W3C members.

  The first version of the WebVTT spec naturally has a focus on captioning (and subtitling), since this has been the dominant use case that we have focused on this far and it’s the part that is the most compatibly implemented feature set of WebVTT in browsers. It’s my expectation that the next version of WebVTT will have a lot more features related to audio descriptions, chapters and metadata. Thus, this seems a good time for a first version feature freeze.

  There are still several obstacles towards progressing WebVTT as a milestone of the TT-WG. Apart from the need to get buy-in from the TT-WG, the TT-CG, and the AC (Adivisory Committee who have to approve the new charter), we’re also looking at the license of the specification document.

  The CG specification has an open license that allows creating derivative work as long as there is attribution, while the W3C document license for documents on the recommendation track does not allow the creation of derivative work unless given explicit exceptions. This is an issue that is currently being discussed in the W3C with a proposal for a CC-BY license on the Recommendation track. However, my view is that it’s probably ok to use the different document licenses : the TT-WG will work on WebVTT 1.0 and give it a W3C document license, while the CG starts working on the next WebVTT version under the open CG license. It probably actually makes sense to have a less open license on a frozen spec.

  Making the best of a complicated world

  WebVTT is now proposed as part of the recharter of the TT-WG. I have no idea how complicated the process will become to achieve a W3C WebVTT 1.0 Recommendation, but I am hoping that what is outlined above will be workable in such a way that all of us get to focus on progressing the technology.

  At TPAC I got the impression that the TT-WG is committed to progressing WebVTT to Recommendation status. I know that the TT-CG is committed to continue developing WebVTT to its full potential for all kinds of media-time aligned content with new kinds already discussed at FOMS. Let’s enable both groups to achieve their goals. As a consequence, we will allow the two formats to excel where they do : TTML as an interchange format and WebVTT as a browser rendering format.

• ffmpeg blend to exclude the top videos background

  2 février 2016, par user2995705

  I want to blend two videos, the top video named "top.mp4" was combined with some PNG files,but the combined video’s background was black ? why ?

  then i try to overlay the top.mp4 on another video (named bottom.mp4,was capture by android camera with QUALITY_480P)

  but when I use Overlay filter i find the top.mp4 was not transparent and have a black background on the result.mp4.

  I try to use blend filter to combine top.mp4 and bottom.mp4 to exclude the top.mp4’s black background , but i don’t know how to use the blend filter.

  here is my question :
  1.is it possible to combine PNG files to a video and the video has transparent background ? and then just use overlay filter,the result.mp4 will not have a black mask under the top.mp4 ?

  2.if 1 is impossible, how to blend top.mp4 and bottom.mp4 to exclude the black background of top.mp4

  my all output log

  02-02 19:34:04.300 7979-18573/com.demo D/LLLLLLLLLL: /data/data/com.demo/app_bin/ffmpeg -i /storage/sdcard0/baishiMagic/magic/waterfall/waterfall/waterfall_%04d.png -r 25 -vcodec copy -preset ultrafast -y /storage/sdcard0/baishiMagic/temp/anim1.mov 
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL: ffmpeg version n2.4.2 Copyright (c) 2000-2014 the FFmpeg developers
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   built on Oct  7 2014 15:05:17 with gcc 4.8 (GCC)
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   configuration: --target-os=linux --cross-prefix=/home/sb/Source-Code/ffmpeg-android/toolchain-android/bin/arm-linux-androideabi- --arch=arm --cpu=cortex-a8 --enable-runtime-cpudetect --sysroot=/home/sb/Source-Code/ffmpeg-android/toolchain-android/sysroot --enable-pic --enable-libx264 --enable-libass --enable-libfreetype --enable-libfribidi --enable-fontconfig --enable-pthreads --disable-debug --disable-ffserver --enable-version3 --enable-hardcoded-tables --disable-ffplay --disable-ffprobe --enable-gpl --enable-yasm --disable-doc --disable-shared --enable-static --pkg-config=/home/sb/Source-Code/ffmpeg-android/ffmpeg-pkg-config --prefix=/home/sb/Source-Code/ffmpeg-android/build/armeabi-v7a --extra-cflags='-I/home/sb/Source-Code/ffmpeg-android/toolchain-android/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fstack-protector-all' --extra-ldflags='-L/home/sb/Source-Code/ffmpeg-android/toolchain-android/lib -Wl,-z,relro -Wl,-z,now -pie' --extra-libs='-lpng -lexpat -lm' --extra-cxxflags=
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libavutil      54.  7.100 / 54.  7.100
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libavcodec     56.  1.100 / 56.  1.100
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libavformat    56.  4.101 / 56.  4.101
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libavdevice    56.  0.100 / 56.  0.100
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libavfilter     5.  1.100 /  5.  1.100
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libswscale      3.  0.100 /  3.  0.100
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libswresample   1.  1.100 /  1.  1.100
  
  02-02 19:34:04.345 7979-18576/com.demo D/LLLLLLLLLL:   libpostproc    53.  0.100 / 53.  0.100
  
  02-02 19:34:04.460 7979-18576/com.demo D/LLLLLLLLLL: Input #0, image2, from '/storage/sdcard0/baishiMagic/magic/waterfall/waterfall/waterfall_%04d.png':
  
  02-02 19:34:04.460 7979-18576/com.demo D/LLLLLLLLLL:   Duration: 00:00:08.00, start: 0.000000, bitrate: N/A
  
  02-02 19:34:04.460 7979-18576/com.demo D/LLLLLLLLLL:     Stream #0:0: Video: png, rgba, 480x640 [SAR 3779:3779 DAR 3:4], 25 fps, 25 tbr, 25 tbn, 25 tbc
  
  02-02 19:34:04.470 7979-18576/com.demo D/LLLLLLLLLL: Output #0, mov, to '/storage/sdcard0/baishiMagic/temp/anim1.mov':
  
  02-02 19:34:04.470 7979-18576/com.demo D/LLLLLLLLLL:   Metadata:
  
  02-02 19:34:04.470 7979-18576/com.demo D/LLLLLLLLLL:     encoder         : Lavf56.4.101
  
  02-02 19:34:04.470 7979-18576/com.demo D/LLLLLLLLLL:     Stream #0:0: Video: png (png  / 0x20676E70), rgba, 480x640 [SAR 3779:3779 DAR 3:4], q=2-31, 25 fps, 12800 tbn, 25 tbc
  
  02-02 19:34:04.470 7979-18576/com.demo D/LLLLLLLLLL: Stream mapping:
  
  02-02 19:34:04.470 7979-18576/com.demo D/LLLLLLLLLL:   Stream #0:0 -> #0:0 (copy)
  
  02-02 19:34:04.470 7979-18576/com.demo D/LLLLLLLLLL: Press [q] to stop, [?] for help
  
  02-02 19:34:05.565 7979-18576/com.demo D/LLLLLLLLLL: frame=   46 fps=0.0 q=-1.0 size=   12339kB time=00:00:01.84 bitrate=54936.1kbits/s    
  
  02-02 19:34:06.070 7979-18576/com.demo D/LLLLLLLLLL: frame=   59 fps= 56 q=-1.0 size=   22617kB time=00:00:02.36 bitrate=78509.1kbits/s    
  
  02-02 19:34:06.580 7979-18576/com.demo D/LLLLLLLLLL: frame=   71 fps= 45 q=-1.0 size=   32451kB time=00:00:02.84 bitrate=93605.9kbits/s    
  
  02-02 19:34:07.095 7979-18576/com.demo D/LLLLLLLLLL: frame=   88 fps= 42 q=-1.0 size=   42163kB time=00:00:03.52 bitrate=98124.1kbits/s    
  
  02-02 19:34:07.610 7979-18576/com.demo D/LLLLLLLLLL: frame=  109 fps= 42 q=-1.0 size=   52919kB time=00:00:04.36 bitrate=99428.7kbits/s    
  
  02-02 19:34:08.095 7979-18576/com.demo D/LLLLLLLLLL: frame=  128 fps= 41 q=-1.0 size=   64222kB time=00:00:05.12 bitrate=102755.2kbits/s    
  
  02-02 19:34:08.270 7979-18576/com.demo D/LLLLLLLLLL: frame=  160 fps= 44 q=-1.0 size=   74397kB time=00:00:06.40 bitrate=95227.6kbits/s    
  
  02-02 19:34:08.270 7979-18576/com.demo D/LLLLLLLLLL: frame=  200 fps= 53 q=-1.0 Lsize=   77598kB time=00:00:08.00 bitrate=79460.4kbits/s    
  
  02-02 19:34:08.270 7979-18576/com.demo D/LLLLLLLLLL: video:77596kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002606%
  
  02-02 19:34:08.270 7979-18573/com.demo D/LLLLLLLLLL: 图片合成,exitValue=0
  
  02-02 19:34:08.295 7979-18573/com.demo D/LLLLLLLLLL: /data/data/com.demo/app_bin/ffmpeg -i /storage/sdcard0/baishiMagic/magic/waterfall/fish_isolate/fish_%04d.png -r 25 -vcodec copy -preset ultrafast -y /storage/sdcard0/baishiMagic/temp/anim2.mov 
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL: ffmpeg version n2.4.2 Copyright (c) 2000-2014 the FFmpeg developers
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   built on Oct  7 2014 15:05:17 with gcc 4.8 (GCC)
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   configuration: --target-os=linux --cross-prefix=/home/sb/Source-Code/ffmpeg-android/toolchain-android/bin/arm-linux-androideabi- --arch=arm --cpu=cortex-a8 --enable-runtime-cpudetect --sysroot=/home/sb/Source-Code/ffmpeg-android/toolchain-android/sysroot --enable-pic --enable-libx264 --enable-libass --enable-libfreetype --enable-libfribidi --enable-fontconfig --enable-pthreads --disable-debug --disable-ffserver --enable-version3 --enable-hardcoded-tables --disable-ffplay --disable-ffprobe --enable-gpl --enable-yasm --disable-doc --disable-shared --enable-static --pkg-config=/home/sb/Source-Code/ffmpeg-android/ffmpeg-pkg-config --prefix=/home/sb/Source-Code/ffmpeg-android/build/armeabi-v7a --extra-cflags='-I/home/sb/Source-Code/ffmpeg-android/toolchain-android/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fstack-protector-all' --extra-ldflags='-L/home/sb/Source-Code/ffmpeg-android/toolchain-android/lib -Wl,-z,relro -Wl,-z,now -pie' --extra-libs='-lpng -lexpat -lm' --extra-cxxflags=
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libavutil      54.  7.100 / 54.  7.100
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libavcodec     56.  1.100 / 56.  1.100
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libavformat    56.  4.101 / 56.  4.101
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libavdevice    56.  0.100 / 56.  0.100
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libavfilter     5.  1.100 /  5.  1.100
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libswscale      3.  0.100 /  3.  0.100
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libswresample   1.  1.100 /  1.  1.100
  
  02-02 19:34:08.325 7979-18674/com.demo D/LLLLLLLLLL:   libpostproc    53.  0.100 / 53.  0.100
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL: Input #0, image2, from '/storage/sdcard0/baishiMagic/magic/waterfall/fish_isolate/fish_%04d.png':
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL:   Duration: 00:00:08.00, start: 0.000000, bitrate: N/A
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL:     Stream #0:0: Video: png, rgba, 480x640 [SAR 3779:3779 DAR 3:4], 25 fps, 25 tbr, 25 tbn, 25 tbc
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL: Output #0, mov, to '/storage/sdcard0/baishiMagic/temp/anim2.mov':
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL:   Metadata:
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL:     encoder         : Lavf56.4.101
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL:     Stream #0:0: Video: png (png  / 0x20676E70), rgba, 480x640 [SAR 3779:3779 DAR 3:4], q=2-31, 25 fps, 12800 tbn, 25 tbc
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL: Stream mapping:
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL:   Stream #0:0 -> #0:0 (copy)
  
  02-02 19:34:08.410 7979-18674/com.demo D/LLLLLLLLLL: Press [q] to stop, [?] for help
  
  02-02 19:34:08.750 7979-18674/com.demo D/LLLLLLLLLL: frame=  200 fps=0.0 q=-1.0 Lsize=    6606kB time=00:00:08.00 bitrate=6764.2kbits/s    
  
  02-02 19:34:08.750 7979-18674/com.demo D/LLLLLLLLLL: video:6604kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.023112%
  
  02-02 19:34:08.750 7979-18573/com.demo D/LLLLLLLLLL: 图片合成,exitValue=0
  
  02-02 19:34:08.780 7979-18573/com.demo D/LLLLLLLLLL: /data/data/com.demo/app_bin/ffmpeg -y -i /storage/sdcard0/baishiMagic/temp/video1454412829452.mp4 -r 25 -i /storage/sdcard0/baishiMagic/temp/anim1.mov -i /storage/sdcard0/baishiMagic/temp/anim2.mov -i /storage/sdcard0/frame.ts -filter_complex transpose=1,crop=480:640:0:40,overlay=0:0:0,overlay=-2:-2:0,overlay=0:0:0 -preset ultrafast -strict -2 /storage/sdcard0/baishiMagic/result.mp4 
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL: ffmpeg version n2.4.2 Copyright (c) 2000-2014 the FFmpeg developers
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   built on Oct  7 2014 15:05:17 with gcc 4.8 (GCC)
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   configuration: --target-os=linux --cross-prefix=/home/sb/Source-Code/ffmpeg-android/toolchain-android/bin/arm-linux-androideabi- --arch=arm --cpu=cortex-a8 --enable-runtime-cpudetect --sysroot=/home/sb/Source-Code/ffmpeg-android/toolchain-android/sysroot --enable-pic --enable-libx264 --enable-libass --enable-libfreetype --enable-libfribidi --enable-fontconfig --enable-pthreads --disable-debug --disable-ffserver --enable-version3 --enable-hardcoded-tables --disable-ffplay --disable-ffprobe --enable-gpl --enable-yasm --disable-doc --disable-shared --enable-static --pkg-config=/home/sb/Source-Code/ffmpeg-android/ffmpeg-pkg-config --prefix=/home/sb/Source-Code/ffmpeg-android/build/armeabi-v7a --extra-cflags='-I/home/sb/Source-Code/ffmpeg-android/toolchain-android/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fstack-protector-all' --extra-ldflags='-L/home/sb/Source-Code/ffmpeg-android/toolchain-android/lib -Wl,-z,relro -Wl,-z,now -pie' --extra-libs='-lpng -lexpat -lm' --extra-cxxflags=
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libavutil      54.  7.100 / 54.  7.100
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libavcodec     56.  1.100 / 56.  1.100
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libavformat    56.  4.101 / 56.  4.101
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libavdevice    56.  0.100 / 56.  0.100
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libavfilter     5.  1.100 /  5.  1.100
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libswscale      3.  0.100 /  3.  0.100
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libswresample   1.  1.100 /  1.  1.100
  
  02-02 19:34:08.810 7979-18716/com.demo D/LLLLLLLLLL:   libpostproc    53.  0.100 / 53.  0.100
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL: Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/storage/sdcard0/baishiMagic/temp/video1454412829452.mp4':
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:   Metadata:
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     major_brand     : isom
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     minor_version   : 0
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     compatible_brands: isom3gp4
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     creation_time   : 2016-02-02 11:33:58
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:   Duration: 00:00:07.64, start: 0.000000, bitrate: 3099 kb/s
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 640x480, 3074 kb/s, SAR 1:1 DAR 4:3, 29.82 fps, 30 tbr, 90k tbn, 180k tbc (default)
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     Metadata:
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:       rotate          : 180
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:       creation_time   : 2016-02-02 11:33:58
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:       handler_name    : VideoHandle
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:       encoder         :                                
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     Side data:
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:       displaymatrix: rotation of 180.00 degrees
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 124 kb/s (default)
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:     Metadata:
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:       creation_time   : 2016-02-02 11:33:58
  
  02-02 19:34:08.870 7979-18716/com.demo D/LLLLLLLLLL:       handler_name    : SoundHandle
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL: Input #1, mov,mp4,m4a,3gp,3g2,mj2, from '/storage/sdcard0/baishiMagic/temp/anim1.mov':
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:   Metadata:
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:     major_brand     : qt  
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:     minor_version   : 512
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:     compatible_brands: qt  
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:     encoder         : Lavf56.4.101
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:   Duration: 00:00:08.00, start: 0.000000, bitrate: 79460 kb/s
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:     Stream #1:0(eng): Video: png (png  / 0x20676E70), rgba, 480x640 [SAR 3779:3779 DAR 3:4], 79458 kb/s, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default)
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:     Metadata:
  
  02-02 19:34:08.920 7979-18716/com.demo D/LLLLLLLLLL:       handler_name    : DataHandler
  
  02-02 19:34:08.950 7979-18716/com.demo D/LLLLLLLLLL: Input #2, mov,mp4,m4a,3gp,3g2,mj2, from '/storage/sdcard0/baishiMagic/temp/anim2.mov':
  
  02-02 19:34:08.950 7979-18716/com.demo D/LLLLLLLLLL:   Metadata:
  
  02-02 19:34:08.950 7979-18716/com.demo D/LLLLLLLLLL:     major_brand     : qt  
  
  02-02 19:34:08.950 7979-18716/com.demo D/LLLLLLLLLL:     minor_version   : 512
  
  02-02 19:34:08.950 7979-18716/com.demo D/LLLLLLLLLL:     compatible_brands: qt  
  
  02-02 19:34:08.950 7979-18716/com.demo D/LLLLLLLLLL:     encoder         : Lavf56.4.101
  
  02-02 19:34:08.950 7979-18716/com.demo D/LLLLLLLLLL:   Duration: 00:00:08.00, start: 0.000000, bitrate: 6764 kb/s
  
  02-02 19:34:08.955 7979-18716/com.demo D/LLLLLLLLLL:     Stream #2:0(eng): Video: png (png  / 0x20676E70), rgba, 480x640 [SAR 3779:3779 DAR 3:4], 6762 kb/s, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default)
  
  02-02 19:34:08.955 7979-18716/com.demo D/LLLLLLLLLL:     Metadata:
  
  02-02 19:34:08.955 7979-18716/com.demo D/LLLLLLLLLL:       handler_name    : DataHandler
  
  02-02 19:34:08.985 7979-18716/com.demo D/LLLLLLLLLL: Input #3, mpegts, from '/storage/sdcard0/frame.ts':
  
  02-02 19:34:08.985 7979-18716/com.demo D/LLLLLLLLLL:   Duration: 00:00:05.13, start: 1.533333, bitrate: 1006 kb/s
  
  02-02 19:34:08.985 7979-18716/com.demo D/LLLLLLLLLL:   Program 1 
  
  02-02 19:34:08.985 7979-18716/com.demo D/LLLLLLLLLL:     Metadata:
  
  02-02 19:34:08.985 7979-18716/com.demo D/LLLLLLLLLL:       service_name    : Service01
  
  02-02 19:34:08.985 7979-18716/com.demo D/LLLLLLLLLL:       service_provider: FFmpeg
  
  02-02 19:34:08.985 7979-18716/com.demo D/LLLLLLLLLL:     Stream #3:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 480x480 [SAR 1:1 DAR 1:1], 15 fps, 15 tbr, 90k tbn, 30 tbc
  
  02-02 19:34:09.000 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] using SAR=1/1
  
  02-02 19:34:09.020 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] using cpu capabilities: none!
  
  02-02 19:34:09.115 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] profile Constrained Baseline, level 3.0
  
  02-02 19:34:09.115 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] 264 - core 142 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=crf mbtree=0 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=0
  
  02-02 19:34:09.170 7979-18716/com.demo D/LLLLLLLLLL: Output #0, mp4, to '/storage/sdcard0/baishiMagic/result.mp4':
  
  02-02 19:34:09.170 7979-18716/com.demo D/LLLLLLLLLL:   Metadata:
  
  02-02 19:34:09.170 7979-18716/com.demo D/LLLLLLLLLL:     major_brand     : isom
  
  02-02 19:34:09.175 7979-18716/com.demo D/LLLLLLLLLL:     minor_version   : 0
  
  02-02 19:34:09.175 7979-18716/com.demo D/LLLLLLLLLL:     compatible_brands: isom3gp4
  
  02-02 19:34:09.175 7979-18716/com.demo D/LLLLLLLLLL:     encoder         : Lavf56.4.101
  
  02-02 19:34:09.175 7979-18716/com.demo D/LLLLLLLLLL:     Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 480x640 [SAR 1:1 DAR 3:4], q=-1--1, 30 fps, 15360 tbn, 30 tbc (default)
  
  02-02 19:34:09.175 7979-18716/com.demo D/LLLLLLLLLL:     Metadata:
  
  02-02 19:34:09.175 7979-18716/com.demo D/LLLLLLLLLL:       encoder         : Lavc56.1.100 libx264
  
  02-02 19:34:09.175 7979-18716/com.demo D/LLLLLLLLLL:     Stream #0:1(eng): Audio: aac ([64][0][0][0] / 0x0040), 48000 Hz, mono, fltp, 128 kb/s (default)
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:     Metadata:
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:       creation_time   : 2016-02-02 11:33:58
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:       handler_name    : SoundHandle
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:       encoder         : Lavc56.1.100 aac
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL: Stream mapping:
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:   Stream #0:0 (h264) -> transpose (graph 0)
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:   Stream #1:0 (png) -> overlay:overlay (graph 0)
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:   Stream #2:0 (png) -> overlay:overlay (graph 0)
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:   Stream #3:0 (h264) -> overlay:overlay (graph 0)
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:   overlay (graph 0) -> Stream #0:0 (libx264)
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL:   Stream #0:1 -> #0:1 (aac (native) -> aac (native))
  
  02-02 19:34:09.180 7979-18716/com.demo D/LLLLLLLLLL: Press [q] to stop, [?] for help
  
  02-02 19:34:10.250 7979-18716/com.demo D/LLLLLLLLLL: frame=    1 fps=0.0 q=0.0 size=       0kB time=00:00:01.00 bitrate=   0.4kbits/s    
  
  02-02 19:34:10.745 7979-18716/com.demo D/LLLLLLLLLL: frame=    6 fps=5.9 q=0.0 size=       0kB time=00:00:01.00 bitrate=   0.4kbits/s    
  
  02-02 19:34:11.295 7979-18716/com.demo D/LLLLLLLLLL: frame=   11 fps=7.1 q=19.0 size=      11kB time=00:00:01.00 bitrate=  92.1kbits/s    
  
  02-02 19:34:11.760 7979-18716/com.demo D/LLLLLLLLLL: frame=   16 fps=7.7 q=19.0 size=      24kB time=00:00:01.00 bitrate= 199.3kbits/s    
  
  02-02 19:34:12.335 7979-18716/com.demo D/LLLLLLLLLL: frame=   22 fps=8.5 q=20.0 size=      39kB time=00:00:01.00 bitrate= 319.8kbits/s    
  
  02-02 19:34:12.870 7979-18716/com.demo D/LLLLLLLLLL: frame=   28 fps=9.0 q=19.0 size=      58kB time=00:00:01.00 bitrate= 475.7kbits/s    
  
  02-02 19:34:13.345 7979-18716/com.demo D/LLLLLLLLLL: frame=   30 fps=8.3 q=20.0 size=      63kB time=00:00:02.00 bitrate= 258.6kbits/s    
  
  02-02 19:34:13.935 7979-18716/com.demo D/LLLLLLLLLL: frame=   34 fps=8.2 q=20.0 size=      74kB time=00:00:02.00 bitrate= 300.8kbits/s    
  
  02-02 19:34:14.480 7979-18716/com.demo D/LLLLLLLLLL: frame=   39 fps=8.2 q=20.0 size=      87kB time=00:00:02.00 bitrate= 354.0kbits/s    
  
  02-02 19:34:15.015 7979-18716/com.demo D/LLLLLLLLLL: frame=   43 fps=8.2 q=20.0 size=      98kB time=00:00:02.00 bitrate= 400.4kbits/s    
  
  02-02 19:34:15.515 7979-18716/com.demo D/LLLLLLLLLL: frame=   48 fps=8.3 q=21.0 size=     112kB time=00:00:02.00 bitrate= 459.5kbits/s    
  
  02-02 19:34:16.015 7979-18716/com.demo D/LLLLLLLLLL: frame=   54 fps=8.5 q=24.0 size=     137kB time=00:00:02.00 bitrate= 557.9kbits/s    
  
  02-02 19:34:16.575 7979-18716/com.demo D/LLLLLLLLLL: frame=   58 fps=8.5 q=24.0 size=     169kB time=00:00:02.19 bitrate= 628.2kbits/s    
  
  02-02 19:34:17.090 7979-18716/com.demo D/LLLLLLLLLL: frame=   60 fps=8.2 q=24.0 size=     189kB time=00:00:03.00 bitrate= 515.4kbits/s    
  
  02-02 19:34:17.605 7979-18716/com.demo D/LLLLLLLLLL: frame=   65 fps=8.3 q=23.0 size=     228kB time=00:00:03.00 bitrate= 621.7kbits/s    
  
  02-02 19:34:18.090 7979-18716/com.demo D/LLLLLLLLLL: frame=   70 fps=8.4 q=24.0 size=     269kB time=00:00:03.00 bitrate= 731.7kbits/s    
  
  02-02 19:34:18.655 7979-18716/com.demo D/LLLLLLLLLL: frame=   76 fps=8.5 q=25.0 size=     320kB time=00:00:03.00 bitrate= 870.6kbits/s    
  
  02-02 19:34:19.115 7979-18716/com.demo D/LLLLLLLLLL: frame=   82 fps=8.7 q=25.0 size=     374kB time=00:00:03.00 bitrate=1019.4kbits/s    
  
  02-02 19:34:19.620 7979-18716/com.demo D/LLLLLLLLLL: frame=   87 fps=8.8 q=24.0 size=     419kB time=00:00:03.00 bitrate=1142.2kbits/s    
  
  02-02 19:34:20.120 7979-18716/com.demo D/LLLLLLLLLL: frame=   89 fps=8.5 q=22.0 size=     434kB time=00:00:04.01 bitrate= 885.6kbits/s    
  
  02-02 19:34:20.685 7979-18716/com.demo D/LLLLLLLLLL: frame=   94 fps=8.6 q=22.0 size=     464kB time=00:00:04.01 bitrate= 947.8kbits/s    
  
  02-02 19:34:21.155 7979-18716/com.demo D/LLLLLLLLLL: frame=  100 fps=8.7 q=22.0 size=     495kB time=00:00:04.01 bitrate=1010.7kbits/s    
  
  02-02 19:34:21.685 7979-18716/com.demo D/LLLLLLLLLL: frame=  105 fps=8.8 q=22.0 size=     523kB time=00:00:04.01 bitrate=1067.3kbits/s    
  
  02-02 19:34:22.180 7979-18716/com.demo D/LLLLLLLLLL: frame=  110 fps=8.8 q=22.0 size=     551kB time=00:00:04.01 bitrate=1125.1kbits/s    
  
  02-02 19:34:22.685 7979-18716/com.demo D/LLLLLLLLLL: frame=  115 fps=8.9 q=22.0 size=     576kB time=00:00:04.01 bitrate=1176.9kbits/s    
  
  02-02 19:34:23.200 7979-18716/com.demo D/LLLLLLLLLL: frame=  118 fps=8.7 q=21.0 size=     592kB time=00:00:04.92 bitrate= 984.3kbits/s    
  
  02-02 19:34:23.715 7979-18716/com.demo D/LLLLLLLLLL: frame=  123 fps=8.8 q=22.0 size=     619kB time=00:00:05.01 bitrate=1011.1kbits/s    
  
  02-02 19:34:24.265 7979-18716/com.demo D/LLLLLLLLLL: frame=  127 fps=8.7 q=22.0 size=     638kB time=00:00:05.01 bitrate=1042.8kbits/s    
  
  02-02 19:34:24.765 7979-18716/com.demo D/LLLLLLLLLL: frame=  131 fps=8.7 q=23.0 size=     658kB time=00:00:05.01 bitrate=1074.5kbits/s    
  
  02-02 19:34:25.310 7979-18716/com.demo D/LLLLLLLLLL: frame=  137 fps=8.8 q=23.0 size=     700kB time=00:00:05.01 bitrate=1143.7kbits/s    
  
  02-02 19:34:25.800 7979-18716/com.demo D/LLLLLLLLLL: frame=  142 fps=8.8 q=23.0 size=     736kB time=00:00:05.01 bitrate=1202.2kbits/s    
  
  02-02 19:34:26.345 7979-18716/com.demo D/LLLLLLLLLL: frame=  147 fps=8.8 q=24.0 size=     771kB time=00:00:05.14 bitrate=1229.1kbits/s    
  
  02-02 19:34:26.895 7979-18716/com.demo D/LLLLLLLLLL: frame=  150 fps=8.7 q=24.0 size=     798kB time=00:00:06.01 bitrate=1086.7kbits/s    
  
  02-02 19:34:27.385 7979-18716/com.demo D/LLLLLLLLLL: frame=  156 fps=8.8 q=24.0 size=     847kB time=00:00:06.01 bitrate=1153.9kbits/s    
  
  02-02 19:34:27.895 7979-18716/com.demo D/LLLLLLLLLL: frame=  161 fps=8.9 q=23.0 size=     886kB time=00:00:06.01 bitrate=1206.2kbits/s    
  
  02-02 19:34:28.455 7979-18716/com.demo D/LLLLLLLLLL: frame=  167 fps=8.9 q=23.0 size=     927kB time=00:00:06.01 bitrate=1261.6kbits/s    
  
  02-02 19:34:28.905 7979-18716/com.demo D/LLLLLLLLLL: frame=  173 fps=9.0 q=23.0 size=     964kB time=00:00:06.01 bitrate=1312.4kbits/s    
  
  02-02 19:34:29.440 7979-18716/com.demo D/LLLLLLLLLL: frame=  177 fps=9.0 q=23.0 size=     987kB time=00:00:06.20 bitrate=1302.9kbits/s    
  
  02-02 19:34:29.995 7979-18716/com.demo D/LLLLLLLLLL: frame=  180 fps=8.9 q=23.0 size=    1008kB time=00:00:07.01 bitrate=1176.9kbits/s    
  
  02-02 19:34:30.490 7979-18716/com.demo D/LLLLLLLLLL: frame=  186 fps=9.0 q=21.0 size=    1048kB time=00:00:07.01 bitrate=1223.3kbits/s    
  
  02-02 19:34:31.015 7979-18716/com.demo D/LLLLLLLLLL: frame=  191 fps=9.0 q=19.0 size=    1076kB time=00:00:07.01 bitrate=1255.5kbits/s    
  
  02-02 19:34:31.495 7979-18716/com.demo D/LLLLLLLLLL: frame=  197 fps=9.0 q=18.0 size=    1103kB time=00:00:07.01 bitrate=1287.1kbits/s    
  
  02-02 19:34:32.040 7979-18716/com.demo D/LLLLLLLLLL: frame=  202 fps=9.1 q=19.0 size=    1119kB time=00:00:07.01 bitrate=1306.5kbits/s    
  
  02-02 19:34:32.555 7979-18716/com.demo D/LLLLLLLLLL: frame=  207 fps=9.1 q=20.0 size=    1138kB time=00:00:07.01 bitrate=1328.1kbits/s    
  
  02-02 19:34:33.140 7979-18716/com.demo D/LLLLLLLLLL: frame=  213 fps=9.1 q=19.0 size=    1161kB time=00:00:07.01 bitrate=1354.7kbits/s    
  
  02-02 19:34:33.695 7979-18716/com.demo D/LLLLLLLLLL: frame=  217 fps=9.1 q=19.0 size=    1176kB time=00:00:07.59 bitrate=1268.3kbits/s    
  
  02-02 19:34:34.205 7979-18716/com.demo D/LLLLLLLLLL: frame=  222 fps=9.1 q=19.0 size=    1195kB time=00:00:07.59 bitrate=1288.8kbits/s dup=0 drop=4    
  
  02-02 19:34:34.720 7979-18716/com.demo D/LLLLLLLLLL: frame=  222 fps=8.9 q=19.0 size=    1195kB time=00:00:07.59 bitrate=1288.8kbits/s dup=0 drop=13    
  
  02-02 19:34:35.075 7979-18716/com.demo D/LLLLLLLLLL: frame=  222 fps=8.7 q=19.0 size=    1195kB time=00:00:07.59 bitrate=1288.8kbits/s dup=0 drop=24    
  
  02-02 19:34:35.075 7979-18716/com.demo D/LLLLLLLLLL: frame=  222 fps=8.6 q=-1.0 Lsize=    1233kB time=00:00:07.63 bitrate=1322.5kbits/s dup=0 drop=30    
  
  02-02 19:34:35.075 7979-18716/com.demo D/LLLLLLLLLL: video:1104kB audio:122kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.615799%
  
  02-02 19:34:35.095 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] frame I:1     Avg QP:20.00  size:  5784
  
  02-02 19:34:35.095 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] frame P:221   Avg QP:21.62  size:  5084
  
  02-02 19:34:35.095 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] mb I  I16..4: 100.0%  0.0%  0.0%
  
  02-02 19:34:35.095 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] mb P  I16..4: 17.6%  0.0%  0.0%  P16..4: 21.8%  0.0%  0.0%  0.0%  0.0%    skip:60.5%
  
  02-02 19:34:35.100 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] coded y,uvDC,uvAC intra: 36.9% 18.1% 2.2% inter: 13.0% 7.3% 0.1%
  
  02-02 19:34:35.100 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] i16 v,h,dc,p: 27% 30% 24% 19%
  
  02-02 19:34:35.100 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] i8c dc,h,v,p: 57% 22% 17%  3%
  
  02-02 19:34:35.100 7979-18716/com.demo D/LLLLLLLLLL: [libx264 @ 0x2b447ef0] kb/s:1221.00
  
  02-02 19:34:35.110 7979-18573/com.demo D/LLLLLLLLLL: 视频处理,exitValue=0