Recherche avancée

Sur d’autres sites (8965)

• How can I mux (or encapsulate) H.264 RTP output into a container using FFMPEG ?

  7 octobre 2013, par Grad

  I am working on the effects of network losses in video transmission. In order to simulate the network losses I use a simple program which drops random RTP packets from the output of H.264 RTP encoding.

  I use Joint Model (JM) 14.2 in order to encode the video. However, I don't use AnnexB format as my output, instead I choose the output as RTP packets. The JM output is generated as RTP packets with RTP headers and payload as a sequence. After that, some of RTP packets are dropped by using a simple program. Then, I can decode the output bitstream by using also JM and it's error concealment methods.

  The main purpose of this process is to evaluate the differences created by network losses on the human video quality perception. In order to measure the perceived quality, the shown video must be in its decoded form (i.e. full resolution) or it can be decodable at the receiver side. The RTP packets created by the JM Encoder cannot be decoded without the JM software installed. However, with the proper header (or container) most video players are able to decode the bitstream. So, the my goal in this question is to encapsulate my encoded RTP packet bitstream in a common container such as AVI or MP4 to have my content decodable at the receiver computer.

  The format of the encoded bitstream in RTP packetized form is as follows :

       ----------------------------------------------------------------------
  
       | RTP Header #1 | RTP Payload #1 | RTP Header #2 | RTP Payload #2 |...
  
       ----------------------------------------------------------------------

  In order to find the video quality, I want to make a subjective test with these bitstreams. I can make these test by using the full resolution data decoded by myself whereas it's very inconvenient to crowdsource this subjective test with GBs of video data on the Internet. So, I want to mux these bitstreams into a container (i.e. AVI) by using FFMPEG. I have tried to decode these bitstreams with FFMPEG and FFPLAY ; however, both of them didn't work. I also tried the following command and it didn't work, either.

      ffmpeg - f h264 -i  -vcodec copy -r 25 out.avi

  Which format or muxer should I use ? Do I need to convert these files to any other format ?

• lavc/vp8dsp : rework R-V V idct_dc_add4y

  2 juin 2024, par Rémi Denis-Courmont

  lavc/vp8dsp : rework R-V V idct_dc_add4y
  DCT-related FFmpeg functions often add an unsigned 8-bit sample to a
  
  signed 16-bit coefficient, then clip the result back to an unsigned
  
  8-bit value. RISC-V has no signed 16-bit to unsigned 8-bit clip, so
  
  instead our most common sequence is :
  
      VWADDU.WV
  
      set SEW to 16 bits
  
      VMAX.VV zero     # clip negative values to 0
  
      set SEW to 8 bits
  
      VNCLIPU.WI       # clip values over 255 to 255 and narrow
  Here we use a different sequence which does not require toggling the
  
  vector type. This assumes that the wide addend vector is biased by
  
   128 :
  
      VWADDU.WV
  
      VNCLIP.WI    # clip values to signed 8-bit and narrow
  
      VXOR.VX 0x80 # flip sign bit (convert signed to unsigned)
  Also the VMAX is effectively replaced by a VXOR of half-width. In this
  
  function, this comes for free as we anyway add a constant to the wide
  
  vector in the prologue.
  On C908, this has no observable effects. On X60, this improves
  
  microbenchmarks by about 20%.
  

  • [DH] libavcodec/riscv/vp7dsp_rvv.S
  • [DH] libavcodec/riscv/vp8dsp_rvv.S

• 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