Recherche avancée

Sur d’autres sites (14966)

• Grow your business and understand your conversion funnel with Funnels for Piwik

  14 décembre 2016, par InnoCraft — Plugins

  Hi, this is Tom from InnoCraft. The company of the makers of Piwik.

  No matter what type of website or app you have, whether you are trying to get your users to sign up for something or sell products, there is a certain number of steps your visitors have to go through. I bet the same applies to you.

  Have you ever wondered if your visitors or users actually follow that path in your website or app ? And wondered where you lose your visitors ? Where they maybe get confused ? Want to see when something is not working anymore ? Maybe you have a multi step signup form or onboarding process ? On every step you lose visitors and therefore potential revenue and conversions. It’s critical to know how well your visitors go through these steps, where they originally came from and where they go to when they drop off.

  If you are wondering about such things like we do, or want to drive your conversions and sales, we have something for you.

  -> Read the rest of the story on the Funnels Marketplace page.

  What does the new Funnel report look like ?

  Here is below just a little preview of the Funnel report.

  

  You get this funnel report for each of your goals so you can optimise each of your conversion funnels.

  Where do I get Funnel for Piwik ?

  Funnels is available on the Piwik Marketplace :

  Get Funnel on the Marketplace

  Funnels is premium plugin for Piwik and comes with our 14 day money back guarantee and 1-click installation & updates (all product updates come for free).

  You can also signup for a free Piwik Cloud-hosted trial to discover the power of Funnels !

• fate/mxf : Fix d10-user-comments test

  4 décembre 2020, par Andreas Rheinhardt

  fate/mxf : Fix d10-user-comments test
  The mxf_d10 muxer is very picky regarding the input it accepts :
  
  The only video accepted is MPEG-2 with absolutely constant bitrate,
  
  i.e. all packets need to have exactly the same size ; and only a few
  
  bitrates are accepted.
  The sample file used did not abide by this : Writing the first packet
  
  (a video packet) errors out and afterwards an audio packet from the
  
  muxing queue has been written. That's all besides metadata (which this
  
  test is about). The FFmpeg cli returned an error, but said error has
  
  been ignored by the md5 test.
  This commit changes the test to actually send a compliant stream to the
  
  muxer, so that it does not error out ; furthermore, the test is changed
  
  to explicitly check the metadata instead of it only being implicitly
  
  included in the md5 checksum. The compliant stream is created by our
  
  encoder at runtime.
  Finally, the test now also covers writing user-specified
  
  product/company/version identification.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] tests/fate/mxf.mak
  • [DH] tests/ref/fate/mxf-d10-user-comments

• What's FFmpeg doing with avcodec_send_packet() ?

  4 avril, par Jim

  I'm trying to optimise a piece of software for playing video, which internally uses the FFmpeg libraries for decoding. We've found that on some large (4K, 60fps) video, it sometimes takes longer to decode a frame than that frame should be displayed for ; sadly, because of the problem domain, simply buffering/skipping frames is not an option.

  


  However, it appears that the FFmpeg executable is able to decode the video in question fine, at about 2x speed, so I've been trying to work out what we're doing wrong.

  


  I've written a very stripped-back decoder program for testing ; the source is here (it's about 200 lines). From profiling it, it appears that the one major bottleneck during decoding is the avcodec_send_packet() function, which can take up to 50ms per call. However, measuring the same call in FFmpeg shows strange behaviour :

  


  

  


  (these are the times taken for each call to avcodec_send_packet() in milliseconds, when decoding a 4K 25fps VP9-encoded video.)

  


  Basically, it seems that when FFmpeg uses this function, it only really takes any amount of time to complete every N calls, where N is the number of threads being used for decoding. However, both my test decoder and the actual product use 4 threads for decoding, and this doesn't happen ; when using frame-based threading, the test decoder behaves like FFmpeg using only 1 thread. This would seem to indicate that we're not using multithreading at all, but we've still seen performance improvements by using more threads.

  


  FFmpeg's results average out to being about twice as fast overall as our decoders, so clearly we're doing something wrong. I've been reading through FFmpeg's source to try to find any clues, but it's so far eluded me.

  


  My question is : what's FFmpeg doing here that we're not ? Alternatively, how can we increase the performance of our decoder ?

  


  Any help is greatly appreciated.