Recherche avancée

Sur d’autres sites (5429)

• Android FFmpeg sometimes works and sometimes crashes

  20 novembre 2013, par Pawel Cala

  I compiled FFmpeg for Android ( https://gitorious.org/android-ffmpeg ) but when I'm trying to do some operations ( f.e filters cropping, transpose, trim etc ) it crashes in 5 on 10 cases.
  Error logs are not the same so I assume that it might be caused by memory issues.
  I'm using OSX, NDK android-ndk-r9b : darwing x86_64.
  Native ffmpeg method is passing args to ffmpeg.c main method. It's executed in AsyncTask in Activity.
  Thanks in advance

  EDIT :
  I forgot to mention that programs algorithm runs like that :
  Press Button - > Open Camera Intent - > Start recording - > After recording copy file to project folder ( on SD card ) - > Open edit activity + Start asynctask

  EDIT2 :
  Tested on HTC ONE with different video resolutions

  Version and config of ffmpeg

  11-20 12:15:23.001: I/ff-log(19091): ffmpeg version 0.10.2.git
  
  11-20 12:15:23.001: I/ff-log(19091):  Copyright (c) 2000-2012 the FFmpeg developers
  
  11-20 12:15:23.001: I/ff-log(19091):   built on Nov 20 2013 12:12:46 with gcc 4.6 20120106 (prerelease)
  
  11-20 12:15:23.001: I/ff-log(19091):   configuration: --target-os=linux --cross-prefix=arm-linux-androideabi- --arch=arm --cpu=armv7-a --disable-ffplay --disable-ffserver --disable-network --disable-avdevice --enable-protocol=file --enable-hwaccel=mpeg4_vaapi --enable-hwaccel=h264_vaapi --sysroot=/Users/dpc/Developer/android-ndk-r9b/platforms/android-9/arch-arm --disable-decoder=h264_vdpau --prefix=build/armv7-a --disable-asm --enable-small --disable-everything --enable-decoder=mjpeg --enable-parser=mjpeg --enable-muxer=mp4 --enable-muxer=h264 --enable-muxer=h263 --enable-muxer=yuv4mpegpipe --enable-muxer=mov --enable-demuxer=mpegvideo --enable-demuxer=mjpeg --enable-demuxer=image2 --enable-demuxer=mp4 --enable-demuxer=aac --enable-demuxer=ac3 --enable-demuxer=mp3 --enable-demuxer=yuv4mpegpipe --enable-demuxer=mov --enable-decoder=mpegvideo --enable-decoder=mpeg4 --enable-decoder=mp3 --enable-decoder=ac3 --enable-decoder=aac --enable-decoder=h264 --enable-decoder=h263 --enable-decoder=rawvideo --enable-decoder=yuv4 --enable-decoder=png --enable

  Sample comand :

  1-20 12:15:22.991: I/FFMPEG(19091): CMD:-i file:/storage/emulated/0/.project/videos/mac_video_tmp.mp4 -vf crop=1079:1079:0:420 -vcodec mpeg4 -sameq -acodec copy file:/storage/emulated/0/.project/videos/croppedVid.mp4

  Some output errors :

  1st type :

     11-20 12:15:23.011: I/ff-log(19091):   libavutil      51. 46.100 / 51. 46.100
  
  11-20 12:15:23.011: I/ff-log(19091):   libavcodec     54. 14.101 / 54. 14.101
  
  11-20 12:15:23.011: I/ff-log(19091):   libavformat    54.  3.100 / 54.  3.100
  
  11-20 12:15:23.011: I/ff-log(19091):   libavfilter     2. 70.100 /  2. 70.100
  
  11-20 12:15:23.011: I/ff-log(19091):   libswscale      2.  1.100 /  2.  1.100
  
  11-20 12:15:23.011: I/ff-log(19091):   libswresample   0. 11.100 /  0. 11.100
  
  11-20 12:15:23.011: I/ff-log(19091): before parsing options
  
  11-20 12:15:23.011: I/ff-log(19091): before parsing options
  
  11-20 12:15:23.011: I/ff-log(19091): parse options
  
  11-20 12:15:23.011: I/ff-log(19091): prepare app arguments !!! NOT defined(_WIN32) && !defined(__MINGW32CE__) !
  
  11-20 12:15:23.011: I/ff-log(19091): after prepare app arguments
  
  11-20 12:15:23.011: I/ff-log(19091): ffurl_open: file:/storage/emulated/0/.project/videos/mac_video_tmp.mp4, 1
  
  11-20 12:15:23.011: I/ff-log(19091): ffurl_alloc: file:/storage/emulated/0/.project/videos/mac_video_tmp.mp4, 1
  
  11-20 12:15:23.011: I/ff-log(19091): ffurl_alloc: file
  
  11-20 12:15:23.011: I/ff-log(19091): ffurl_open alloc: 0
  
  11-20 12:15:23.011: I/ff-log(19091): ffurl_connect
  
  11-20 12:15:23.011: I/ff-log(19091): ffurl_open connect: 0
  
  11-20 12:15:23.011: I/ff-log(19091): Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100
  
  11-20 12:15:23.011: I/ff-log(19091): ISO: File Type Major Brand: isom
  
  11-20 12:15:23.021: I/ff-log(19091): File position before avformat_find_stream_info() is 8458240
  
  11-20 12:15:23.041: A/libc(19091): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 19091 (t.android.utils)

  Second type :

  11-20 12:17:04.800: I/ff-log(19632):   libavutil      51. 46.100 / 51. 46.100
  
  11-20 12:17:04.800: I/ff-log(19632):   libavcodec     54. 14.101 / 54. 14.101
  
  11-20 12:17:04.800: I/ff-log(19632):   libavformat    54.  3.100 / 54.  3.100
  
  11-20 12:17:04.800: I/ff-log(19632):   libavfilter     2. 70.100 /  2. 70.100
  
  11-20 12:17:04.800: I/ff-log(19632):   libswscale      2.  1.100 /  2.  1.100
  
  11-20 12:17:04.800: I/ff-log(19632):   libswresample   0. 11.100 /  0. 11.100
  
  11-20 12:17:04.800: I/ff-log(19632): before parsing options
  
  11-20 12:17:04.800: I/ff-log(19632): before parsing options
  
  11-20 12:17:04.800: I/ff-log(19632): parse options
  
  11-20 12:17:04.800: I/ff-log(19632): prepare app arguments !!! NOT defined(_WIN32) && !defined(__MINGW32CE__) !
  
  11-20 12:17:04.800: I/ff-log(19632): after prepare app arguments
  
  11-20 12:17:04.800: I/ff-log(19632): opt_output_file ܞ�f��f��f��f���flated/0/.project/videos/mac_video_tmp.mp4
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_alloc: ܞ�f��f��f��f���flated/0/.project/videos/mac_video_tmp.mp4, 0
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_alloc: file
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_open: ܞ�f��f��f��f���flated/0/.project/videos/mac_video_tmp.mp4, 2
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_alloc: ܞ�f��f��f��f���flated/0/.project/videos/mac_video_tmp.mp4, 2
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_alloc: file
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_open alloc: 0
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_connect
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_open connect: -2
  
  11-20 12:17:04.800: I/ff-log(19632): ffurl_open FAIL
  
  11-20 12:17:04.800: I/ff-log(19632): ܞ�f��f��f��f���flated/0/.project/videos/mac_video_tmp.mp4: No such file or directory

  ( CHARSER IS AS IT'S IN OUTPUT LOGCAT )

  3rd type :

  11-20 12:18:23.243: I/ff-log(19867):   libavutil      51. 46.100 / 51. 46.100
  
  11-20 12:18:23.243: I/ff-log(19867):   libavcodec     54. 14.101 / 54. 14.101
  
  11-20 12:18:23.243: I/ff-log(19867):   libavformat    54.  3.100 / 54.  3.100
  
  11-20 12:18:23.243: I/ff-log(19867):   libavfilter     2. 70.100 /  2. 70.100
  
  11-20 12:18:23.243: I/ff-log(19867):   libswscale      2.  1.100 /  2.  1.100
  
  11-20 12:18:23.243: I/ff-log(19867):   libswresample   0. 11.100 /  0. 11.100
  
  11-20 12:18:23.243: I/ff-log(19867): before parsing options
  
  11-20 12:18:23.243: I/ff-log(19867): before parsing options
  
  11-20 12:18:23.243: I/ff-log(19867): parse options
  
  11-20 12:18:23.243: I/ff-log(19867): prepare app arguments !!! NOT defined(_WIN32) && !defined(__MINGW32CE__) !
  
  11-20 12:18:23.243: I/ff-log(19867): after prepare app arguments
  
  11-20 12:18:23.243: I/ff-log(19867): Unknown decoder '��f('
  
  11-20 12:18:23.243: I/ff-log(19867): exit_program 1
  
  11-20 12:18:23.243: I/ff-log(19867): exit_program 1
  
  11-20 12:18:23.243: I/ff-log(19867): exit_program 2
  
  11-20 12:18:23.253: A/libc(19867): @@@ ABORTING: invalid address or address of corrupt block 0x1d3422d passed to dlfree
  
  11-20 12:18:23.253: A/libc(19867): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 20393 (AsyncTask #2)

  4th type :

  11-20 12:20:07.214: I/ff-log(20660):   libavutil      51. 46.100 / 51. 46.100
  
  11-20 12:20:07.214: I/ff-log(20660):   libavcodec     54. 14.101 / 54. 14.101
  
  11-20 12:20:07.214: I/ff-log(20660):   libavformat    54.  3.100 / 54.  3.100
  
  11-20 12:20:07.214: I/ff-log(20660):   libavfilter     2. 70.100 /  2. 70.100
  
  11-20 12:20:07.214: I/ff-log(20660):   libswscale      2.  1.100 /  2.  1.100
  
  11-20 12:20:07.214: I/ff-log(20660):   libswresample   0. 11.100 /  0. 11.100
  
  11-20 12:20:07.214: I/ff-log(20660): before parsing options
  
  11-20 12:20:07.214: I/ff-log(20660): before parsing options
  
  11-20 12:20:07.214: I/ff-log(20660): parse options
  
  11-20 12:20:07.214: I/ff-log(20660): prepare app arguments !!! NOT defined(_WIN32) && !defined(__MINGW32CE__) !
  
  11-20 12:20:07.214: I/ff-log(20660): after prepare app arguments
  
  11-20 12:20:07.214: I/ff-log(20660): Unknown decoder ''
  
  11-20 12:20:07.214: I/ff-log(20660): exit_program 1
  
  11-20 12:20:07.214: A/libc(20660): Fatal signal 11 (SIGSEGV) at 0x2d007165 (code=1), thread 21017 (AsyncTask #2)

• Retrieving RTP time from an IP camera programatically using FFMPEG

  22 novembre 2013, par Dídac Pérez

  I am using the ffmpeg C/C++ library to get the video stream from an IP camera using methods such as avformat_open_input(), av_read_frame(), etc... I would like to get the RTP time from the camera. pts and dts values give me the relative timestamp to the first frame, but I need the absolute date (i.e. 2013/11/22 12:40:30.123) and time since as I read, at the RTP layer the time is sent by the camera, and I have also configured the camera to use the dime from an NTP server.

  Please, I am really confused and I have tried everything without success, I am not able to find this date and time. Any help will be really appreciated, thank you so much.

• Our latest improvement to QA : Screenshot Testing

  2 octobre 2013, par benaka — Development

  Introduction to QA in Piwik

  Like any piece of good software, Piwik comes with a comprehensive QA suite that includes unit and integration tests. The unit tests make sure core components of Piwik work properly. The integration tests make sure Piwik’s tracking and report aggregation and APIs work properly.

  To complete our QA suite, we’ve recently added a new type of tests : Screenshot tests, that we use to make sure Piwik’s controller and JavaScript code works properly.

  This blog post will explain how they work and describe our experiences setting them up ; we hope to show you an example of innovative QA practices in an active open source project.

  Screenshot Tests

  As the name implies, our screenshot tests (1) first capture a screenshot of a URL, then (2) compare the result with an expected image. This lets us test the code in Piwik’s controllers and Piwik’s JavaScript simply by specifying a URL.

  Contrast this with conventional UI tests that test for page content changes. Such tests require writing large amounts of test code that, at most, check for changes in HTML. Our tests, on the otherhand, will be able to show regressions in CSS and JavaScript rendering logic with a bare minimum of testing code.

  Capturing Screenshots

  Screenshots are captured using a 3rd party tool. We tried several tools before settling on PhantomJS. PhantomJS executes a JavaScript file with an environment that allows it to create WebKit powered web views. When capturing a screenshot, we supply PhantomJS with a script that :

  • opens a web page view,
  • loads a URL,
  • waits for all AJAX requests to be completed,
  • waits for all images to be loaded
  • waits for all JavaScript to be run.

  Then it renders the completed page to an PNG file.

  • To see how we use PhantomJS see capture.js.
  • To see how we wait for AJAX requests to complete and images to load see override.js.

  Comparing Screenshots

  Once a screenshot is generated we test for UI regressions by comparing it with an expected image. There is no sort of fuzzy matching involved. We just check that the images consist of the same bytes.

  If a screenshot test fails we use ImageMagick’s compare command line tool to generate an image diff :

  

  In this example above, there was a change that caused the Search box to be hidden in the datatable. This resulted in the whole Data table report being shifted up a few pixels. The differences are visible in red color which gives rapid feedback to the developers what has changed in the last commit.

  Screenshot Tests on Travis

  We experienced trouble generating identical screenshots on different machines, so our tests were not initially automated by Travis. Once we surpassed this hurdle, we created a new github repo to store our UI tests and screenshots and then enabled the travis build for it. We also made sure that every time a commit is pushed to the Piwik repo, our travis build will push a commit to the UI test repo to run the UI tests.

  We decided to create a new repository so the main repository wouldn’t be burdened with the large screenshot files (which git would not handle very well). We also made sure the travis build would upload all the generated screenshots to a server so debugging failures would be easier.

  Problems we experienced

  Getting generated screenshots to render identically on separate machines was quite a challenge. It took months to figure out how to get it right. Here’s what we learned :

  Fonts will render identically on different machines, but different machines can pick the wrong fonts. When we first tried getting these tests to run on Travis, we noticed small differences in the way fonts were rendered on different machines. We thought this was an insurmountable problem that would occur due to the libraries installed on these machines. It turns out, the machines were just picking the wrong fonts. After installing certain fonts during our Travis build, everything started working.

  Different versions of GD can generate slightly different images. GD is used in Piwik to, among other things, generate sparkline images. Different versions of GD will result in slightly different images. They look the same to the naked eye, but some pixels will have slightly different colors. This is, unfortunately, a problem we couldn’t solve. We couldn’t make sure that everyone who runs the tests uses the same version of GD, so instead we disabled sparklines for UI testing.

  What we learned about existing screenshot capturing tools

  We tried several screenshot capturing tools before finding one that would work adequately. Here’s what we learned about them :

  • CutyCapt This is the first screenshot capturing tool we tried. CutyCapt is a C++ program that uses QtWebKit to load and take a screenshot of a page. It can’t be used to capture multiple screenshots in one run and it can’t be used to wait for all AJAX/Images/JavaScript to complete/load (at least not currently).

  • PhantomJS This is the solution we eventually chose. PhantomJS is a headless scriptable browser that currently uses WebKit as its rendering engine.

    For the most part, PhantomJS is the best solution we found. It reliably renders screenshots, allows JavaScript to be injected into pages it loads, and since it essentially just runs JavaScript code that you provide, it can be made to do whatever you want.

  • SlimerJS SlimerJS is a clone of PhantomJS that uses Gecko as the rendering engine. It is meant to function similarly to PhantomJS. Unfortunately, due to some limitations hard-coded in Mozilla’s software, we couldn’t use it.

    For one, SlimerJS is not headless. There is, apparently, no way to do that when embedding Mozilla. You can, however, run it through xvfb, however the fact that it has to create a window means some odd things can happen. When using SlimerJS, we would sometimes end up with images where tooltips would display as if the mouse was hovering over an element. This inconsistency meant we couldn’t use it for our tests.

  One tool we didn’t try was Selenium Webdriver. Although Selenium is traditionally used to create tests that check for HTML content, it can be used to generate screenshots. (Note : PhantomJS supports using a remote WebDriver.)

  Our Future Plans for Screenshot Testing

  At the moment we render a couple dozen screenshots. We test how our PHP code, JavaScript code and CSS makes Piwik’s UI look, but we don’t test how it behaves. This is our next step.

  We want to create Screenshot Unit Tests for each UI control Piwik uses (for example, the Data Table View or the Site Selector). These tests would use the Widgetize plugin to load a control by itself, then execute JavaScript that simulates events and user behavior, and finally take a screenshot. This way we can test how our code handles clicks and hovers and all sorts of other behavior.

  Screenshots Tests will make Piwik more stable and keep us agile and able to release early and often. Thank you for your support & Spreading the word about Piwik !