Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 468406 - Removal of media-libs/win32codecs, media-libs/amd64codecs (and related use-flags win32codecs, real)
Summary: Removal of media-libs/win32codecs, media-libs/amd64codecs (and related use-fl...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Licenses team
URL:
Whiteboard: Pending removal: 2013-06-12
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-03 10:38 UTC by Hanno Böck
Modified: 2013-09-22 14:01 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
The sample of video coded with vp7 (sample.avi,976.56 KB, application/octet-stream)
2013-09-22 03:51 UTC, Arthur D.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hanno Böck gentoo-dev 2013-05-03 10:38:29 UTC
The packages
media-libs/win32codecs
media-libs/amd64codecs
have an unclear licensing situation. With that, we'd also like to remove
media-libs/realcodecs
which has been masked for ages due to security issues.

According to discussions in the license-team, to the best of our knowledge they shouldn't be needed any more. Some packages activate them through the win32codecs USE-flag, others through the real USE-flag.
Our plan is to mask and lastrite them, use-mask the according flags and when we're done also remove the according USE-flags.

If you think any of those packages is still needed, please provide a link to videos in the wild. To our knowledge, all relevant codecs that previously needed win32codecs or realcodecs are now supported by plain ffmpeg/libav.
Comment 1 Ulrich Müller gentoo-dev 2013-06-09 15:27:35 UTC
Packages removed. Leaving this bug open for removal of the USE flags.

- The "win32codecs" flag is not used any more by any package.
- The "real" flag still exists in media-video/mplayer and
  media-video/mplayer2, but it's not entirely clear to me what effect
  it has when there are no binary codecs present.

Furthermore, the "real" flag is masked in profiles/base/use.mask and unmasked for mplayer (but not for mplayer2) in profiles/base/package.use.mask, plus a couple of masks and unmasks in the prefix profiles.
Comment 2 Ulrich Müller gentoo-dev 2013-06-13 16:21:26 UTC
The win32codecs flag has been removed.

I've opened bug 473206 for the remaining issue with the real flag. This is not a license issue though, therefore closing this bug.
Comment 3 Arthur D. 2013-09-22 03:12:04 UTC
VP7 codec is not supported by mplayer + ffmpeg.
You can check this by running:
ffmpeg -codecs

You will find this:
 D.V.L. vp3                  On2 VP3
 D.V.L. vp5                  On2 VP5
 D.V.L. vp6                  On2 VP6
 D.V.L. vp6a                 On2 VP6 (Flash version, with alpha channel)
 D.V.L. vp6f                 On2 VP6 (Flash version)
 D.V.L. vp8                  On2 VP8

So VP7 is missing.

I wasn't able to find free alternative to play appropriate movie after removing win32codecs from Gentoo.
I think it's too early to remove the package and it should be returned.
There sould be other codecs not implemented yet.
Comment 4 Arthur D. 2013-09-22 03:14:51 UTC
Should I open a new bug report about this?
Comment 5 Nikoli 2013-09-22 03:24:33 UTC
Can you provide sample?
Comment 6 Arthur D. 2013-09-22 03:51:17 UTC
Created attachment 359214 [details]
The sample of video coded with vp7

I split the video to 1 MB pieces.
Here's the first piece of it (it's 8 seconds sample).
As I can see the sound is played fine and the video is skipped because of codec problem (this message of mplayer):
 none (VP70 / 0x30375056), 640x272): unknown codec

You should be able to reproduce the problem.
Is that enough?

This should provide the key for solution:
$ mplayer -vc help | grep "vp7"
vp7         vfwex     working   On2 VP7 Personal Codec  [vp7vfw.dll]

And probably there are a lot of codecs not implemented yet:
$ mplayer -vc help | grep "\.dll"
...
Comment 7 Hanno Böck gentoo-dev 2013-09-22 09:03:22 UTC
Seems this is a valid reason to keep win32codecs, although in many years I never found such a video in the wild.

Before we start any discussion about reviving it: It has many open issues and we'd need someone volunteering to take care of them, especially security-issues (which is rather nontrivial as I think they're rarely triaged upstream). A maintainer or a proxy-maintainer. Is anyone willing to do that?
Comment 8 Ulrich Müller gentoo-dev 2013-09-22 13:13:00 UTC
(In reply to Hanno Boeck from comment #7)
> Seems this is a valid reason to keep win32codecs, although in many years I
> never found such a video in the wild.
> 
> Before we start any discussion about reviving it: It has many open issues
> and we'd need someone volunteering to take care of them, especially
> security-issues (which is rather nontrivial as I think they're rarely
> triaged upstream). A maintainer or a proxy-maintainer. Is anyone willing to
> do that?

The license situation needs to be solved before the package can be readded. The minimum requirement is that there is a location from where users can legally download the codecs.
Comment 9 Nikoli 2013-09-22 13:21:08 UTC
mpv and vlc built with libav-9.9 can not play video from sample, only sound.
Comment 10 Nikoli 2013-09-22 13:29:49 UTC
btw,
$ file /sample.avi 
sample.avi: Matroska data
Comment 11 Nikoli 2013-09-22 14:01:29 UTC
Bug is now reported to libav and ffmpeg upstreams:
https://bugzilla.libav.org/show_bug.cgi?id=566
https://trac.ffmpeg.org/ticket/2983

Seems like VP7 codec is used *very* rare (everyone i asked does not use it), i think restoring win32codecs only for vp7 is not justified. If someone really needs to play VP7 video, he can install dlls manually.

Arthur, do you know any other codecs or samples, not supported without win32codecs by latest libav and ffmpeg versions?