Recherche avancée

Sur d’autres sites (3942)

• aarch64 : vp9 : Implement NEON loop filters

  13 novembre 2016, par Martin Storsjö

  aarch64 : vp9 : Implement NEON loop filters
  This work is sponsored by, and copyright, Google.
  These are ported from the ARM version ; thanks to the larger
  
  amount of registers available, we can do the loop filters with
  
  16 pixels at a time. The implementation is fully templated, with
  
  a single macro which can generate versions for both 8 and
  
  16 pixels wide, for both 4, 8 and 16 pixels loop filters
  
  (and the 4/8 mixed versions as well).
  For the 8 pixel wide versions, it is pretty close in speed (the
  
  v_4_8 and v_8_8 filters are the best examples of this ; the h_4_8
  
  and h_8_8 filters seem to get some gain in the load/transpose/store
  
  part). For the 16 pixels wide ones, we get a speedup of around
  
  1.2-1.4x compared to the 32 bit version.
  Examples of runtimes vs the 32 bit version, on a Cortex A53 :
  
                                         ARM AArch64
  
  vp9_loop_filter_h_4_8_neon :          144.0   127.2
  
  vp9_loop_filter_h_8_8_neon :          207.0   182.5
  
  vp9_loop_filter_h_16_8_neon :         415.0   328.7
  
  vp9_loop_filter_h_16_16_neon :        672.0   558.6
  
  vp9_loop_filter_mix2_h_44_16_neon :   302.0   203.5
  
  vp9_loop_filter_mix2_h_48_16_neon :   365.0   305.2
  
  vp9_loop_filter_mix2_h_84_16_neon :   365.0   305.2
  
  vp9_loop_filter_mix2_h_88_16_neon :   376.0   305.2
  
  vp9_loop_filter_mix2_v_44_16_neon :   193.2   128.2
  
  vp9_loop_filter_mix2_v_48_16_neon :   246.7   218.4
  
  vp9_loop_filter_mix2_v_84_16_neon :   248.0   218.5
  
  vp9_loop_filter_mix2_v_88_16_neon :   302.0   218.2
  
  vp9_loop_filter_v_4_8_neon :           89.0    88.7
  
  vp9_loop_filter_v_8_8_neon :          141.0   137.7
  
  vp9_loop_filter_v_16_8_neon :         295.0   272.7
  
  vp9_loop_filter_v_16_16_neon :        546.0   453.7
  The speedup vs C code in checkasm tests is around 2-7x, which is
  
  pretty much the same as for the 32 bit version. Even if these functions
  
  are faster than their 32 bit equivalent, the C version that we compare
  
  to also became around 1.3-1.7x faster than the C version in 32 bit.
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 4-5x.
  Examples of runtimes vs C on a Cortex A57 (for a slightly older version
  
  of the patch) :
  
                           A57 gcc-5.3  neon
  
  loop_filter_h_4_8_neon :        256.6  93.4
  
  loop_filter_h_8_8_neon :        307.3 139.1
  
  loop_filter_h_16_8_neon :       340.1 254.1
  
  loop_filter_h_16_16_neon :      827.0 407.9
  
  loop_filter_mix2_h_44_16_neon : 524.5 155.4
  
  loop_filter_mix2_h_48_16_neon : 644.5 173.3
  
  loop_filter_mix2_h_84_16_neon : 630.5 222.0
  
  loop_filter_mix2_h_88_16_neon : 697.3 222.0
  
  loop_filter_mix2_v_44_16_neon : 598.5 100.6
  
  loop_filter_mix2_v_48_16_neon : 651.5 127.0
  
  loop_filter_mix2_v_84_16_neon : 591.5 167.1
  
  loop_filter_mix2_v_88_16_neon : 855.1 166.7
  
  loop_filter_v_4_8_neon :        271.7  65.3
  
  loop_filter_v_8_8_neon :        312.5 106.9
  
  loop_filter_v_16_8_neon :       473.3 206.5
  
  loop_filter_v_16_16_neon :      976.1 327.8
  The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
  
  is again 30-50% faster than the cortex-a53.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/aarch64/Makefile
  • [DBH] libavcodec/aarch64/vp9dsp_init_aarch64.c
  • [DBH] libavcodec/aarch64/vp9lpf_neon.S

