Recherche avancée

Sur d’autres sites (9669)

• MPlayer not playing HTTP video stream for a specific type of content from the same source

  2 août 2017, par Joel

  Implementation overview

  Before I dive into the question, I need to establish the context from the start.

  I am currently implementing a cloud gaming solution utilising the following :

  • Nvidia Capture SDK
  • Nvidia Video Codec SDK
  • FFmpeg
  • MPlayer

  The Nvidia Capture SDK is used to produce a shim layer (via DXGI.dll), intercepting and capturing DirectX frames so that they can be passed to the Nvidia Video Codec SDK to be encoded into an h264 video format. All this is done within DXGI.dll.

  I then pass the encoded video to FFmpeg. FFmpeg acts as an HTTP server that broadcasts the video stream for MPlayer to play.

  Problem

  I am running an Unreal Engine 4 game called "Epic Survival Game Series". The Nvidia Capture SDK’s shim layer kicks off when the game starts, and FFmpeg launches the HTTP server to start streaming. However, when I start MPlayer to receive the stream, MPlayer stops at the following message, and nothing happens after that.

  libavformat version 57.72.101 (internal)
Stream not seekable!
H264-ES file format detected

  The thing is, when I play the same video using ffplay, it works without any issue. This is not the only quirk. When I launch a different Unreal Engine 4 game called "First Person Shooter Template", MPlayer can play that video as well. Also, if I modify the Survival Game to load directly into the game level by skipping the menu, MPlayer is also able to play the video.

  Using FFmpeg to write the video to a file instead of streaming it to a video also works, no matter the game or whether I loaded into the menu or game level.

  This is very strange and I do not have any idea why this is the case. Any ideas ?

  Edit : One strange quirk I forgot to mention is that MPlayer does manage to play the video in very rare occasions - maybe once every 10-20 tries or so.

  Implementation Details

  Additional details of how certain parts are implemented.

  (1) For the Nvidia Capture SDK, I use the provided DXIFRShim example that is provided in the SDK

  (2) for the Nvidia Video Codec SDK, I use the provided NvEncoder example that is provided in the SDK

  (3) The FFmpeg command I use is this :
  ffmpeg -i - -listen 1 -threads 1 -vcodec copy -preset ultrafast -an -tune zerolatency -f h264 http://address:port
  The encoded frames from Nvidia Video Codec SDK is piped to FFmpeg.

  (4) The MPlayer command I use is this :
  mplayer -quiet -vo gl -nosound -benchmark http://address:port

  Things I’ve tried

  I am suspecting MPlayer to be the cause, so I’ve only played around with MPlayer parameters.
  mplayer http://address:port

  mplayer -fps 30 -vo gl -nosound -benchmark http://address:port

  mplayer -fps 30 -screenw 720 -screenh 1280 -vo gl -nosound -benchmark http://address:port

  mplayer -fps 30 -vo directx -nosound -benchmark http://address:port

  mplayer -fps 30 -vo null -nosound -benchmark http://address:port

  None of these worked.

