Recherche avancée

Sur d’autres sites (8660)

• Revision e890c2579b : add a context tree structure to encoder This patch sets up a quad_tree structur

  17 avril 2014, par Jim Bankoski

  Changed Paths :
   Modify /vp9/encoder/vp9_block.h

  
   Add /vp9/encoder/vp9_context_tree.c

  
   Add /vp9/encoder/vp9_context_tree.h

  
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/vp9_firstpass.c

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/vp9cx.mk

  
  
  add a context tree structure to encoder

  This patch sets up a quad_tree structure (pc_tree) for holding all of
  pick_mode_context data we use at any square block size during encoding
  or picking modes. That includes contexts for 2 horizontal and 2 vertical
  splits, one none, and pointers to 4 sub pc_tree nodes corresponding
  to split. It also includes a pointer to the current chosen partitioning.

  This replaces code that held an index for every level in the pick
  modes array including : sb_index, mb_index,
  b_index, ab_index.

  These were used as stateful indexes that pointed to the current pick mode
  contexts you had at each level stored in the following arrays

  array ab4x4_context[][][],
  sb8x4_context[][][], sb4x8_context[][][], sb8x8_context[][][],
  sb8x16_context[][][], sb16x8_context[][][], mb_context[][], sb32x16[][],
  sb16x32[], sb32_context[], sb32x64_context[], sb64x32_context[],
  sb64_context

  and the partitioning that had been stored in the following :
  b_partitioning, mb_partitioning, sb_partitioning, and sb64_partitioning.

  Prior to this patch before doing an encode you had to set the appropriate
  index for your block size ( switch statement), update it ( up to 3
  lookups for the index array value) and then make your call into a recursive
  function at which point you'd have to call get_context which then
  had to do a switch statement based on the blocksize, and then up to 3
  lookups based upon the block size to find the context to use.

  With the new code the context for the block size is passed around directly
  avoiding the extraneous switch statements and multi dimensional array
  look ups that were listed above. At any level in the search all of the
  contexts are local to the pc_tree you are working on (in ?).

  In addition in most places code that used to call sub functions and
  then check if the block size was 4x4 and index was > 0 and return
  now don't preferring instead to call the right none function on the inside.

  Change-Id : I06e39318269d9af2ce37961b3f95e181b57f5ed9