• rtpdec : Don’t pass non-const pointers to fmtp attribute parsing functions

  24 février 2015, par Martin Storsjö

  rtpdec : Don’t pass non-const pointers to fmtp attribute parsing functions
  This makes it clear that the individual parsing functions can’t
  
  touch the parsed out value.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/rtpdec.c
  • [DBH] libavformat/rtpdec.h
  • [DBH] libavformat/rtpdec_amr.c
  • [DBH] libavformat/rtpdec_dv.c
  • [DBH] libavformat/rtpdec_h264.c
  • [DBH] libavformat/rtpdec_hevc.c
  • [DBH] libavformat/rtpdec_ilbc.c
  • [DBH] libavformat/rtpdec_latm.c
  • [DBH] libavformat/rtpdec_mpeg4.c
  • [DBH] libavformat/rtpdec_xiph.c

• Receiving UDP streams on my web server

  25 novembre 2013, par user3032143

  I have a Winform C# Desktop application.

  This is my overall aim :

  I have a constant stream of images from which I acquire using a VLC wrapper receiving a RTSP stream from my IP camera.

  I am doing image processing on these separate jpegs and at the same time I am wanting to upload these jpegs to my web server so my User can view these streaming jpegs live a video.

  Now, I have accomplished this so far by uploading each jpeg to my server using a [Web method]. But, I am trying to push my knowledge to make it more efficient.

  Now, i know if I use a video encoder - like OGG (used because it is Open Source) I can use ffmpeg called from my client code using the Process class so to convert images to that video format.

  Doing this saves a lot of memory when comparing that 1 ogg file to the separate bytes added up in total from all the individual jpegs.

  These are the arguments I pass to ffmpeg to achieve that :

  -f image2 -r 10 -i {location of jpegs}+"\img%05d.jpg -crf 23  -y -r 10 -f outputfile.ogg

  Now, I could take this a step further and not output to a physical file but instead to the base stream of the Process class. I would use these arguments to accomplish that :

  -f image2 -r 10 -i {location of jpegs}+"\img%05d.jpg -crf 23  -y -r 10 -f ogg -

  and in my code I would get the memory stream like so :

  mStandardOutput = serverBuild.StandardOutput.BaseStream;
  
  mStandardOutput.BeginRead(mReadBuffer, 0, mReadBuffer.Length, StandardOutputReadCallback, null);
  
  serverBuild.WaitForExit();
  
  data = mStandardOutputMs.ToArray();
  
  mStandardOutput.Close();

  Now ultimately, I would like to replace :

  -i {location of jpegs}+"\img%05d.jpg

  with a constant flow of jpegs in a memory stream like so :

  ffmpeg -f mjpeg -i - -r 10 -c:v libtheora -q:v 7 -f ogg -

  .. by over-writing the stdin...

  But I have not done this yet because I want to 1st try getting the ogg to be received within my web server.

  From there I would extract the jpegs to be accessible somehow via my web application written in asp.net 4.0.

  But first thing is first I want to just see if I can receive the UDP stream from my client.
  So, I create a test C# application to open and listen write from the client stream..
  this is my code :

  Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
  
  public Form1()
  
  {
  
     InitializeComponent();
  
  
  
     socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
  
     string ip = "My Server IP Address";
  
     int port = 3000;
  
     socket.Bind(new IPEndPoint(IPAddress.Parse(ip), port));
  
  }
  
  
  
  private void button1_Click(object sender, EventArgs e)
  
  {
  
     try
  
     {
  
        var buffer = new byte[1024];
  
        while (true)
  
        {
  
           Application.DoEvents();
  
           int numBytesReceived = socket.Receive(buffer);
  
           if (numBytesReceived > 0)
  
           {
  
              File.WriteAllBytes("c:\\udp\\test.ogg", buffer);
  
           }
  
        }
  
     }
  
     catch (Exception _ex)
  
     {
  
        MessageBox.Show(_ex.ToString());
  
     }
  
  }

  But, I get this error :

  A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.

  What am I doing wrong please ?

  Thanks