Use WebM as the default video format

This bug is an upstream one and it would be quite helpful if somebody experiencing it could send the bug the to the people writing the software. You can learn more about how to do this for various upstreams at https://wiki.ubuntu.com/Bugs/Upstream.
Once submitted upstream , do report back here with the upstream bug number.
Thanks in advance!

Currently it cannot be used for telepathy for #telepathy

"currently there's no standard for vp8 rtp payloaders or depayloader, until there is a standard, it can't very well realistically be used for voip"

If the above is true, it is the same issue with the SIP protocol, thus invalid for Ekiga too.

Best regards,
Yannick

That would go for pidgin as well, but isn't a standard planned? Wouldn't that mean this bug isn't invalid?

For some reason i can't link recordmydesktop to the upstream bug: https://sourceforge.net/tracker/?func=detail&aid=3016200&group_id=172357&atid=861428

Thanks for sending upstream

@Danny Piccirillo For telepathy, bugs should be opened for telepathy gabble, farsight2 and gstreamer but empathy is not related at all.

@Omer Akram

Okay thanks. Hopefully i've added them correctly! Let me know if not

Oops, didn't mean to add this in the first place

Surely these bugs cannot be usefully completed until the ffmpeg .deb in maverick starts having compiled-in webm support?

e.g., there's not much point in recordmydesktop making .webm files when none of the editors (e.g., pitivi) based around ffmpeg can edit them

ffmpeg upstream has had webm support since it was announced, and it should have it by maverick. pitivi is based on gstreamer, not ffmpeg, which has also had webm support upstream since the announcement.

I think you'll find that the official ffmpeg trunk has only had vpx encoding for around 12 days, and webm muxing for about 8 days. Maverick is still on ffmpeg 0.5.1 (0.5.2 is latest official release) and Ubuntu tracks releases rather than svn snapshots.

I'd hence hypothesis that the bugs you've raised again 'project (Ubuntu)' packages are all invalid until a) (at the very least) ffmpeg and gstreamer have made official releases with vpx and webm support and b) the upstreams for each of the projects have similarly made releases with support for vpx and webm either through their own direct linking against libvpx etc., or via ffmpeg/gstreamer prereq

Hmm...FFmpeg 0.6 released, codenamed "Works with HTML 5"
http://lwn.net/Articles/392248/

upstream bug comment

"Farsight2 doesn't pick codecs. The preferences are set by the application by
calling fs_session_set_codec_preferences().

That said, as soon as there is a more or less standardised RTP payloading for
VP8. I do plan to advertise it as the best format to use."

Marking the pidgin task triaged since we now have an upstream bug.

Upstream bug was marked dup of https://bugzilla.gnome.org/show_bug.cgi?id=564957 , changing bug watch.

Comment #15 : does this mean that Google did not give yet all informations about WebM ?

For rendering in PiTivi and converting in VLC

@Danny Piccirillo : While your efforts at championing this change is appreciated , you do realize that you are spamming everyone right?

As of now, there are 11ubuntu tasks and 12 upstream tasks in this bug report and the changes in each of those tasks spam everyone. Not everyone is interested in all the tasks listed here.

Kindly stop abusing this bug report and do not add any more tasks here.

In future, kindly open separate bug reports rather than opening such meta bugs.
Copy-pasting one line descriptions to a new bug surely does not take much effort, I hope.

telepathy-gabble is not involved in this.

Empathy is already ready for this. We "just" need a VP8 payloader/depayloader in GStreamer.

This is for VLC's convert wizard. The default preset should be WebM instead of a proprietary format

Cheese Upstream had set the bugzilla bug as a dup of https://bugzilla.gnome.org/show_bug.cgi?id=564957 , which is already being tracked in Bug 385344 .
Ideally if this bug had only a single cheese task, I could have duped it but since this has several other tasks. Closing this bug report.

Anyone interested in this, Kindly subscribe to Bug 385344 .

I mean , closing the cheese task in this bug report!:-)

Per https://bugs.launchpad.net/cheese/+bug/593477/comments/25

per https://bugs.launchpad.net/cheese/+bug/593477/comments/25

In reply to comment #25
> This is for VLC's convert wizard. The default preset should be WebM instead of a proprietary format

From Wikipedia: "In telecommunications, a proprietary protocol is a communications protocol owned by a single organization or individual."

WebM is fully controlled by Google, and hence proprietary.

The VLC default video codec is H.264, an international standard (ISO/IEC 14496-10 - MPEG-4 Part 10, Advanced Video Coding). That does not fit my definition of "proprietary". You can get the specification for free there http://www.itu.int/rec/T-REC-H.264 . There are also top-notch open-source implementations, FFmpeg/lavc for decoding, x264 for encoding.

I guess you meant "patent-encumbered" rather than "proprietary". The VideoLAN projec operates under EU legislation which does not recognize software patent. If you live somewhere else, please don't make it the VLC media player developer's problem. Back to invalid state.

@Rémi Denis-Courmont: VP8 is endorsed by the Free Software Foundation as its patent license is compliant with software freedom. It is because Google owned the patents that they were able to license them with that open license. Patents aren't code. You can't "release" them or nullify them once they are issued. H.264 is a for-profit format whose ulterior existence reason is commercial, and most of its pool members have proven evil throughout their existence. "Top-notch open-source implementations" exist for VP8 too. libavcodec's ffvp8 decoder is faster than their ffh264 decoder. VP8 encoding in x264 is being developed as project xvp8 and will be internally integrated into x264. Thanks for nothing Remi.

You are assuming that they are no other patents than Google's on VP8. This is an unproven assertion, and some experts have clearly voiced their serious doubts.

The VideoLAN project has an informal policy of not taking software patents into accounts when taking decision for the simple reason that: 1/ they are invalid in Europe, where the project is based, and 2/ there is no way to determine that a certain piece of code does not infringe any patent (you cannot come and ask the patent office for that kind of assertion).

The VideoLAN project is a non-profit and it will not let its policy be dictated by the FSF or Ubuntu zealots. If you have a problem with that, you better take it up with the VideoLAN project directly than through Launchpad.

So in your country, both H.264 and VP8 are on the same grounds legally. Then why do you choose H.264 over VP8?

1-The VP8 format bitstream is final, and its patents are provided under an open license, so there is nothing left for Google to control, apart from developing/improving the reference implementation. Other independent implementations for both decoding and encoding exist. They don't relate to Google whatsoever.

2-Patent infringement claims have been there since eternity, and they're literally nothing but FUD. Where is the patent pool that was being put together to "go after" Theora?

3-Google said several times it has no intention to control the format and, for future iterations of the format, they called anyone willing to join them. However, why would companies and research firms submit their patents and ideas to the WebM project when they can submit them to MPEG-LA and collect massive royalties?

4-Lead x264 developer stated that, with enough work, VP8 can have equal quality to H.264. And on IRC, he acutally said it that VP8 can surpass H.264 in 8-bit given a good encoder. He is just saying that the reference implementation sucks and is giving the format a bad name.

I would like to thank Google for their investment in cracking the MPEG-LA audio/video monopoly and for their trials in making a better, patent-troll-free world. Lastly, I don't actually think VLC is a recommended way to encode video. Therefore I don't really care if H.264 continues to be the default.

AVC offers much better compatibility across encapsulation formats (notably MPEG-TS) and playback devices than WebM currently does. The Ubuntu community is not going to take care of the surge of support request and bad publicity a new version of VLC gets if it breaks that compatibility.

VP8/WebM is supported, but I do not believe it would an appropriate default choice at this point in time.

So it’s been a year since this opened, and little change anywhere on the desktop. Any updates?