Recherche avancée

Sur d’autres sites (4564)

• Why X.Org's X Server has stopped working on Google Colab ?

  20 février 2021, par Rahul

  I am Using X server for the virtual screen on Google Colab and capturing that screen with ffmpeg to record it and live stream it to twitch. (for the reinforcement learning project)

  


  


  The above process was completely working till my last use of my Colab notebook (on mid-January 2021), but now (on 19th February 2021) I am using the same notebook and the streaming code has stopped working.

  


  


  I am adding config and log file data below. (I have never seen these files before because it was working, now it's not so I don't have any idea what wrong)

  


  The config file stored at /etc/X11/xorg.conf have the following data :

  


  # nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 418.67

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/mouse"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "Tesla T4"
    BusID          "PCI:0:4:0"
    MatchSeat      "seat-1"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "AllowEmptyInitialConfiguration" "True"
    SubSection     "Display"
        Virtual     1920 1080
        Depth       24
    EndSubSection
EndSection


  


  The log file stored at /var/log/Xorg.0.log have the following data :

  


  [   464.605] 
X.Org X Server 1.19.6
Release Date: 2017-12-20
[   464.605] X Protocol Version 11, Revision 0
[   464.605] Build Operating System: Linux 4.15.0-124-generic x86_64 Ubuntu
[   464.605] Current Operating System: Linux 9d3fe3949671 4.19.112+ #1 SMP Thu Jul 23 08:00:38 PDT 2020 x86_64
[   464.605] Kernel command line: BOOT_IMAGE=/syslinux/vmlinuz.A init=/usr/lib/systemd/systemd boot=local rootwait ro noresume noswap loglevel=7 noinitrd console=ttyS0 security=apparmor virtio_net.napi_tx=1 systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false csm.disabled=1 dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 i915.modeset=1 cros_efi loadpin.enabled=0 root=/dev/dm-0 "dm=1 vroot none ro 1,0 4077568 verity payload=PARTUUID=555BDB75-CBD7-CD4A-B24E-29B13D7AC0DF hashtree=PARTUUID=555BDB75-CBD7-CD4A-B24E-29B13D7AC0DF hashstart=4077568 alg=sha256 root_hexdigest=42104d547ac104fb7061529e78f53e4f3e8c3d3cbb040dc6e0f84aad68491347 salt=9dc7f3acc4e2ce65be16356e960c2b21b51a917fa31d2e891fd295490c991e41" mitigations=off
[   464.605] Build Date: 30 November 2020  08:01:56PM
[   464.605] xorg-server 2:1.19.6-1ubuntu4.8 (For technical support please see http://www.ubuntu.com/support) 
[   464.605] Current version of pixman: 0.34.0
[   464.605]    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[   464.605] Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   464.605] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 20 03:10:44 2021
[   464.606] (==) Using config file: "/etc/X11/xorg.conf"
[   464.606] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   464.607] (==) ServerLayout "Layout0"
[   464.607] (**) |-->Screen "Screen0" (0)
[   464.607] (**) |   |-->Monitor "Monitor0"
[   464.607] (**) |   |-->Device "Device0"
[   464.607] (**) |-->Input Device "Keyboard0"
[   464.607] (**) |-->Input Device "Mouse0"
[   464.607] (==) Automatically adding devices
[   464.607] (==) Automatically enabling devices
[   464.607] (==) Automatically adding GPU devices
[   464.607] (==) Automatically binding GPU devices
[   464.607] (==) Max clients allowed: 256, resource mask: 0x1fffff
[   464.607] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   464.607]    Entry deleted from font path.
[   464.607] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[   464.607]    Entry deleted from font path.
[   464.607] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[   464.607]    Entry deleted from font path.
[   464.607] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[   464.607]    Entry deleted from font path.
[   464.607] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[   464.607]    Entry deleted from font path.
[   464.607] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[   464.607]    Entry deleted from font path.
[   464.607] (==) FontPath set to:
    /usr/share/fonts/X11/misc,
    built-ins
