Recherche avancée

Sur d’autres sites (3241)

• arm : vp9itxfm16 : Do a simpler half/quarter idct16/idct32 when possible

  24 février 2017, par Martin Storsjö

  arm : vp9itxfm16 : Do a simpler half/quarter idct16/idct32 when possible
  This work is sponsored by, and copyright, Google.
  This avoids loading and calculating coefficients that we know will
  
  be zero, and avoids filling the temp buffer with zeros in places
  
  where we know the second pass won’t read.
  This gives a pretty substantial speedup for the smaller subpartitions.
  The code size increases from 14516 bytes to 22484 bytes.
  The idct16/32_end macros are moved above the individual functions ; the
  
  instructions themselves are unchanged, but since new functions are added
  
  at the same place where the code is moved from, the diff looks rather
  
  messy.
  Before :                                 Cortex A7       A8       A9      A53
  
  vp9_inv_dct_dct_16x16_sub1_add_10_neon :     454.0    270.7    418.5    295.4
  
  vp9_inv_dct_dct_16x16_sub2_add_10_neon :    3840.2   3244.8   3700.1   2337.9
  
  vp9_inv_dct_dct_16x16_sub4_add_10_neon :    4212.5   3575.4   3996.9   2571.6
  
  vp9_inv_dct_dct_16x16_sub8_add_10_neon :    5174.4   4270.5   4615.5   3031.9
  
  vp9_inv_dct_dct_16x16_sub12_add_10_neon :   5676.0   4908.5   5226.5   3491.3
  
  vp9_inv_dct_dct_16x16_sub16_add_10_neon :   6403.9   5589.0   5839.8   3948.5
  
  vp9_inv_dct_dct_32x32_sub1_add_10_neon :    1710.7    944.7   1582.1   1045.4
  
  vp9_inv_dct_dct_32x32_sub2_add_10_neon :   21040.7  16706.1  18687.7  13193.1
  
  vp9_inv_dct_dct_32x32_sub4_add_10_neon :   22197.7  18282.7  19577.5  13918.6
  
  vp9_inv_dct_dct_32x32_sub8_add_10_neon :   24511.5  20911.5  21472.5  15367.5
  
  vp9_inv_dct_dct_32x32_sub12_add_10_neon :  26939.5  24264.3  23239.1  16830.3
  
  vp9_inv_dct_dct_32x32_sub16_add_10_neon :  29419.5  26845.1  25020.6  18259.9
  
  vp9_inv_dct_dct_32x32_sub20_add_10_neon :  31146.4  29633.5  26803.3  19721.7
  
  vp9_inv_dct_dct_32x32_sub24_add_10_neon :  33376.3  32507.8  28642.4  21174.2
  
  vp9_inv_dct_dct_32x32_sub28_add_10_neon :  35629.4  35439.6  30416.5  22625.7
  
  vp9_inv_dct_dct_32x32_sub32_add_10_neon :  37269.9  37914.9  32271.9  24078.9
  After :
  
  vp9_inv_dct_dct_16x16_sub1_add_10_neon :     454.0    276.0    418.5    295.1
  
  vp9_inv_dct_dct_16x16_sub2_add_10_neon :    2336.2   1886.0   2251.0   1458.6
  
  vp9_inv_dct_dct_16x16_sub4_add_10_neon :    2531.0   2054.7   2402.8   1591.1
  
  vp9_inv_dct_dct_16x16_sub8_add_10_neon :    3848.6   3491.1   3845.7   2554.8
  
  vp9_inv_dct_dct_16x16_sub12_add_10_neon :   5703.8   4831.6   5230.8   3493.4
  
  vp9_inv_dct_dct_16x16_sub16_add_10_neon :   6399.5   5567.0   5832.4   3951.5
  
  vp9_inv_dct_dct_32x32_sub1_add_10_neon :    1722.1    938.5   1577.3   1044.5
  
  vp9_inv_dct_dct_32x32_sub2_add_10_neon :   15003.5  11576.8  13105.8   9602.2
  
  vp9_inv_dct_dct_32x32_sub4_add_10_neon :   15768.5  12677.2  13726.0  10138.1
  
  vp9_inv_dct_dct_32x32_sub8_add_10_neon :   17278.8  14825.4  14907.5  11185.7
  
  vp9_inv_dct_dct_32x32_sub12_add_10_neon :  22335.7  21544.5  20379.5  15019.8
  
  vp9_inv_dct_dct_32x32_sub16_add_10_neon :  24165.6  23881.7  21938.6  16308.2
  
  vp9_inv_dct_dct_32x32_sub20_add_10_neon :  31082.2  30860.9  26835.3  19711.3
  
  vp9_inv_dct_dct_32x32_sub24_add_10_neon :  33102.6  31922.8  28638.3  21161.0
  
  vp9_inv_dct_dct_32x32_sub28_add_10_neon :  35104.9  34867.5  30411.7  22621.2
  
  vp9_inv_dct_dct_32x32_sub32_add_10_neon :  37438.1  39103.4  32217.8  24067.6
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/arm/vp9itxfm_16bpp_neon.S

