Recherche avancée

Sur d’autres sites (7973)

• Revision ad484fc6be : Add support for armv7-win32-vs11 The arm assembly files are named .s after conv

  18 mai 2013, par Martin Storsjo

  Changed Paths :
   Add /build/arm-msvs/obj_int_extract.bat

  
   Modify /build/make/Makefile

  
   Modify /build/make/configure.sh

  
   Modify /build/make/gen_msvs_vcxproj.sh

  
   Modify /configure

  
   Modify /libs.mk

  
  
  Add support for armv7-win32-vs11

  The arm assembly files are named .s after conversion, to reuse
  as much of the existing makefile infrastructure for conversion to
  gas format as possible. Within the generated visual studio project,
  only the converted assembly sources are available, which might not
  be optimal for actually developing it, but is acceptable for
  just building the library.

  Multithreading is disabled since the traditional win32 threading
  functions aren't available on WinRT/Windows Phone 8.

  Building of vpx itself and the examples succeed, while building the
  tests fail due to them using functions not available in the
  windows store/windows phone API subsets - therefore the unit tests
  are disabled.

  This works for building in Visual Studio Express 2012 for Windows
  Phone, while Visual Studio Express 2012 for Windows 8 (for
  "Windows Store" apps) seems to reject the vcxproj files due to
  not supporting "classic style native application or managed
  projects". The built static library should be compatible with that
  platform though.

  Change-Id : Idcd7eca60bfaaaeb09392a9cd7a02e4a670e3b30