[   464.607] (==) ModulePath set to "/usr/lib/xorg/modules"
[   464.607] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   464.607] (WW) Disabling Keyboard0
[   464.607] (WW) Disabling Mouse0
[   464.607] (II) Loader magic: 0x556eb77b8020
[   464.607] (II) Module ABI versions:
[   464.607]    X.Org ANSI C Emulation: 0.4
[   464.607]    X.Org Video Driver: 23.0
[   464.607]    X.Org XInput driver : 24.1
[   464.607]    X.Org Server Extension : 10.0
[   464.607] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)
[   464.609] (--) PCI: (0:0:4:0) 10de:1eb8:10de:12a2 rev 161, Mem @ 0xc0000000/16777216, 0x380000000/268435456, 0x390000000/33554432
[   464.609] (II) no primary bus or device found
[   464.609] (II) LoadModule: "glx"
[   464.609] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   464.610] (II) Module glx: vendor="X.Org Foundation"
[   464.610]    compiled for 1.19.6, module version = 1.0.0
[   464.610]    ABI class: X.Org Server Extension, version 10.0
[   464.610] (II) LoadModule: "nvidia"
[   464.610] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[   464.610] (II) Module nvidia: vendor="NVIDIA Corporation"
[   464.610]    compiled for 4.0.2, module version = 1.0.0
[   464.610]    Module class: X.Org Video Driver
[   464.610] (II) NVIDIA dlloader X Driver  418.67  Sat Apr  6 02:51:17 CDT 2019
[   464.610] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[   464.610] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
[   464.610] (II) Loading sub module "fb"
[   464.610] (II) LoadModule: "fb"
[   464.611] (II) Loading /usr/lib/xorg/modules/libfb.so
[   464.611] (II) Module fb: vendor="X.Org Foundation"
[   464.611]    compiled for 1.19.6, module version = 1.0.0
[   464.611]    ABI class: X.Org ANSI C Emulation, version 0.4
[   464.611] (II) Loading sub module "wfb"
[   464.611] (II) LoadModule: "wfb"
[   464.611] (II) Loading /usr/lib/xorg/modules/libwfb.so
[   464.611] (II) Module wfb: vendor="X.Org Foundation"
[   464.611]    compiled for 1.19.6, module version = 1.0.0
[   464.611]    ABI class: X.Org ANSI C Emulation, version 0.4
[   464.611] (II) Loading sub module "ramdac"
[   464.611] (II) LoadModule: "ramdac"
[   464.611] (II) Module "ramdac" already built-in
[   464.637] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
[   464.637] (EE) NVIDIA:     system's kernel log for additional error messages and
[   464.637] (EE) NVIDIA:     consult the NVIDIA README for details.
[   464.662] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
[   464.662] (EE) NVIDIA:     system's kernel log for additional error messages and
[   464.662] (EE) NVIDIA:     consult the NVIDIA README for details.
[   464.662] (EE) No devices detected.
[   464.662] (==) Matched modesetting as autoconfigured driver 0
[   464.662] (==) Matched fbdev as autoconfigured driver 1
[   464.662] (==) Matched vesa as autoconfigured driver 2
[   464.662] (==) Assigned the driver to the xf86ConfigLayout
[   464.662] (II) LoadModule: "modesetting"
[   464.662] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   464.663] (II) Module modesetting: vendor="X.Org Foundation"
[   464.663]    compiled for 1.19.6, module version = 1.19.6
[   464.663]    Module class: X.Org Video Driver
[   464.663]    ABI class: X.Org Video Driver, version 23.0
[   464.663] (II) LoadModule: "fbdev"
[   464.663] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[   464.663] (II) Module fbdev: vendor="X.Org Foundation"
[   464.663]    compiled for 1.19.3, module version = 0.4.4
[   464.663]    Module class: X.Org Video Driver
[   464.663]    ABI class: X.Org Video Driver, version 23.0
[   464.663] (II) LoadModule: "vesa"
[   464.663] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[   464.663] (II) Module vesa: vendor="X.Org Foundation"
[   464.663]    compiled for 1.19.3, module version = 2.3.4
[   464.663]    Module class: X.Org Video Driver
[   464.663]    ABI class: X.Org Video Driver, version 23.0
[   464.663] (II) NVIDIA dlloader X Driver  418.67  Sat Apr  6 02:51:17 CDT 2019
[   464.663] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[   464.663] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   464.663] (II) FBDEV: driver for framebuffer: fbdev
[   464.663] (II) VESA: driver for VESA chipsets: vesa
[   464.663] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
[   464.663] (EE) open /dev/dri/card0: No such file or directory
[   464.663] (WW) Falling back to old probe method for modesetting
[   464.663] (EE) open /dev/dri/card0: No such file or directory
[   464.663] (WW) Falling back to old probe method for fbdev
[   464.663] (II) Loading sub module "fbdevhw"
[   464.663] (II) LoadModule: "fbdevhw"
[   464.663] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[   464.663] (II) Module fbdevhw: vendor="X.Org Foundation"
[   464.663]    compiled for 1.19.6, module version = 0.0.2
[   464.663]    ABI class: X.Org Video Driver, version 23.0
[   464.664] (EE) open /dev/fb0: No such file or directory
[   464.664] (WW) Falling back to old probe method for vesa
[   464.664] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[   464.664] (EE) Screen 0 deleted because of no matching config section.
[   464.664] (II) UnloadModule: "modesetting"
[   464.664] (EE) Device(s) detected, but none match those in the config file.
[   464.664] (EE) 
Fatal server error:
[   464.664] (EE) no screens found(EE) 
[   464.664] (EE) 
Please consult the The X.Org Foundation support 
     at http://wiki.x.org
 for help. 
