Recherche avancée

Sur d’autres sites (4899)

• 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

• aarch64 : vp9 : Implement NEON loop filters

  14 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.
  This is an adapted cherry-pick from libav commits
  
  9d2afd1eb8c5cc0633062430e66326dbf98c99e0 and
  
  31756abe29eb039a11c59a42cb12e0cc2aef3b97.
  Signed-off-by : Ronald S. Bultje <rsbultje@gmail.com>
  

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

• fate : Avoid unnecessary pixel format conversions

  30 juin 2015, par Martin Storsjö

  fate : Avoid unnecessary pixel format conversions
  Most of the fate-dds-* and fate-txd-* tests already
  
  output into the same pixel format regardless of
  
  platform endianness, so there’s no need to force
  
  conversion to another format.
  This fixes the tests fate-txd-16bpp, fate-txd-odd,
  
  fate-dds-rgb16, fate-dds-rgb24 and fate-dds-xrgb on
  
  big endian, where the tests seem to fail due to issues
  
  with certain conversion codepaths in swscale.
  Those conversion codepaths should of course be fixed, but
  
  the individual decoder tests should use as little extra
  
  conversion steps as possible.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] tests/fate/image.mak
  • [DH] tests/fate/video.mak
  • [DH] tests/ref/fate/dds-rgb16
  • [DH] tests/ref/fate/dds-rgb24
  • [DH] tests/ref/fate/dds-uyvy
  • [DH] tests/ref/fate/dds-xbgr
  • [DH] tests/ref/fate/dds-y
  • [DH] tests/ref/fate/dds-ya
  • [DH] tests/ref/fate/dds-yuyv
  • [DH] tests/ref/fate/txd-16bpp
  • [DH] tests/ref/fate/txd-odd