Recherche avancée

Sur d’autres sites (11651)

• ffmpeg mp4 shows blurred frames after seeking in the video with internet explorer

  21 février 2014, par Larzzz

  I have a question regarding JWPlayer 5, IE and video encoding.
  Basicly I use a Wowza server to stream my files. This works on all devices (windows, iOS and Android).
  However when i play it in Internet Explorer, it behaves strange.
  It plays fine, and the entire movie looks good without any issues. But when I seek in the video, it shows a line in the center of my video, like if the previous frame is still showing some part, and it refreshes after a few frames move in the video.
  The frames itself are not broken, as if i just play the video without seeking it all looks good.
  This does not happen in Chrome, Firefox or Safari, neither does this happen on android & iOS.
  I've tested this with JW 6 as well, and it shows the same results for IE.

  Altough it's showing fine on other browsers, I still believe it's an issue with encoding, as other videos do not show this behavior.

  Example viewable here : http://www.mobileevolution.be/standardcode-withsmil.html

  The FFMPEG code i use to convert any file (.avi in this case) to an MP4 :

  "ffmpeg.exe" -i "%1" -vcodec libx264 -strict experimental -c:a aac -profile:v baseline -level 3 -movflags faststart -bufsize 1000k -tune zerolatency -b:v 1000k -minrate 600k -maxrate 1500k "%5%71000k.mp4"

  the %1, %5 and %7 are variables i send with a script.

  I have tried various options, but could not figure out what the problem is.
  I have also tried converting with handbrake, but this shows similar results.

  My questions are :
  Has anyone seen this before ?
  Does anyone know a solution ?
  What's wrong with my FFMPEG settings ?

  Thanks for any help,
  Grts

  EDIT
  pictures :
  http://www.mobileevolution.be/foto1.jpg
  http://www.mobileevolution.be/foto2.jpg
  console output :
  http://www.mobileevolution.be/consoleoutput.txt

• Revision b6c75c5a8d : Improve motion detection for low complexity regions. Where there is very subtle

  11 décembre 2014, par Paul Wilkins

  Changed Paths :
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Improve motion detection for low complexity regions.

  Where there is very subtle motion, especially when combined
  with low spatial complexity, the codec sometimes fails to quickly
  pick up the ambient motion field.

  Once it has been established though the field propagates well using
  Nearest and Near MV.

  This patch looks specifically at the case where the Nearest and Near
  have not been established as non zero vectors and in this case
  discounts the cost of searching for a new vector in the rd code.

  This will almost certainly have some implications in terms of encode
  speed but it should be possible to mitigate the impact in a subsequent
  using first pass stats and the local spatial complexity.

  Average results for test sets approximately neutral.

  Change-Id : I44a29e20f11f7ab10f8c93ffbdc50183d9801524

• Do i still need to convert ffmpeg's RGB frame to YUV for SDL2.0 ?

  19 avril 2013, par James491

  I've been following dranger's ffmpeg tutorial and a few other sdl2.0 tutorials and noticed that they all still use the sws_scale function to convert ffmpeg's decoded frame from RGB to YUV even for an SDL_texture. Is this still the best method for video with textures ? Because you can eliminate all of the scaling by setting the SDL_PIXELFORMAT of the texture to an rgb format and then copy ffmpeg's rgb directly without scaling. Am i missing something ? Is yuv faster or better in any way for sdl ? Or are other people just used to using an SDL_YUVOverlay ?

  UPDATE : I noticed that the direct copy only works for scenarios when the AVFrame linesize is equal to the pitch. When and how does this happen ?