[   464.664] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   464.664] (EE) 
[   464.664] (EE) Server terminated with error (1). Closing log file.



  


  I am using this github repo to setup the video-streamer

  


  If anyone wants the colab notebook for the example then I will add it over here.

  


  For this problem I am really not sure where to file an issue for this so that's why I am writing this here.

  


• Introducing the Data Warehouse Connector feature

  30 janvier, par Matomo Core Team

  Matomo is built on a simple truth : your data belongs to you, and you should have complete control over it. That’s why we’re excited to launch our new Data Warehouse Connector feature for Matomo Cloud, giving you even more ways to work with your analytics data. 

  Until now, getting raw data from Matomo Cloud required APIs and custom scripts, or waiting for engineering help.  

  Our new Data Warehouse Connector feature removes those barriers. You can now access your raw, unaggregated data and schedule regular exports straight to your data warehouse. 

  The feature works with all major data warehouses including (but not limited to) : 

  • Google BigQuery 
  • Amazon Redshift 
  • Snowflake 
  • Azure Synapse Analytics 
  • Apache Hive 
  • Teradata 

  You can schedule exports, combine your Matomo data with other data sources in your data warehouse, and easily query data with SQL-like queries. 

  Direct raw data access for greater data portability 

  Waiting for engineering support can delay your work. Managing API connections and writing scripts can be time-consuming. This keeps you from focusing on what you do best—analysing data. 

  

  With the Data Warehouse Connector feature, you get direct access to your raw Matomo data without the technical setup. So, you can spend more time analysing data and finding insights that matter. 

  Bringing your data together 

  Answering business questions often requires data from multiple sources. A single customer interaction might span your CRM, web analytics, sales systems, and more. Piecing this data together manually is time-consuming—what starts as a seemingly simple question from stakeholders can turn into hours of work collecting and comparing data across different tools. 

  This feature lets you combine your Matomo data with data from other business systems in your data warehouse. Instead of switching between tools or manually comparing spreadsheets, you can analyse all your data in one place to better understand how customers interact with your business. 

  Easy, custom analysis with SQL-like queries 

  Standard, pre-built reports often don’t address the specific, detailed questions that analysts need to answer.  

  When you use the Data Warehouse Connector feature, you can use SQL-like queries in your data warehouse to do detailed, customised analysis. This flexibility allows you to explore your data in depth and uncover specific insights that aren’t possible with pre-built reports. 

  

  Here is an example of how you might use SQL-like query to compare the behaviours of paying vs. non-paying users : 

  				
                                          <xmp>SELECT  
  
  
  
  custom_dimension_value AS user_type, -- Assuming 'user_type' is stored in a custom dimension 
  
  
  
  COUNT(*) AS total_visits,  
  
  
  
  AVG(visit_total_time) AS avg_duration, 
  
  
  
  SUM(conversion.revenue) AS total_spent  
  
  
  
  FROM  
  
  
  
  `your_project.your_dataset.matomo_log_visit` AS visit 
  
  
  
  LEFT JOIN  
  
  
  
  `your_project.your_dataset.matomo_log_conversion` AS conversion  
  
  
  
  ON  
  
  
  
  visit.idvisit = conversion.idvisit  
  
  
  
  GROUP BY  
  
  
  
  custom_dimension_value; </xmp>
  
                                  
  			

  This query helps you compare metrics such as the number of visits, average session duration, and total amount spent between paying and non-paying users. It provides a full view of behavioural differences between these groups. 

  Advanced data manipulation and visualisation 

  When you need to create detailed reports or dive deep into data analysis, working within the constraints of a fixed user interface (UI) can limit your ability to draw insights. 

  Exporting your Matomo data to a data warehouse like BigQuery provides greater flexibility for in-depth manipulation and advanced visualisations, enabling you to uncover deeper insights and tailor your reports more effectively. 

  Getting started 

  To set up data warehouse exports in your Matomo : 

  1. Go to System Admin (cog icon in the top right corner) 
  2. Select ‘Export’ from the left-hand menu 
  3. Choose ‘Data Warehouse Connector’ 

  You’ll find detailed instructions in our data warehouse exports guide.  

  Please note, enabling this feature will cost an additional 10% of your current subscription. You can view the exact cost by following the steps above. 

  New to Matomo ? Start your 21-day free trial now (no credit card required), or request a demo. 

  Try Matomo for Free

  21 day free trial. No credit card required.

  
  

  Your email address
  

  Your website address
  

  Your Analytics subdomain will be .matomo.cloud (change)

  Choose your analytics subdomain
  

  .matomo.cloud

  I accept the terms and conditions and data processing agreement (DPA)

  
  Your information will be used to create an account on our cloud service. For more information please consult our privacy policy.
  
  
  

  Start improving your websites now

  