• 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 .

• avformat/matroskaenc : Actually apply timestamp offset for Opus

  31 août 2022, par Andreas Rheinhardt

  avformat/matroskaenc : Actually apply timestamp offset for Opus
  Matroska generally requires timestamps to be nonnegative, but
  
  there is an exception : Data that corresponds to encoder delay
  
  and is not supposed to be output anyway can have a negative
  
  timestamp. This is achieved by using the CodecDelay header
  
  field : The demuxer has to subtract this value from the raw
  
  (nonnegative) timestamps of the corresponding track.
  
  Therefore the muxer has to add this value first to write
  
  this raw timestamp.
  Support for writing CodecDelay has been added in FFmpeg commit
  
  d92b1b1babe69268971863649c225e1747358a74 and in Libav commit
  
  a1aa37dd0b96710d4a17718198a3f56aea2040c1. The former simply
  
  wrote the header field and did not apply any timestamp offsets,
  
  leading to desynchronisation (if one uses multiple tracks).
  
  The latter applied it at two places, but not at the one where
  
  it actually matters, namely in mkv_write_block(), leading to
  
  the same desynchronisation as with the former commit. It furthermore
  
  used the wrong stream timebase to convert the delay to the
  
  stream's timebase, as the conversion used the timebase from
  
  before avpriv_set_pts_info().
  When the latter was merged in 82e4f39883932c1b1e5c7792a1be12dec6ab603d,
  
  it was only done in a deactivated state that still did not
  
  offset the timestamps when muxing due to "assertion failures
  
  and av sync errors". a1aa37dd0b96710d4a17718198a3f56aea2040c1
  
  made it definitely more likely to run into assertion failures
  
  (namely if the relative block timestamp doesn't fit into an int16_t).
  Yet all of the above issues have been fixed (in commits
  
  962d63157322466a9a82f9f9d84c1b6f1b582f65,
  
  5d3953a5dcfd5f71391b7f34908517eb6f7e5146 and
  
  4ebeab15b037a21f195696cef1f7522daf42f3ee. This commit therefore
  
  enables applying CodecDelay, fixing ticket #7182.
  There is just one slight regression from this : If one has input
  
  with encoder delay where the first timestamp is negative, but
  
  the pts of the part of the data that is actually intended to be
  
  output is nonnegative, then the timestamps will currently by default
  
  be shifted to make them nonnegative before they reach the muxer ;
  
  the muxer will then ensure that the shifted timestamps are retained.
  
  Before this commit, the muxer did not ensure this ; instead the
  
  timestamps that the demuxer will output were shifted and
  
  if the first timestamp of the actually intended output was zero
  
  before shifting, then this unintentional shift just cancels
  
  the shift performed before the packet reached the muxer.
  
  (But notice that this only applies if all the tracks use the same
  
  CodecDelay, or the relative sync between tracks will be impaired.)
  
  This happens in the matroska-opus-remux and matroska-ogg-opus-remux
  
  FATE tests. Future commits will forward the information that
  
  the Matroska muxer has a limited capability to handle negative
  
  timestamps so that the shifting in libavformat can take advantage
  
  of it.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/matroskaenc.c
  • [DH] tests/ref/fate/matroska-ogg-opus-remux
  • [DH] tests/ref/fate/matroska-opus-remux