Skip to main content

War of formats: OGG Theora vs H264

From Slashdot via Fedora Mexico.
Sad thing is h264 will be patented which is no different than MP3 back then. It is all about control. *sigh*

Comments

Anonymous said…
It has always been a measure of control. To think that the codec debate that has come out of HTML5 is anything but that is rather naive.
To say that MPEG-LA will be docile with it's handling of the Mpeg-4 technology is also naive. I am not doing to say that Theora is great (it's improving in an impressive measure, but it's not great yet), but it really seem to be the only option for free-flowing video data.

I am not sure that people will be saying the same things of H.264 (which, from my own look at the decoders, is problematic) if and/or when MPEG-LA cracks down on the patents. And there is way too much money in play for MPEG-LA not to do some legal in that space, the royalties that they will make on something like Blu-ray alone will be astronomical. I am looking at this as a simple "John Doe" going that it's way too much money to over look. And I doubt that MPEG-LA will... if history has shown.



What I consider curious with Google in this debate is that One, Youtube hasn't done a full change into the format yet. The only thing that I have seen is Youtube tinkering with the video tag so far... so I am not sure if H.264 is the format of choice yet over Youtube.

Second, as a provider of content, moving to H.264 would be highly unwise for Youtube to do. Google is not known to hiring idiots, I think that they clearly know that this with the looming spectre of patent enforcement the space that H.264 holds will become volatile (How much so is anyone's guess). Youtube, nor Google doesn't seem to be the type of company to bet the data farm on that... I could be wrong through, but that is Google's bread and butter. I expect them to be protective of that.

Third, I was looking at the Chrome 3 builds a few days ago [See here], and there is something curious in it's use of ffmpeg, the decoders libaries they they use in the video and audio tags... if you look at the build tags they use for ffmpeg, everything except all that is needed for Theora libraries (and OGG and Vorbis) is disabled. Or what is what they are suggesting that is how it should be build.

That said, you are saying what I have been saying for years.
What I consider curious with Google in this debate is that One, Youtube hasn't done a full change into the format yet. The only thing that I have seen is Youtube tinkering with the video tag so far... so I am not sure if H.264 is the format of choice yet over Youtube.


Mozilla did a test and posted the result with screenshots. Google can also include Theora support. From what I read, the assertion that Theora is no good is based on outdated information.

Thank you for this insightful comment.

Still
Anonymous said…
What I mean by that is that Youtube's actions at the moment have been... timid when compared to a content provider like Dalymotion, whom committed to Theora in full force.

If anything, life at Youtube remains unchanged. Currently.

I have been speaking about how the video tag would really change how youtube provide content for a few months now. Since as good as it is now, there is a barrier. If your browser of choice didn't have a plug-in for flash video (there are a few), there was very little hope for you with youtube... either as a developer or as a user.
You could rely on something like Gnash or swfdec, but they are limited in what they can do and/or are hopeless behind what Adobe does with Flash.
As much as I see this push to move into Silverlight with online video, I see Moonlight in the same spot as Gnash or swfdec. Limited in what it is capable of and behind what Microsoft does with Silverlight (through with some co-operation with MS, it's not as bad. But it's still bad.)

This sidesteps that wall (assuming that the raging codec debate settles with a clear winner) completely.
Personally speaking, I see Theora doing very well in this space, since it would simply allow for free-flowing video data (based on it's licensing alone) over the internet... something that Google thrives on with text ad's currently.

If Youtube's tinkering with the video tag is something of an indication. That point (that Google earns lots of money when data [text or otherwise] is free-flowing) is not lost on Google, and they are investigating their options. It's really a matter of the codec debate being solved with something that pleases all parties... but I can't see that can of worms being solved before HMTL5 is presented to W3C, (where it's likely to be more of a mess in it's current state, with so many vested interests in W3C's corporate membership).

Popular posts from this blog

Detailing the installation of AMD OpenCL rpm for Fedora

Revisiting the previous blog and freshly reinstalling Fedora Design Suite due to a busted boot, I look at the official guideline from AMD Driver for Red Hat Enterprise Linux 7.2 and write a way to improve the process of installing on Fedora 29 in this example.



Extracting the tarball contains the following:
amdgpu-installamdgpu-pro-install symlink to amdgpudoc folderrepodata folderRPMS folder containing rpm package
Executing the command ./amdgpu-install -opencl=pal --headless sadly failed on Fedora on that line:

./amdgpu-install -y --opencl=pal --headless
Last metadata expiration check: 0:30:51 ago on Mon 19 Nov 2018 07:13:43 PM PST.
No match for argument: amdgpu

Upon closer look, the script failed to created a temporary repository on /var/opt/amdgpu-pro-local probably explaining why amdgpu metapackage name failed to display. Someone should investigate and provide a fix. At least, we find out Fedora support is available but unofficial.

Due to its design, Gnome Software only allows one cli…

Using AMD RX Vega driver OpenCL on Fedora 29

The Raven Ridge APU is very capable processor to handle OpenCL inside some applications like Blender, Darktable and Gimp. Unfortunately, the current implementation from Mesa, clover, stuck to 1.3, is not supported. AMD released their driver 18.40 with OpenCL2.0+ targeting only Red Hat Enterprise Linux/Cent OS 6.10 and 7.5 in addition of Ubuntu LTS. The good new is the former rpm format can be used on Fedora.

The graphical part of Raven Ridge is Vega 8, basically a cut-down of Vega56 or Vega64 meaning choosing either driver for RX Vega.
The instruction is provided for extracting the rpm files but here is
 some requirements for OpenCL:
kernel-devel (provided by Fedora repository)amdgpu-dkmsdkmslibopencl-amdgpu-proopencl-amdgpu-pro-icd Once done, applications needing OpenCL will automatically detect the driver located on /opt/amdgpu/lib64. Blender will list as unknown AMD GPU and Darktable will enable it.



There is a ROCm version but it currently does not support the graphical side of Rav…

HP, Linux and ACPI

Majority of HP hardware running on Linux and even Microsoft reported an issue related to a non-standard compliant ACPI. Notable message below repeats at least three times on the boot:


4.876549] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20190215/dsopcode-198) 
[ 4.876555] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_BUFFER_LIMIT) (20190215/psparse-529) 
[ 4.876562] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_BUFFER_LIMIT) (20190215/psparse-529)


The bug is a known for years from which Linux kernel team are unable to fix without the help of vendor i.e. HP. Here is a compilation of reports:
BIOS error: The BIOS in this system is not fully ACPI compliant. ACPI BIOS ERROR (blue screen) on startup ACPI bad works with Linux  The good news is some errors seems harmless. Unfortunately, such errors displayed the quirks approach used by vendors to support …