• VP8 : a retrospective

  13 juillet 2010, par Dark Shikari — DCT, VP8, speed

  I’ve been working the past few weeks to help finish up the ffmpeg VP8 decoder, the first community implementation of On2′s VP8 video format. Now that I’ve written a thousand or two lines of assembly code and optimized a good bit of the C code, I’d like to look back at VP8 and comment on a variety of things — both good and bad — that slipped the net the first time, along with things that have changed since the time of that blog post.

  These are less-so issues related to compression — that issue has been beaten to death, particularly in MSU’s recent comparison, where x264 beat the crap out of VP8 and the VP8 developers pulled a Pinocchio in the developer comments. But that was expected and isn’t particularly interesting, so I won’t go into that. VP8 doesn’t have to be the best in the world in order to be useful.

  When the ffmpeg VP8 decoder is complete (just a few more asm functions to go), we’ll hopefully be able to post some benchmarks comparing it to libvpx.

  1. The spec, er, I mean, bitstream guide.

  Google has reneged on their claim that a spec existed at all and renamed it a “bitstream guide”. This is probably after it was found that — not merely was it incomplete — but at least a dozen places in the spec differed wildly from what was actually in their own encoder and decoder software ! The deblocking filter, motion vector clamping, probability tables, and many more parts simply disagreed flat-out with the spec. Fortunately, Ronald Bultje, one of the main authors of the ffmpeg VP8 decoder, is rather skilled at reverse-engineering, so we were able to put together a matching implementation regardless.

  Most of the differences aren’t particularly important — they don’t have a huge effect on compression or anything — but make it vastly more difficult to implement a “working” VP8 decoder, or for that matter, decide what “working” really is. For example, Google’s decoder will, if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN. Is this a bug ? Or is this how it’s supposed to work ? It’s hard to tell — there isn’t a spec to say so. Google says that whatever libvpx does is right, but I doubt they intended this.

  I expect a spec will eventually be written, but it was a bit obnoxious of Google — both to the community and to their own developers — to release so early that they didn’t even have their own documentation ready.

  2. The TM intra prediction mode.

  One thing I glossed over in the original piece was that On2 had added an extra intra prediction mode to the standard batch that H.264 came with — they replaced Planar with “TM pred”. For i4x4, which didn’t have a Planar mode, they just added it without replacing an old one, resulting in a total of 10 modes to H.264′s 9. After understanding and writing assembly code for TM pred, I have to say that it is quite a cool idea. Here’s how it works :

  1. Let us take a block of size 4×4, 8×8, or 16×16.

  2. Define the pixels bordering the top of this block (starting from the left) as T[0], T[1], T[2]…

  3. Define the pixels bordering the left of this block (starting from the top) as L[0], L[1], L[2]…

  4. Define the pixel above the top-left of the block as TL.

  5. Predict every pixel <X,Y> in the block to be equal to clip3( T[X] + L[Y] – TL, 0, 255).

  It’s effectively a generalization of gradient prediction to the block level — predict each pixel based on the gradient between its top and left pixels, and the topleft. According to the VP8 devs, it’s chosen by the encoder quite a lot of the time, which isn’t surprising ; it seems like a pretty good idea. As just one more intra pred mode, it’s not going to do magic for compression, but it’s a cool idea and elegantly simple.

  3. Performance and the deblocking filter.
  

  On2 advertised for quite some that VP8′s goal was to be significantly faster to decode than H.264. When I saw the spec, I waited for the punchline, but apparently they were serious. There’s nothing wrong with being of similar speed or a bit slower — but I was rather confused as to the fact that their design didn’t match their stated goal at all. What apparently happened is they had multiple profiles of VP8 — high and low complexity profiles. They marketed the performance of the low complexity ones while touting the quality of the high complexity ones, a tad dishonest. More importantly though, practically nobody is using the low complexity modes, so anyone writing a decoder has to be prepared to handle the high complexity ones, which are the default.

  The primary time-eater here is the deblocking filter. VP8, being an H.264 derivative, has much the same problem as H.264 does in terms of deblocking — it spends an absurd amount of time there. As I write this post, we’re about to finish some of the deblocking filter asm code, but before it’s committed, up to 70% or more of total decoding time is spent in the deblocking filter ! Like H.264, it suffers from the 4×4 transform problem : a 4×4 transform requires a total of 8 length-16 and 8 length-8 loopfilter calls per macroblock, while Theora, with only an 8×8 transform, requires half that.

  This problem is aggravated in VP8 by the fact that the deblocking filter isn’t strength-adaptive ; if even one 4×4 block in a macroblock contains coefficients, every single edge has to be deblocked. Furthermore, the deblocking filter itself is quite complicated ; the “inner edge” filter is a bit more complex than H.264′s and the “macroblock edge” filter is vastly more complicated, having two entirely different codepaths chosen on a per-pixel basis. Of course, in SIMD, this means you have to do both and mask them together at the end.

  There’s nothing wrong with a good-but-slow deblocking filter. But given the amount of deblocking one needs to do in a 4×4-transform-based format, it might have been a better choice to make the filter simpler. It’s pretty difficult to beat H.264 on compression, but it’s certainly not hard to beat it on speed — and yet it seems VP8 missed a perfectly good chance to do so. Another option would have been to pick an 8×8 transform instead of 4×4, reducing the amount of deblocking by a factor of 2.

  And yes, there’s a simple filter available in the low complexity profile, but it doesn’t help if nobody uses it.

  4. Tree-based arithmetic coding.

  Binary arithmetic coding has become the standard entropy coding method for a wide variety of compressed formats, ranging from LZMA to VP6, H.264 and VP8. It’s simple, relatively fast compared to other arithmetic coding schemes, and easy to make adaptive. The problem with this is that you have to come up with a method for converting non-binary symbols into a list of binary symbols, and then choosing what probabilities to use to code each one. Here’s an example from H.264, the sub-partition mode symbol, which is either 8×8, 8×4, 4×8, or 4×4. encode_decision( context, bit ) writes a binary decision (bit) into a numbered context (context).

  8×8 : encode_decision( 21, 0 ) ;

  8×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 0 ) ;

  4×8 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 1 ) ;

  4×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 0 ) ;

  As can be seen, this is clearly like a Huffman tree. Wouldn’t it be nice if we could represent this in the form of an actual tree data structure instead of code ? On2 thought so — they designed a simple system in VP8 that allowed all binarization schemes in the entire format to be represented as simple tree data structures. This greatly reduces the complexity — not speed-wise, but implementation-wise — of the entropy coder. Personally, I quite like it.

  5. The inverse transform ordering.

  I should at some point write a post about common mistakes made in video formats that everyone keeps making. These are not issues that are patent worries or huge issues for compression — just stupid mistakes that are repeatedly made in new video formats, probably because someone just never asked the guy next to him “does this look stupid ?” before sticking it in the spec.

  One common mistake is the problem of transform ordering. Every sane 2D transform is “separable” — that is, it can be done by doing a 1D transform vertically and doing the 1D transform again horizontally (or vice versa). The original iDCT as used in JPEG, H.263, and MPEG-1/2/4 was an “idealized” iDCT — nobody had to use the exact same iDCT, theirs just had to give very close results to a reference implementation. This ended up resulting in a lot of practical problems. It was also slow ; the only way to get an accurate enough iDCT was to do all the intermediate math in 32-bit.

  Practically every modern format, accordingly, has specified an exact iDCT. This includes H.264, VC-1, RV40, Theora, VP8, and many more. Of course, with an exact iDCT comes an exact ordering — while the “real” iDCT can be done in any order, an exact iDCT usually requires an exact order. That is, it specifies horizontal and then vertical, or vertical and then horizontal.

  All of these transforms end up being implemented in SIMD. In SIMD, a vertical transform is generally the only option, so a transpose is added to the process instead of doing a horizontal transform. Accordingly, there are two ways to do it :

  1. Transpose, vertical transform, transpose, vertical transform.

  2. Vertical transform, transpose, vertical transform, transpose.

  These may seem to be equally good, but there’s one catch — if the transpose is done first, it can be completely eliminated by merging it into the coefficient decoding process. On many modern CPUs, particularly x86, transposes are very expensive, so eliminating one of the two gives a pretty significant speed benefit.

  H.264 did it way 1).

  VC-1 did it way 1).

  Theora (inherited from VP3) did it way 1).

  But no. VP8 has to do it way 2), where you can’t eliminate the transpose. Bah. It’s not a huge deal ; probably only 1-2% overall at most speed-wise, but it’s just a needless waste. What really bugs me is that VP3 got it right — why in the world did they screw it up this time around if they got it right beforehand ?

  RV40 is the other modern format I know that made this mistake.

  (NB : You can do transforms without a transpose, but it’s generally not worth it unless the intermediate needs 32-bit math, as in the case of the “real” iDCT.)

  6. Not supporting interlacing.

  THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU.

  Interlacing was the scourge of H.264. It weaseled its way into every nook and cranny of the spec, making every decoder a thousand lines longer. H.264 even included a highly complicated — and effective — dedicated interlaced coding scheme, MBAFF. The mere existence of MBAFF, despite its usefulness for broadcasters and others still stuck in the analog age with their 1080i, 576i , and 480i content, was a blight upon the video format.

  VP8 has once and for all avoided it.

  And if anyone suggests adding interlaced support to the experimental VP8 branch, find a straightjacket and padded cell for them before they cause any real damage.