Recherche avancée

Sur d’autres sites (4685)

• ffmpeg with -strict -2 : Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

  8 juin 2018, par Bhumi Shah

  This is my command

  ffmpeg -i a.mp4 -asyncec libx264 -strict -2 -refs 6 -coder 1 -sc_threshold 40 -flags +loop -me_range 16 -subq 7 -i_qfactor 0.71 -qcomp 0.6 -qdiff 4 -trellis 1 -b:a 128k -pass 1 -profile:v baseline -level:v 3.0 -s 1080x1920 a.mp4

  Here is the error i am getting

  ffmpeg version N-46084-gcae004cab-static https://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2018 the FFmpeg developers
  
    built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  
    configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg
  
    libavutil      56. 18.102 / 56. 18.102
  
    libavcodec     58. 19.101 / 58. 19.101
  
    libavformat    58. 13.102 / 58. 13.102
  
    libavdevice    58.  4.100 / 58.  4.100
  
    libavfilter     7. 22.100 /  7. 22.100
  
    libswscale      5.  2.100 /  5.  2.100
  
    libswresample   3.  2.100 /  3.  2.100
  
    libpostproc    55.  2.100 / 55.  2.100
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'a.mp4':
  
    Metadata:
  
      major_brand     : mp42
  
      minor_version   : 0
  
      compatible_brands: mp42mp41
  
      creation_time   : 2018-01-17T06:39:29.000000Z
  
    Duration: 00:00:06.04, start: 0.000000, bitrate: 872 kb/s
  
      Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 2160x3840, 534 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)
  
      Metadata:
  
        creation_time   : 2018-01-17T06:39:29.000000Z
  
        handler_name    : Alias Data Handler
  
        encoder         : AVC Coding
  
      Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 317 kb/s (default)
  
      Metadata:
  
        creation_time   : 2018-01-17T06:39:29.000000Z
  
        handler_name    : Alias Data Handler
  
  File 'a.mp4' already exists. Overwrite ? [y/N] y
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  
    Stream #0:1 -> #0:1 (aac (native) -> aac (native))
  
  Press [q] to stop, [?] for help
  
  [libx264 @ 0x66327c0] frame MB size (68x120) > level limit (1620)
  
  [libx264 @ 0x66327c0] DPB size (1 frames, 8160 mbs) > level limit (0 frames, 8100 mbs)
  
  [libx264 @ 0x66327c0] MB rate (244800) > level limit (40500)
  
  [libx264 @ 0x66327c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
  
  [libx264 @ 0x66327c0] ratecontrol_init: can't open stats file
  
  Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
  
  Conversion failed!

• Thinking about switching to GeoIP2 for better location detection ? Here’s what you should know

  5 juin 2018, par Matomo Core Team

  In Matomo 3.5.0 we added a new feature to improve the location detection (country, region, city) of your visitors. Especially when it comes to IPv6 addresses, you will see less “Unknown” locations and more accurate results in general. This feature is now enabled for all new installations but needs to be manually enabled for existing Matomo self-hosted users.

  

  Why is the Matomo plugin not enabled for existing users ?

  When you enable the GeoIP2 plugin, a database update will need to be executed on two datatable tables (“log_visit” and “log_conversion”) which stores some of the raw data. Please be aware that this update could take several hours depending on the size of your database.

  If you store many visits in your database, it is recommended to execute the update through the command line by executing the command ./console core:update to avoid the update from timing out. You may also have to put your Matomo into maintenance mode during this time and replay the missed traffic from logs afterwards as explained in the FAQ article.

  GeoIP2 may slow down your tracking

  In the past we have seen that a few Matomo databases with high traffic volumes struggle to handle all the tracking requests after enabling GeoIP2. The reason for this is the location database now contains many more entries because it has to store all the IPv6 addresses and the database itself has a different format. Hence, the location lookup takes longer.

  It is hard to say how much slower the location lookup gets, but we found GeoIP2-PHP is about 20 times slower than GeoIP1-PHP. On a fast CPU the lookup time for an IP with GeoIP2 takes about 1ms, but can also take much longer depending on the server.

  Making location lookups fast again

  There is a PHP extension available that makes lookups very fast, even faster than the old GeoIP1-PHP provider. If you can install additional PHP extensions on your server and have a high traffic website, you may want to install the GeoIP2 extension.

  There is also an Nginx module and an Apache module. Unfortunately, we don’t have any performance metrics for these providers.

  How do I activate the GeoIP2 location provider ?

  As a Super User, log in to your Matomo and go to “Administration => Plugins”. There you can activate the “GeoIP2” plugin. As mentioned, this will trigger a database update which can take a while and you may want to perform this update through the command line.

  Now you can go to “Administration => Geolocation”. Here you will first need to install the GeoIP2 databases at the bottom of the page before you can activate the GeoIP2-PHP provider. To activate any of the other GeoIP2 providers, you will need to install the required modules.

  You will be able to check if the detection works on the right next to location provider. Once you selected one of the available providers, you’re all good to go.

  The post Thinking about switching to GeoIP2 for better location detection ? Here’s what you should know appeared first on Analytics Platform - Matomo.

• Video files recorded in Google Chrome have stuttering audio

  4 juin 2018, par maxpaj

  Background

  I’m developing a platform where users can record videos of themselves or their screen and send them as video messages to customers / clients.

  I have limited users to only using my application with Google Chrome and I’m using the MediaRecorder API to record the video data from the users screen or webcamera. The codecs that are used for recording are VP8/OPUS (WEBM container).

  I need the videos to run in as many browsers as possible, so I’m using a 3rd party service to transcode videos from whatever format I’m getting from the users to a H.265/AAC MP4 container (caniuse MPEG-4/H.264).

  Issue

  Lately I’ve seen that some videos recorded on Mac OSX machines have the video and audio out of sync or that the video and audio stutters, depending on which player I’m using. I call these video files corrupt, for lack of a better word. Playing a corrupt file in Google Chrome renders smooth playing audio. Playing the video in VLC on my Windows machine renders stuttering audio.

  When I run the corrupt video files through the transcoding service I get video files with stuttering audio, no matter which player I’m using.

  This is an unwanted result and pretty much unacceptable since the audio needs to be smooth in order for the recipient of a video to not be bothered with the quality.

  Debugging

  According to the transcoding service support, this happens because of their mechanisms that try to sync up the audio and video from the corrupt file :

  Inspecting our encoding logs, I’ve noticed the following kind of
  warnings :

  [2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0] pcm_encode_frame :
  filling in for 5856 missing samples (122 ms) before pts 40800 to
  correct sync ! [2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0]
  pcm_encode_frame : dropping 2880 samples (60 ms) at pts 43392 to help
  correct sync to -3168 samples (-66 ms) !

  The problem here comes from the way that the audio in the original
  source file is encoded.

  -

  you should ensure that the audio is not out of sync (audio timestamps
  are correct) in your source file before submitting the job

  Running a corrupt file through ffmpeg on my own machine, re-encoding with the same codecs, produces the same kind of stuttering video. The logs produce an alarming amount of errors. Here is a sample of the log output :

  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 194.8kbits/s dup=0 drop=5 speed=0.31x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15394; changing to 15434. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15414; changing to 15434. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 193.3kbits/s dup=0 drop=5 speed=0.309x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15499; changing to 15539. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15519; changing to 15539. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 192.0kbits/s dup=0 drop=5 speed=0.308x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15627; changing to 15667. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15647; changing to 15667. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in time

  I tried running the same inputs through another transcoding service and those outputs worked a lot better - video was still stuttering but the audio played smoothly, which is more important to the use case of my application.

  To my knowledge, this have so far only occurred for users on Mac OSX machines.

  Questions

  1. Is there anything I can do to have the files work better ? Or is this entirely a consequence of how encoding of video and audio in Google Chrome works ?

  2. One step in the right direction would be to just be able to detect when the video is corrupt. How can I do that ?