• Visualizing Call Graphs Using Gephi

  1er septembre 2014, par Multimedia Mike — General

  When I was at university studying computer science, I took a basic chemistry course. During an accompanying lab, the teaching assistant chatted me up and asked about my major. He then said, “Computer science ? Well, that’s just typing stuff, right ?”

  My impulsive retort : “Sure, and chemistry is just about mixing together liquids and coming up with different colored liquids, as seen on the cover of my high school chemistry textbook, right ?”

  
  
  

  In fact, pure computer science has precious little to do with typing (as is joked in CS circles, computer science is about computers in the same way that astronomy is about telescopes). However, people who study computer science often pursue careers as programmers, or to put it in fancier professional language, software engineers.

  So, what’s a software engineer’s job ? Isn’t it just typing ? That’s where I’ve been going with this overly long setup. After thinking about it for long enough, I like to say that a software engineer’s trade is managing complexity.

  A few years ago, I discovered Gephi, an open source tool for graph and data visualization. It looked neat but I didn’t have much use for it at the time. Recently, however, I was trying to get a better handle on a large codebase. I.e., I was trying to manage the project’s complexity. And then I thought of Gephi again.

  Prior Work
  One way to get a grip on a large C codebase is to instrument it for profiling and extract details from the profiler. On Linux systems, this means compiling and linking the code using the -pg flag. After running the executable, there will be a gmon.out file which is post-processed using the gprof command.

  GNU software development tools have a reputation for being rather powerful and flexible, but also extremely raw. This first hit home when I was learning how to use the GNU tool for code coverage — gcov — and the way it outputs very raw data that you need to massage with other tools in order to get really useful intelligence.

  And so it is with gprof output. The output gives you a list of functions sorted by the amount of processing time spent in each. Then it gives you a flattened call tree. This is arranged as “during the profiled executions, function c was called by functions a and b and called functions d, e, and f ; function d was called by function c and called functions g and h”.

  How can this call tree data be represented in a more instructive manner that is easier to navigate ? My first impulse (and I don’t think I’m alone in this) is to convert the gprof call tree into a representation suitable for interpretation by Graphviz. Unfortunately, doing so tends to generate some enormous and unwieldy static images.

  Feeding gprof Data To Gephi
  I learned of Gephi a few years ago and recalled it when I developed an interest in gaining better perspective on a large base of alien C code. To understand what this codebase is doing for a particular use case, instrument it with gprof, gather execution data, and then study the code paths.

  How could I feed the gprof data into Gephi ? Gephi supports numerous graphing formats including an XML-based format named GEXF.

  Thus, the challenge becomes converting gprof output to GEXF.

  Which I did.

  Demonstration
  I have been absent from FFmpeg development for a long time, which is a pity because a lot of interesting development has occurred over the last 2-3 years after a troubling period of stagnation. I know that 2 big video codec developments have been HEVC (next in the line of MPEG codecs) and VP9 (heir to VP8’s throne). FFmpeg implements them both now.

  I decided I wanted to study the code flow of VP9. So I got the latest FFmpeg code from git and built it using the options "--extra-cflags=-pg --extra-ldflags=-pg". Annoyingly, I also needed to specify "--disable-asm" because gcc complains of some register allocation snafus when compiling inline ASM in profiling mode (and this is on x86_64). No matter ; ASM isn’t necessary for understanding overall code flow.

  After compiling, the binary ‘ffmpeg_g’ will have symbols and be instrumented for profiling. I grabbed a sample from this VP9 test vector set and went to work.

  ./ffmpeg_g -i vp90-2-00-quantizer-00.webm -f null /dev/null
  gprof ./ffmpeg_g > vp9decode.txt
  convert-gprof-to-gexf.py vp9decode.txt > /bigdisk/vp9decode.gexf
  

  Gephi loads vp9decode.gexf with no problem. Using Gephi, however, can be a bit challenging if one is not versed in any data exploration jargon. I recommend this Gephi getting starting guide in slide deck form. Here’s what the default graph looks like :

  
  
  

  Not very pretty or helpful. BTW, that beefy arrow running from mid-top to lower-right is the call from decode_coeffs_b -> iwht_iwht_4x4_add_c. There were 18774 from the former to the latter in this execution. Right now, the edge thicknesses correlate to number of calls between the nodes, which I’m not sure is the best representation.

  Following the tutorial slide deck, I at least learned how to enable the node labels (function symbols in this case) and apply a layout algorithm. The tutorial shows the force atlas layout. Here’s what the node neighborhood looks like for probing file type :

  
  
  

  Okay, so that’s not especially surprising– avprobe_input_format3 calls all of the *_probe functions in order to automatically determine input type. Let’s find that decode_coeffs_b function and see what its neighborhood looks like :

  
  
  

  That’s not very useful. Perhaps another algorithm might help. I select the Fruchterman–Reingold algorithm instead and get a slightly more coherent representation of the decoding node neighborhood :

  
  
  

  Further Work
  Obviously, I’m just getting started with this data exploration topic. One thing I would really appreciate in such a tool is the ability to interactively travel the graph since that’s what I’m really hoping to get out of this experiment– watching the code flows.

  Perhaps someone else can find better use cases for visualizing call graph data. Thus, I have published the source code for this tool at Github.