• How to make high smooth, high resolution particle motion animations

  5 décembre 2019, par algae

  For some time I have been having trouble with producing short movies/animations/gifs which are of sufficiently high resolution. I’m going to use R to generate some frames as a random example, but if there is somewhere else I should be creating frames from to give better results I would be interested in that too.

  Creating frames

  The kinds of animations I’m interested involve some cloud of ’particles’ moving about the page. There are usually a large number of particles and I would like their motion be as smooth as possible. As a random example, consider the R code (using base graphics and not ggplot2 as it is far quicker for saving a large number of frames)

  N <- 500
  
  nFrames <- 250
  
  points <- pracma::randp(n=N, r=1)
  
  rot <- function(p, a) { return(cbind(p[,1]*cos(a) - p[,2]*sin(a), p[,1]*sin(a) + p[,2]*cos(a))) }
  
  cols <- colorRampPalette(c("red", "green", "blue"))(nFrames)
  
  ang <- seq(0, pi, length=N)
  
  
  
  # Save frames
  
  png(filename="%d.png")
  
  par(mar=c(0,0,0,0))
  
  for (i in seq(1,N,length=nFrames)) 
  
          plot(sqrt(i)*rot(points, ang[i]), xlim=sqrt(N)*c(-1,1),  ylim=sqrt(N)*c(-1,1), cex=0.5, pch=19, col=cols[i], asp=1, xaxs="i")
  
  
  
  dev.off()

  Frames to animation

  There are a number of tools available to chain each frame together into an animation (in R there are also things like gganimate which I have tried but did not find convenient or better than the following). I also don’t have any requirements for the resulting file size or time taken to get everything looking as crisp as possible.

  convert

  For short gif style animations a common solution is to do something like convert -delay 1 -loop 0 *.png g.gif which gives

  

  gifski

  Running gifski -o g.gif *.png produces

  

  There is an annoying amount of ’jitter’ happening in the transition between frames in both of the above (though less noticeable with gifski).

  ffmpeg

  Being gifs, the above will be have limited options for tweaking so I suspect part of the solution lies in using ffmpeg. All I would like to know is how to make the animation appear totally smooth without any kind of noticeable blurriness. Here the resulting movies tend to be quite smooth, but resolution is lacking.. e.g. after setting height=1080 and width=1080 in png() of the above code we can run

  fmpeg -i %d.png -s 1080x1080 -c:v libx264 -vf fps=250 -pix_fmt yuv444p out.mp4

  If the particles move on a time/space scale smaller than is visible to the naked eye, and we set the frames per second to be the total number of frames, the transition between frames should be seamless, right ? At around the 2 second mark in out.mp4 you will see some kind of frame drop and similarly right at the beginning. Why does this happen ?

  Questions

  1. Is there a standard documented approach to generating high quality animations/movies involving large numbers of ’point-like’ particles ? Do we need more an more frames ?
  2. How to improve resolution of movies using ffmpeg ? Should I change from .png format to something vectorised (if so, how) ?

  Running Fedora v31.

• Performance optimizations you can apply today to load the Piwik JavaScript tracker faster

  20 avril 2017, par InnoCraft — Community, Development

  When you track your website with Piwik or any other analytics solution, you need to embed a JavaScript file in order to track page views, events, clicks, and more. At InnoCraft, it is our daily business to help Piwik users to make the most out of their Piwik. We often see similar problems of websites loading unnecessarily slower because the tracking file is not loaded as fast as it should be. There are many ways you can improve the performance but avoiding the most important mistakes will help you to not lose revenue and conversions because of this today. Below you find a few steps that will boost the loading of your Piwik JavaScript tracking file.

  Cache piwik.js

  The most important step is to make sure to configure your server in a way so the piwik.js JavaScript tracker file will be cached once it has been loaded and not requested again on subsequent page views. Learn more about browser caching.

  Enable GZIP

  We recommend enabling GZIP as it reduces the size the user needs to load when the piwik.js file is requested. For the standard Piwik tracker, this will reduce the size from about 60KB to 20KB.

  Preload DNS

  Often a Piwik is hosted on a different domain and when the browser loads the JavaScript tracker file, it needs to first perform a DNS lookup to find the IP address for this domain. By adding the below snipped for your Piwik domain, it can boost the performance of loading the tracker file by 10ms to 50ms.

  <link rel="dns-prefetch" href="//example.innocraft.cloud">

  Preload resource

  To boost the loading of the Piwik tracking file, you can add the following HTML into the header of your website :

  <link rel="preload" href="https://yourpiwikdomain.com/piwik.js" onload="embedTracker()" type="script" crossorigin>

  In Chrome, Opera, and soon in more browsers this will load the JavaScript tracker file without blocking the “onload” event. As a result, as soon as you embed the tracking code, the JavaScript tracker might be already loaded. How “preloading” affects your website always depends and maybe you rather want to preload more important resources than the tracking code, but it is an option to consider. If you load your JavaScript tracker file in the <head> of your website, this should not be needed.

  Advanced options

  If you want to go even further, you can think about serving the JavaScript tracking file via a CDN, merging the JavaScript tracker file content with your other JavaScript files, making use of service workers (and even track data offline), and more. Feel free to get in touch with us if you have any questions.

  More performance improvements

  Read our first blog in the series at Different ways of embedding the Piwik tracking code for faster website performance