Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 464676 - www-client/chromium-27.0.1453.12 libav compatibility?
Summary: www-client/chromium-27.0.1453.12 libav compatibility?
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Chromium Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-05 07:31 UTC by Nikos Chantziaras
Modified: 2013-05-21 17:01 UTC (History)
10 users (show)

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


Attachments
lu_zero-464676.patch (lu_zero-464676.patch,1.06 KB, patch)
2013-04-11 19:36 UTC, Mike Gilbert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos Chantziaras 2013-04-05 07:31:28 UTC
Updating Chromium to 27.0.1453.12 results in portage wanting to unmerge libav. I cannot see any USE flag that would make chromium use libav, or use a bundled ffmpeg.

This really needs to be addressed in some way. I do not mind installing ffmpeg, but I do very much mind uninstalling libav (so I masked this Chromium version for now.)
Comment 1 Michael Hampicke 2013-04-05 07:43:15 UTC
I noticed that yesterday too. I mean there are a number other packages out there depending on ffmpeg (like mplayer2 and vlc with USE="postproc") but as of yesterday that was not a problem. Till now I had both libav and ffmpeg installed.
Comment 2 Mike Gilbert gentoo-dev 2013-04-05 18:32:09 UTC
Have you tested to see if chromium will build against libav?
Comment 3 Martin Jansa 2013-04-05 19:11:16 UTC
(In reply to comment #2)
> Have you tested to see if chromium will build against libav?

with libav-9.4 it fails:

media/filters/audio_file_reader.cc: In member function ‘int media::AudioFileReader::Read(media::AudioBus*)’:
media/filters/audio_file_reader.cc:183:21: error: ‘struct AVFrame’ has no member named ‘channels’
media/filters/audio_file_reader.cc:188:52: error: ‘struct AVFrame’ has no member named ‘channels’
Comment 4 Nikos Chantziaras 2013-04-05 19:19:15 UTC
(In reply to comment #2)
> Have you tested to see if chromium will build against libav?

I don't think it will work. (I assume you ask due to the title of this bug. I didn't write that; it was changed by someone else.)
Comment 5 Mike Gilbert gentoo-dev 2013-04-05 19:47:55 UTC
A ha. I imagine we need ffmpeg because of some difference from libav that chromium relies on. phajdan would know more about that.
Comment 6 Nikos Chantziaras 2013-04-05 20:12:01 UTC
It might be worth (re?)introducing a flag to use the bundled ffmpeg, if that's possible. Normally I'd try and see if I can patch-in libav support myself, but due to lack of time and in combination with the insane compilation times of Chromium, that's not an option at this moment.
Comment 7 Alexandre Rostovtsev (RETIRED) gentoo-dev 2013-04-06 01:17:08 UTC
If chromium doesn't support libav, IMHO the ebuild should bring back the system-ffmpeg USE flag. Chromium is the only application I have installed which does not respect virtual/ffmpeg, and I would prefer to use libav to satisfy the virtual.
Comment 8 Diego Elio Pettenò (RETIRED) gentoo-dev 2013-04-11 07:40:48 UTC
Basically you're forcing crapware down the throat of users without even a notice.

+1 for reintroducing the USE flag so that one can at least merge the thing.
Also +1 for actually patching those tinsy bits that it would fail on.
Comment 9 Nicolas George 2013-04-11 19:28:21 UTC
(In reply to comment #0)
> but I do very much mind uninstalling libav (so I masked this

ffmpeg can act as a drop-in compatible replacement for libav, both in source and binary form.

May I ask why you want or need to keep libav itself?

(For reference: all enhancements and bug fixes in libav are merged into ffmpeg, usually on a daily basis, while libav mostly ignores improvements to ffmpeg.)
Comment 10 Samuli Suominen (RETIRED) gentoo-dev 2013-04-11 19:31:40 UTC
(In reply to comment #9)
> May I ask why you want or need to keep libav itself?

Don't reopen that can of worms in this bug, please. This has been discussed to death at the mailing list.

I urge everyone to avoid turning this bug into a discussion about which one should be used.
Comment 11 Mike Gilbert gentoo-dev 2013-04-11 19:36:48 UTC
Created attachment 345272 [details, diff]
lu_zero-464676.patch

I received this patch from lu_zero in IRC to fix the issue in comment 3. Ok to apply it, or do we want a fix upstream first?
Comment 12 Nicolas George 2013-04-11 20:12:23 UTC
(In reply to comment #10)
> Don't reopen that can of worms in this bug, please. This has been discussed
> to death at the mailing list.
> 
> I urge everyone to avoid turning this bug into a discussion about which one
> should be used.

I do not intend to start a flame-war, please excuse me if my comment gave that impression.

I am genuinely interested in the reasons people have for choosing libav, if only to try and fix or improve ffmpeg, and make it suitable for their needs.

I will not comment further on the subject, except possibly to ask for technical details if someone answers. I have also no objection to continuing this in private mail.
Comment 13 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-04-11 20:17:39 UTC
(In reply to comment #11)
> Created attachment 345272 [details, diff] [details, diff]
> lu_zero-464676.patch
> 
> I received this patch from lu_zero in IRC to fix the issue in comment 3. Ok
> to apply it, or do we want a fix upstream first?

I think you'll also need to patch media/filters/ffmpeg_audio_decoder.cc

Please remember to test with ffmpeg, including video playback (I usually use http://sublimevideo.net/ for testing).

It's fine to apply the patch - could you just submit it upstream as well and CC me?
Comment 14 Nicolas George 2013-04-11 20:23:38 UTC
(In reply to comment #11)
> Created attachment 345272 [details, diff] [details, diff]
> lu_zero-464676.patch
> 
> I received this patch from lu_zero in IRC to fix the issue in comment 3. Ok
> to apply it, or do we want a fix upstream first?

Technical information:

This patch may break audio playback of some files with ffmpeg. Unlike libav, ffmpeg can output frames with channel_layout = 0 when the information is not present in the source file and can not be reliably guessed, and the relrevant information is only present in the channels field.

I can look for a sample file to exhibit the problem if you want.
Comment 15 Mike Gilbert gentoo-dev 2013-04-11 20:30:32 UTC
(In reply to comment #13)

lu_zero indicated that he was working on submitting this upstream himself, so I'm going to leave this to him.
Comment 16 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-04-11 21:08:22 UTC
(In reply to comment #14)
> This patch may break audio playback of some files with ffmpeg. Unlike libav,
> ffmpeg can output frames with channel_layout = 0 when the information is not
> present in the source file and can not be reliably guessed, and the
> relrevant information is only present in the channels field.
> 
> I can look for a sample file to exhibit the problem if you want.

Yes please, it'll be useful for testing, and to determine minimum required ffmpeg version for it to work (ffmpeg merges from libav, so I think it has the fix on trunk - not sure about releases).
Comment 17 Alexis Ballier gentoo-dev 2013-04-11 22:05:45 UTC
(In reply to comment #11)
> Created attachment 345272 [details, diff] [details, diff]
> lu_zero-464676.patch
> 
> I received this patch from lu_zero in IRC to fix the issue in comment 3. Ok
> to apply it, or do we want a fix upstream first?

a similar patch should be merged regardless of libav vs ffmpeg btw:
from avcodec.h:

/**
 * Audio Video Frame.
 * New fields can be added to the end of AVFRAME with minor version
 * bumps. Similarly fields that are marked as to be only accessed by
 * av_opt_ptr() can be reordered. This allows 2 forks to add fields
 * without breaking compatibility with each other.
 * Removal, reordering and changes in the remaining cases require
 * a major version bump.
 * sizeof(AVFrame) must not be used outside libavcodec.
 */


    /**
     * number of audio channels, only used for audio.
     * Code outside libavcodec should access this field using:
     * av_frame_get_channels(frame)
     * - encoding: unused
     * - decoding: Read by user.
     */
    int64_t channels;

in the avframe struct definition.

unfortunately, libav has no such av_frame_get_channels function.
Comment 18 Alexis Ballier gentoo-dev 2013-04-11 22:13:37 UTC
(In reply to comment #16)
> (In reply to comment #14)
> > This patch may break audio playback of some files with ffmpeg. Unlike libav,
> > ffmpeg can output frames with channel_layout = 0 when the information is not
> > present in the source file and can not be reliably guessed, and the
> > relrevant information is only present in the channels field.
> > 
> > I can look for a sample file to exhibit the problem if you want.
> 
> Yes please, it'll be useful for testing, and to determine minimum required
> ffmpeg version for it to work (ffmpeg merges from libav, so I think it has
> the fix on trunk - not sure about releases).

I guess what he meant is that it may not work by design and no minimum version will fix that: if a stream only has the information of the # of channels then ffmpeg will set the # of channels, not a semi-randomly guessed channel layout.

What I would suggest is to patch chromium to use av_frame_get_channels and add such code in a common header:
#if LIBAVCODEC_VERSION_MICRO >= 100
#define av_frame_get_channels(frame) av_get_channel_layout_nb_channels((frame)->channel_layout)
#endif

this should work with both versions
Comment 19 Alexis Ballier gentoo-dev 2013-04-11 22:14:32 UTC
(In reply to comment #18)
> #if LIBAVCODEC_VERSION_MICRO >= 100

sorry, this was meant to be:
#if LIBAVCODEC_VERSION_MICRO < 100
Comment 20 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-04-11 22:32:17 UTC
  11 Apr 2013; Pawel Hajdan jr
  chromium-27.0.1453.12.ebuild, chromium-9999-r1.ebuild:
  Restore system-ffmpeg USE flag, bug #464676 by Nikos Chantziaras .

Now the focus will be on libav compatibility (actually using system libav).

Nicolas, if you have a file to test with I'd still find it useful.
Comment 21 Nicolas George 2013-04-12 09:51:35 UTC
(In reply to comment #19)

I believe this updated macro is correct for both implementations, I was about to suggest the same thing.

I believe all the files in this directory:
http://fate-suite.libav.org/qt-surge-suite/
(also present in ffmpeg, but only using rsync) exhibit the behaviour difference:

field                          |  ffmpeg  |  libav  |  comment
AVCodecContext.channels        |    2     |    2    |
AVCodecContext.channel_layout  |    0     |    0    |  0 means unknown
AVFrame.channels               |    2     |         |
AVFrame.channel_layout         |    0     |    3    |  3 means stereo

There are a few files with 6 channels and unknown layout, but I believe most 6-channels files are 5.1. I did not find files with 4 channels (ambiguous between quad and 4.0) yet.

(In a near future, ffmpeg will possibly put STEREO in both channel_layout fields by default, but having a different channel_layout in AVCodecContext and AVFrame is not supposed to happen.)
Comment 22 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-04-12 18:58:23 UTC
(In reply to comment #21)
> I believe all the files in this directory:
> http://fate-suite.libav.org/qt-surge-suite/
> (also present in ffmpeg, but only using rsync) exhibit the behaviour
> difference:

Thanks! Do you have something playable as HTML5 video though? See e.g. http://en.wikipedia.org/wiki/HTML5_video and http://www.html5rocks.com/en/tutorials/video/basics/ for more info.

> field                          |  ffmpeg  |  libav  |  comment
> AVCodecContext.channels        |    2     |    2    |
> AVCodecContext.channel_layout  |    0     |    0    |  0 means unknown
> AVFrame.channels               |    2     |         |
> AVFrame.channel_layout         |    0     |    3    |  3 means stereo
> 
> There are a few files with 6 channels and unknown layout, but I believe most
> 6-channels files are 5.1. I did not find files with 4 channels (ambiguous
> between quad and 4.0) yet.
> 
> (In a near future, ffmpeg will possibly put STEREO in both channel_layout
> fields by default, but having a different channel_layout in AVCodecContext
> and AVFrame is not supposed to happen.)

I'm trying to understand... if ffmpeg regularly merges from libav, wouldn't it eventually have the same behavior for AVFrame.channel_layout?

By the way, is there an easy way to extract the above values when playing the file from command-line? While less optimal than testing from browser, it would allow me to prove or disprove above statement.
Comment 23 Nicolas George 2013-04-12 19:58:38 UTC
(In reply to comment #22)
> Thanks! Do you have something playable as HTML5 video though? See e.g.
> http://en.wikipedia.org/wiki/HTML5_video and
> http://www.html5rocks.com/en/tutorials/video/basics/ for more info.

I suspect it will not apply; there is no comprehensive list of codecs, but I suspect most of the supported ones define the channel count - channel layout mapping; I know Vorbis does, for example.

Is Chromium supposed to support only a small set of codecs? The advantage of linking with libavcodec is that a whole lot of codecs are automatically supported.

> I'm trying to understand... if ffmpeg regularly merges from libav, wouldn't
> it eventually have the same behavior for AVFrame.channel_layout?

FFmpeg merges from libav, but implements its own features and fixes bugs. In that particular case, there are two points:

* Having AVCodecContext.channel_layout != AVFrame.channel_layout was considered at least a misfeature.

* FFmpeg supports handling streams with unknown channel layouts, while libav will always "guess" a channel layout, even when none is specified in the file and there is no obvious choice (4 channels can be front left + front right + front center + subwoofer or front left + front right + rear left + rear right more or less equally), and a lot of things will not work in libav if frames with unknown layouts are inserted by an application.

In the near future, guessing the channel layout will probably be enabled at the library level, so that applications will never notice unknown channels layouts unless they are ready for them.

> By the way, is there an easy way to extract the above values when playing
> the file from command-line? While less optimal than testing from browser, it
> would allow me to prove or disprove above statement.

With ffmpeg, you can use the "-guess_layout_max 0" option to disable guessing, and you will notice, in the info dump, either "quad" or "4.0" (meaning that the channel layout is known) or "4 channels" (meaning it is unknown). That is from the AVCodecContext structure. The fields in the AVFrame structure can be extracted using "-af ashowinfo" and a dummy output (-f null -).

With avconv, the "-guess_layout_max" option does not exist, and avconv will always do the guessing. Unfortunately, the guessing is done in the application, not in the library; that means you will not see the same results as an application, unless the application also does it.
Comment 24 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-04-22 23:45:49 UTC
Status update: the issue related to AVFrame->channels field is now fixed.

Here is a new one:

media/filters/ffmpeg_demuxer.cc: In member function ‘void media::FFmpegDemuxerStream::EnqueuePacket(media::ScopedAVPacket)’:
media/filters/ffmpeg_demuxer.cc:115:41: error: ‘av_packet_split_side_data’ was not declared in this scope
media/filters/ffmpeg_demuxer.cc:119:7: error: ‘AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL’ was not declared in this scope

I'll be taking a look at this, the code above has been added in the last week.
Comment 25 Samuli Suominen (RETIRED) gentoo-dev 2013-04-23 08:00:52 UTC
*** Bug 466866 has been marked as a duplicate of this bug. ***
Comment 26 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-05-09 21:00:31 UTC
This should be fixed in chromium-28.0.1500.5 .
Comment 27 Patrizio Bassi 2013-05-11 08:33:45 UTC
iirc you can't declare fixes a bug when a version fixing it is hardmasked
Comment 28 Samuli Suominen (RETIRED) gentoo-dev 2013-05-11 11:32:37 UTC
(In reply to comment #26)
> This should be fixed in chromium-28.0.1500.5 .

hmm, nope? i see chromium-28.0.1500.5 still using media-video/ffmpeg instead of virtual/ffmpeg

(In reply to comment #27)
> iirc you can't declare fixes a bug when a version fixing it is hardmasked

you can if the dependencies are correct (ie. old versions are restricted to media-video/ffmpeg)
Comment 29 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-05-21 17:01:55 UTC
(In reply to comment #28)
> (In reply to comment #26)
> > This should be fixed in chromium-28.0.1500.5 .
> 
> hmm, nope? i see chromium-28.0.1500.5 still using media-video/ffmpeg instead
> of virtual/ffmpeg

The dependency is:

system-ffmpeg? ( || (
  >=media-video/ffmpeg-1.0:=[opus]
  >=media-video/libav-9.5:=[opus]
) )