• How to convert Lagarith .avi videos to MP4 using WinFF

  24 avril 2014, par Moein

  I have a bunch of .avi videos encoded with Lagarith codec. We would like to convert them in to a lossless .MP4 format so that they could be easily played on html. I want to keep video specifications remain the same if it’s possible and just convert the video to MP4.

  I tried WinFF and also some manually written FFmpeg codes [without any specific reference to the Lagarith codec] but they all create a video which is not playable (neither with Windows Player nor with the HTML5 player). Also, FFmpeg returns exceptions like bellow.

  Edit :
  Here is the FFmpeg code generated by WinFF, this code gives me the following Exception :

  "C:\Program Files\WinFF\ffmpeg.exe" -y -i "C:\Desktop\Videos\input.avi" -f mp4 -r 29.97 -vcodec libx264 -preset slow -vf scale=640:480 -b:v 1000k -aspect 4:3 -flags +loop -cmp chroma -b:v 1250k -maxrate 1500k -bufsize 4M -bt 256k -refs 1 -bf 3 -coder 1 -me_method umh -me_range 16 -subq 7 -partitions +parti4x4+parti8x8+partp8x8+partb8x8 -g 250 -keyint_min 25 -level 30 -qmin 10 -qmax 51 -qcomp 0.6 -trellis 2 -sc_threshold 40 -i_qfactor 0.71 -acodec libvo_aacenc -b:a 112k -ar 48000 -ac 2 "C:\Desktop\Videos\output.mp4"

  ---

  

  2nd Edit :
  Here is the entire exception that I receive :

      C:\Users\Desktop\Videos>"c:\Program Files\ffmpeg\bin\ffmpeg.exe" -y -i 300
  
  4_KDSmall-08_02_2013-11_43_34_415.avi -crf 26 -vcodec libx264 -pix_fmt yuv420p -
  
  acodec libvo_aacenc -ac 1 -ar 16000 -b:a 32000 3004_KDSmall-08_02_2013-11_43_34_
  
  415.mp4
  
  ffmpeg version N-62439-g5e379cd Copyright (c) 2000-2014 the FFmpeg developers
  
    built on Apr 13 2014 22:08:47 with gcc 4.8.2 (GCC)
  
    configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
  
  isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
  
  le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
  
  e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena
  
  ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l
  
  ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp
  
  eex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aa
  
  cenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavp
  
  ack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable
  
  -zlib
  
    libavutil      52. 76.100 / 52. 76.100
  
    libavcodec     55. 58.103 / 55. 58.103
  
    libavformat    55. 37.100 / 55. 37.100
  
    libavdevice    55. 13.100 / 55. 13.100
  
    libavfilter     4.  4.100 /  4.  4.100
  
    libswscale      2.  6.100 /  2.  6.100
  
    libswresample   0. 18.100 /  0. 18.100
  
    libpostproc    52.  3.100 / 52.  3.100
  
  Input #0, avi, from '3004_KDSmall-08_02_2013-11_43_34_415.avi':
  
    Duration: 00:15:00.00, start: 0.000000, bitrate: 328 kb/s
  
      Stream #0:0: Video: lagarith (LAGS / 0x5347414C), rgb24, 320x244, 326 kb/s,
  
  7.50 tbr, 7.50 tbn, 7.50 tbc
  
  Codec AVOption b (set bitrate (in bits/s)) specified for output file #0 (3004_KD
  
  Small-08_02_2013-11_43_34_415.mp4) has not been used for any stream. The most li
  
  kely reason is either wrong type (e.g. a video option with no video streams) or
  
  that it is a private option of some encoder which was not actually used for any
  
  stream.
  
  [libx264 @ 0000000004288320] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
  
  AVX
  
  [libx264 @ 0000000004288320] profile High, level 1.2
  
  [libx264 @ 0000000004288320] 264 - core 142 r2409 d6b4e63 - H.264/MPEG-4 AVC cod
  
  ec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 r
  
  ef=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed
  
  _ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pski
  
  p=1 chroma_qp_offset=-2 threads=12 lookahead_threads=1 sliced_threads=0 nr=0 dec
  
  imate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b
  
  _adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=
  
  7 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=26.0 qcomp=0.6
  
  0 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  
  Output #0, mp4, to '3004_KDSmall-08_02_2013-11_43_34_415.mp4':
  
    Metadata:
  
      encoder         : Lavf55.37.100
  
      Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 320x24
  
  4, q=-1--1, 15360 tbn, 7.50 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (lagarith -> libx264)
  
  Press [q] to stop, [?] for help
  
  frame= 1024 fps=0.0 q=27.0 size=      17kB time=00:02:08.80 bitrate=   1.1kbits/
  
  frame= 1947 fps=1943 q=27.0 size=     234kB time=00:04:11.86 bitrate=   7.6kbits
  
  frame= 2695 fps=1794 q=27.0 size=     659kB time=00:05:51.60 bitrate=  15.4kbits
  
  frame= 3971 fps=1983 q=27.0 size=     680kB time=00:08:41.73 bitrate=  10.7kbits
  
  frame= 5256 fps=2101 q=27.0 size=     702kB time=00:11:33.06 bitrate=   8.3kbits
  
  frame= 6074 fps=2023 q=27.0 size=    1018kB time=00:13:22.13 bitrate=  10.4kbits
  
  frame= 6343 fps=1810 q=27.0 size=    1625kB time=00:13:58.00 bitrate=  15.9kbits
  
  frame= 6588 fps=1644 q=27.0 size=    2247kB time=00:14:30.66 bitrate=  21.1kbits
  
  [lagarith @ 0000000004378fc0] Unsupported Lagarith frame type: 0x24
  
  [lagarith @ 00000000043796c0] Unsupported Lagarith frame type: 0x38
  
  [lagarith @ 000000000437a700] Unsupported Lagarith frame type: 0x4c
  
  [lagarith @ 000000000437d740] Unsupported Lagarith frame type: 0x60
  
  [lagarith @ 000000000437e760] Unsupported Lagarith frame type: 0x74
  
  [lagarith @ 0000000007fcb800] Unsupported Lagarith frame type: 0x88
  
  [lagarith @ 0000000007fcc820] Unsupported Lagarith frame type: 0x9c
  
  [lagarith @ 0000000007fd0860] Unsupported Lagarith frame type: 0xb0
  
  Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome
  
  
  
  [lagarith @ 0000000007fd0ce0] Unsupported Lagarith frame type: 0xc4
  
  Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome
  
  
  
  [lagarith @ 0000000004378fc0] Unsupported Lagarith frame type: 0xd8
  
  Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome
  
  
  
  [lagarith @ 00000000043796c0] Unsupported Lagarith frame type: 0xec
  
  frame= 6750 fps=1524 q=-1.0 Lsize=    2881kB time=00:14:59.73 bitrate=  26.2kbit
  
  s/s
  
  video:2802kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
  
  overhead: 2.842291%
  
  [libx264 @ 0000000004288320] frame I:29    Avg QP: 8.05  size:  2113
  
  [libx264 @ 0000000004288320] frame P:1874  Avg QP:11.85  size:   799
  
  [libx264 @ 0000000004288320] frame B:4847  Avg QP:13.60  size:   270
  
  [libx264 @ 0000000004288320] consecutive B-frames:  1.3%  6.0%  8.6% 84.1%
  
  [libx264 @ 0000000004288320] mb I  I16..4: 82.8%  4.8% 12.4%
  
  [libx264 @ 0000000004288320] mb P  I16..4:  0.2%  0.2%  0.3%  P16..4:  5.5%  4.9
  
  %  5.0%  0.0%  0.0%    skip:84.0%
  
  [libx264 @ 0000000004288320] mb B  I16..4:  0.0%  0.0%  0.1%  B16..8:  2.9%  2.2
  
  %  1.4%  direct: 0.7%  skip:92.7%  L0:55.4% L1:38.8% BI: 5.8%
  
  [libx264 @ 0000000004288320] 8x8 transform intra:13.7% inter:12.4%
  
  [libx264 @ 0000000004288320] coded y,uvDC,uvAC intra: 21.9% 42.5% 34.9% inter: 2
  
  .7% 5.4% 4.8%
  
  [libx264 @ 0000000004288320] i16 v,h,dc,p: 81%  9%  8%  2%
  
  [libx264 @ 0000000004288320] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 14% 49%  2%  3%
  
   4%  3%  2%  2%
  
  [libx264 @ 0000000004288320] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 14% 34%  4%  4%
  
   5%  4%  4%  3%
  
  [libx264 @ 0000000004288320] i8c dc,h,v,p: 72% 12% 12%  4%
  
  [libx264 @ 0000000004288320] Weighted P-Frames: Y:0.1% UV:0.1%
  
  [libx264 @ 0000000004288320] ref P L0: 42.5%  5.1% 29.3% 23.0%
  
  [libx264 @ 0000000004288320] ref B L0: 52.8% 37.8%  9.5%
  
  [libx264 @ 0000000004288320] ref B L1: 82.3% 17.7%
  
  [libx264 @ 0000000004288320] kb/s:25.50

  Any body could help me easily doing this conversion ?