• Using ffmpeg.exe making the computer slow in task manager it takes over 1GB of memory how can i fix it ?

  29 mai 2013, par Revuen Ben Dror

  In mt Form1 i have this code :

  private void StartRecording_Click(object sender, EventArgs e)
  
          {
  
  
  
              ffmp.Start("test.avi", 25);
  
              timer1.Enabled = true;
  
          }

  ffmp is a variable of my class : Ffmpeg
  In this class i add frames to a pipe and create an avi file.

  using System;
  
  using System.Collections.Generic;
  
  using System.Linq;
  
  using System.Text;
  
  using System.Threading.Tasks;
  
  using System.Drawing;
  
  using System.IO.Pipes;
  
  using System.Runtime.InteropServices;
  
  using System.Diagnostics;
  
  
  
  namespace ScreenVideoRecorder
  
  {
  
      class Ffmpeg
  
      {
  
          NamedPipeServerStream p;
  
          String pipename = "mytestpipe";
  
          byte[] b;
  
          System.Diagnostics.Process process;
  
  
  
          public Ffmpeg()
  
          {
  
  
  
          }
  
  
  
          public void Start(string FileName, int BitmapRate)
  
          {
  
              p = new NamedPipeServerStream(pipename, PipeDirection.Out, 1, PipeTransmissionMode.Byte);
  
              b = new byte[1920 * 1080 * 3]; // some buffer for the r g and b of pixels of an image of size 720p 
  
              process = new System.Diagnostics.Process();
  
              process.StartInfo.FileName = @"D:\pipetest\pipetest\ffmpegx86\ffmpeg.exe";
  
              process.EnableRaisingEvents = false;
  
              process.StartInfo.WorkingDirectory = @"D:\pipetest\pipetest\ffmpegx86";
  
              process.StartInfo.Arguments = @"-f rawvideo -pix_fmt bgr0 -video_size 1920x1080 -i \\.\pipe\mytestpipe -map 0 -c:v libx264 -r " + BitmapRate + " " + FileName;
  
              process.Start();
  
  
  
              process.StartInfo.UseShellExecute = false;
  
              process.StartInfo.CreateNoWindow = false;
  
  
  
              p.WaitForConnection();
  
          }
  
  
  
          public void PushFrame(Bitmap bmp)
  
          {
  
  
  
              int length;
  
              // Lock the bitmap's bits.
  
              Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
  
              //Rectangle rect = new Rectangle(0, 0, 1280, 720);
  
              System.Drawing.Imaging.BitmapData bmpData =
  
                  bmp.LockBits(rect, System.Drawing.Imaging.ImageLockMode.ReadOnly,
  
                  bmp.PixelFormat);
  
  
  
              int absStride = Math.Abs(bmpData.Stride);
  
              // Get the address of the first line.
  
              IntPtr ptr = bmpData.Scan0;
  
  
  
              // Declare an array to hold the bytes of the bitmap.
  
              //length = 3 * bmp.Width * bmp.Height;
  
              length = absStride * bmpData.Height;
  
              byte[] rgbValues = new byte[length];
  
  
  
              int j = bmp.Height - 1;
  
              for (int i = 0; i < bmp.Height; i++)
  
              {
  
                  IntPtr pointer = new IntPtr(bmpData.Scan0.ToInt32() + (bmpData.Stride * j));
  
                  System.Runtime.InteropServices.Marshal.Copy(pointer, rgbValues, absStride * (bmp.Height - i - 1), absStride);
  
                  j--;
  
              }
  
  
  
              p.Write(rgbValues, 0, length);
  
  
  
              bmp.UnlockBits(bmpData);
  
  
  
          public void Close()
  
          {
  
              p.Close();
  
          }
  
      }
  
  }

  The problem is when i'm running my application in this from my visual studio 2012 pro and click the button it's openning a console window and start the processing .

  I tracked over it through the task manager on ffmpeg.exe and saw that it started from 996mb and very quick jumped ot 1040mb memory usage. The cpu usage was only 16%

  Once i close ended this task the ffmpeg.exe everything was back to move smooth.
  When it's working and i tried to drag my Form around the screen for example it was moving slow and also with some stuttering .

  Closed the ffmpeg.exe and i could drag the Form around smooth and quick like in regular way as it should be.

  I tried to google for it and found some others with the same problem i think but i'm not sure where is the problem and how to fix it.

  I'm not sure what version of ffmpeg.exe i have i'm using now but i read in some places that it's not working better with new versions but maybe i mistake here .

  My windows is 8 with 6gb of ram .

• How To Play Hardware Accelerated Video on A Mac

  28 mai 2013, par Multimedia Mike — General

  I have a friend who was considering purchasing a Mac Mini recently. At the time of this writing, there are 3 desktop models (and 2 more “server” models).

  
  
  

  The cheapest one is a Core i5 2.5 GHz. Then there are 2 Core i7 models : 2.3 GHz and 2.6 GHz. The difference between the latter 2 is US$100. The only appreciable technical difference is the extra 0.3 GHz and the choice came down to those 2.

  He asked me which one would be able to play HD video at full frame rate. I found this query puzzling. But then, I have been “in the biz” for a bit too long. Whether or not a computer or device can play a video well depends on a lot of factors.

  Hardware Support
  First of all, looking at the raw speed of the general-purpose CPU inside of a computer as a gauge of video playback performance is generally misguided in this day and age. In general, we have a video standard (H.264, which I’ll focus on for this post) and many bits of hardware are able to accelerate decoding. So, the question is not whether the CPU can decode the data in real time, but can any other hardware in the device (likely the graphics hardware) handle it ? These machines have Intel HD 4000 graphics and, per my reading of the literature, they are capable of accelerating H.264 video decoding.

  Great, so the hardware supports accelerated decoding. So it’s a done deal, right ? Not quite…

  Operating System Support
  An application can’t do anything pertaining to hardware without permission from the operating system. So the next question is : Does Mac OS X allow an application to access accelerated video decoding hardware if it’s available ? This used to be a contentious matter (notably, Adobe Flash Player was unable to accelerate H.264 playback on Mac in the absence of such an API) but then Apple released an official API detailed in Technical Note TN2267.

  So, does this mean that video is magically accelerated ? Nope, we’re still not there yet…

  Application Support
  It’s great that all of these underlying pieces are in place, but if an individual application chooses to decode the video directly on the CPU, it’s all for naught. An application needs to query the facilities and direct data through the API if it wants to leverage the acceleration. Obviously, at this point it becomes a matter of “which application ?”

  My friend eventually opted to get the pricier of the desktop Mac Mini models and we ran some ad-hoc tests since I was curious how widespread the acceleration support is among Mac multimedia players. Here are some programs I wanted to test, playing 1080p H.264 :

  • Apple QuickTime Player
  • VLC
  • YouTube with Flash Player (any browser)
  • YouTube with Safari/HTML5
  • YouTube with Chrome/HTML5
  • YouTube with Firefox/HTML5
  • Netflix

  I didn’t take exhaustive notes but my impromptu tests revealed QuickTime Player was, far and away, the most performant player, occupying only around 5% of the CPU according to the Mac OS X System Profiler graph (which is likely largely spent on audio decoding).

  VLC consistently required 20-30% CPU, so it’s probably leveraging some acceleration facilities. I think that Flash Player and the various HTML5 elements performed similarly (their multi-process architectures can make such a trivial profiling test difficult).

  The outlier was Netflix running in Firefox via Microsoft’s Silverlight plugin. Of course, the inner workings of Netflix’s technology are opaque to outsiders and we don’t even know if it uses H.264. It may very well use Microsoft’s VC-1 which is not a capability provided by the Mac OS X acceleration API (it doesn’t look like the Intel HD 4000 chip can handle it either). I have never seen any data one way or another about how Netflix encodes video. However, I was able to see that Netflix required an enormous amount of CPU muscle on the Mac platform.

  Conclusion
  The foregoing is a slight simplification of the video playback pipeline. There are some other considerations, most notably how the video is displayed afterwards. To circle back around to the original question : Can the Mac Mini handle full HD video playback ? As my friend found, the meager Mac Mini can do an admirable job at playing full HD video without loading down the CPU.