Recherche avancée

Sur d’autres sites (3659)

• lavu : add an API function to return the Libav version string

  2 juillet 2015, par wm4

  lavu : add an API function to return the Libav version string
  This returns something like "v12_dev0-1332-g333a27c". This is much more
  
  useful than the individual library versions, of which there are too
  
  many, and which are very hard to map back to releases or git commits.
  Signed-off-by : Janne Grunau <janne-libav@jannau.net>
  

  • [DBH] .gitignore
  • [DBH] Makefile
  • [DBH] cmdutils.c
  • [DBH] doc/APIchanges
  • [DBH] libavutil/avutil.h
  • [DBH] libavutil/utils.c

• arm : Add NEON optimizations for 10 and 12 bit vp9 loop filter

  5 janvier 2017, par Martin Storsjö

  arm : Add NEON optimizations for 10 and 12 bit vp9 loop filter
  This work is sponsored by, and copyright, Google.
  This is pretty much similar to the 8 bpp version, but in some senses
  
  simpler. All input pixels are 16 bits, and all intermediates also fit
  
  in 16 bits, so there’s no lengthening/narrowing in the filter at all.
  For the full 16 pixel wide filter, we can only process 4 pixels at a time
  
  (using an implementation very much similar to the one for 8 bpp),
  
  but we can do 8 pixels at a time for the 4 and 8 pixel wide filters with
  
  a different implementation of the core filter.
  Examples of relative speedup compared to the C version, from checkasm :
  
                                     Cortex    A7     A8     A9    A53
  
  vp9_loop_filter_h_4_8_10bpp_neon :          1.83   2.16   1.40   2.09
  
  vp9_loop_filter_h_8_8_10bpp_neon :          1.39   1.67   1.24   1.70
  
  vp9_loop_filter_h_16_8_10bpp_neon :         1.56   1.47   1.10   1.81
  
  vp9_loop_filter_h_16_16_10bpp_neon :        1.94   1.69   1.33   2.24
  
  vp9_loop_filter_mix2_h_44_16_10bpp_neon :   2.01   2.27   1.67   2.39
  
  vp9_loop_filter_mix2_h_48_16_10bpp_neon :   1.84   2.06   1.45   2.19
  
  vp9_loop_filter_mix2_h_84_16_10bpp_neon :   1.89   2.20   1.47   2.29
  
  vp9_loop_filter_mix2_h_88_16_10bpp_neon :   1.69   2.12   1.47   2.08
  
  vp9_loop_filter_mix2_v_44_16_10bpp_neon :   3.16   3.98   2.50   4.05
  
  vp9_loop_filter_mix2_v_48_16_10bpp_neon :   2.84   3.64   2.25   3.77
  
  vp9_loop_filter_mix2_v_84_16_10bpp_neon :   2.65   3.45   2.16   3.54
  
  vp9_loop_filter_mix2_v_88_16_10bpp_neon :   2.55   3.30   2.16   3.55
  
  vp9_loop_filter_v_4_8_10bpp_neon :          2.85   3.97   2.24   3.68
  
  vp9_loop_filter_v_8_8_10bpp_neon :          2.27   3.19   1.96   3.08
  
  vp9_loop_filter_v_16_8_10bpp_neon :         3.42   2.74   2.26   4.40
  
  vp9_loop_filter_v_16_16_10bpp_neon :        2.86   2.44   1.93   3.88
  The speedup vs C code measured in checkasm is around 1.1-4x.
  
  These numbers are quite inconclusive though, since the checkasm test
  
  runs multiple filterings on top of each other, so later rounds might
  
  end up with different codepaths (different decisions on which filter
  
  to apply, based on input pixel differences).
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 2-4x.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/arm/Makefile
  • [DH] libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
  • [DH] libavcodec/arm/vp9lpf_16bpp_neon.S

• Decoding RIMM streaming file format

  1er août 2019, par ThomasRS

  I want to decode the video (visual) frames within a Blackberry RIMM file. So far I have a parser, and some corresponding container documentation from RIM. 

  The video codec is H264 and is explicitly set on the device using one of the video.encodings properties. However, FFMPEG is not able to decode the frames and this is driving me nuts.

  Edit 1 : The issues seems to be lack of SPS and PPS in the frames, and artificially inserting them have proven unsuccessful so far (all grey image). Blackberry 9700 sends

  0x00 0x00 0x ?? 0x ?? 0xType

  where Type is according to table 7-1 in the H264 spec (I and P frames). We believe the 0x ?? 0x ?? represent the size of the frame, however the size does not always correspond to the size found by the parser (the parser seems to be working correctly).

  I have a windows decoder codec from blackberry, called mc_demux_mp2_ds.ax, and can play some MPEG-4 files captured the same way, but it is a binary for windows. And the H264 files will not play either way. I am aware of previous attempts. The capture url for javax.microedition.media.Manager is

  encoding=video-3gpp_width=176_height=144_video_codec=H264_audio_codec=AAC

  and I am writing to an output stream. Some example files here.

  Edit 2 :Turns out that about 3-4 of the 12-15 available video capture modes are flat out failing and refusing to output data, even in the simplest of test applications. So any working solution should implement MPEG-4, H264 and H263 in both AMR and AAC, in so getting fallback alternatives when one sound codec and/or resolution fails. Reboots, hangs and what not litters the Blackberry video implementation and vary from firmware to firmware ; total suckage.