Bug#816973: marked as pending

[Alessandro Ghedini]

On Sat, Apr 09, 2016 at 10:03:08am +, Mateusz Łukasik  wrote:
> tag 816973 pending
> thanks
> 
> Hello,
> 
> Bug #816973 reported by you has been fixed in the Git repository. You can
> see the changelog below, and you can check the diff of the fix at:
> 
> http://git.debian.org/?p=pkg-multimedia/mpv.git;a=commitdiff;h=75e886f
> 
> ---
> commit 75e886f33177df6ed88a5b6141143fdbdf4c9d22
> Author: Mateusz Łukasik 
> Date:   Sat Apr 9 12:03:51 2016 +0200
> 
> Drop mpv-dbg and libmpv-dbg packages.
> 
> diff --git a/debian/changelog b/debian/changelog
> index b01cd4e..be2d643 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,7 +1,7 @@
>  mpv (0.16.0-1) UNRELEASED; urgency=medium
>  
>* Team upload.
> -  * New upstream release. (Closes: #815692)
> +  * New upstream release. (Closes: #815692, #816973)

Please explain how you think this bug is fixed by the new release. The
commit seems completely unrelated.

Cheers


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#809710: mpv can never load external subtitle file.

[Alessandro Ghedini]

On Sun, Jan 03, 2016 at 05:30:58PM +0800, Tianming Xie wrote:
> Package: mpv
> Version: 0.14.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgraded to the current version, mpv can never load external ASS 
> subtitle
> file any more, neither a subtitle file located beside the corresponding video
> file, which may be loaded automatically when opening the video file, nor
> explicitly assigned targets via --sub-file, with the following error log:
> 
> [cplayer] Can not open external file 
> 
> The last version does not have this bug.
> 
> Subtitles embedded as stream within video files seem not affected, but I lack
> more samples to test, and now I do not have subtitle files in other formats.

Could you please provide the ASS file that doesn't work, so I can try to
reproduce this?

Thanks


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#802751: mpv leaks memory while playing vp9/opus/webm video

[Alessandro Ghedini]

On Fri, Oct 23, 2015 at 05:06:17PM +1100, Sylvain BERTRAND wrote:
> Package: mpv
> Version: 0.6.2-2
> 
> mpv fill memory while playing a vp9/opus/webm video file.
> totem is fine, it seems mpv is fine while playing an avc/aac/mp4 video file.

It's probably a ffmpeg issue, but could you upload somewhere a sample of the
file that causes this? So, I can try to reproduce.

Thanks


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#800109: mpv no longer play with --vo x11 option

[Alessandro Ghedini]

Control: tags - fixed-upstream

On Sun, Sep 27, 2015 at 11:08:14am -0500, Herminio Hernandez Jr. wrote:
> I tried with both option and video playback was extremely slow and out of sync
> with the audio. Below is the output I got.

So, even with --hwdec=no mpv decides to fallback to vo=sdl and the end result
is the same. Another thing you might try is use --vo=opengl:sw.

However upstream decided to restore the x11 output, so you'll be able to use it
again in the next release.

Cheers


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#800109: mpv no longer play with --vo x11 option

[Alessandro Ghedini]

On Sat, Sep 26, 2015 at 05:18:01pm -0500, Herminio Hernandez Jr wrote:
> Package: mpv
> Version: 0.11.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I am can no longer play videos on mplayer with the --vo x11 option. I am
> running Sid on PowerPC and the video card I have crashes when I have hardware
> acceleration on, so I need to have it disabled. This was working before I
> performed a system upgrade on my system.

The x11 video output was removed (see /usr/share/doc/mpv/changelog.gz) in the
0.11.0 upstream release.

You might want to either try the sdl video output (--vo=sdl) or disable hw
acceleration with --hwdec=no and let mpv pick an appropriate output.

Let me know if any of that helps.

Cheers


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#795595: libasound2-plugin-equal: change package name to "alsa-equalizer-plugin" or similar and move to sound section

[Alessandro Ghedini]

On Sat, Aug 15, 2015 at 05:00:29PM +0200, Marcel Partap wrote:
> Package: libasound2-plugin-equal
> Version: 0.6-6
> Severity: wishlist
> 
> The main reasons being that
> a) it is a hidden gem that should not hide in the dark (libs section)
> b) it easily gets removed accidently by marking all packages in the libs
> section auto-installed, which f.e. can be used to clean up packages on crufty
> machines.

The name was decided to follow the libasound2-plugins package naming scheme, so
I think that before renaming alsaequal, this should maybe be discussed with the
ALSA maintainers (I added jordi to CC since he has been doing alsa-plugins
uploads, and since the ALSA Maintainers mailing list seems to be mostly spam).

TBH I'm not really sure if following the alsa-plugins naming scheme actually
makes sense, and personally I would be okay with a rename.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#791026: ecasound: library transition may be needed when GCC 5 is the default

[Alessandro Ghedini]

reopen 791026
user release.debian@packages.debian.org
usertag 791026 + transition
block 791026 by 790756
reassign 791026 release.debian.org
kthxbye

On Fri, Jul 03, 2015 at 01:09:43pm +, Matthias Klose wrote:
> Package: src:ecasound
> Version: 2.9.1-5
> Severity: important
> Tags: sid stretch
> User: debian-...@lists.debian.org
> Usertags: libstdc++-cxx11
> 
> Background [1]: libstdc++6 introduces a new ABI to conform to the
> C++11 standard, but keeps the old ABI to not break existing binaries.
> Packages which are built with g++-5 from experimental (not the one
> from testing/unstable) are using the new ABI.  Libraries built from
> this source package export some of the new __cxx11 or B5cxx11 symbols,
> and dropping other symbols.  If these symbols are part of the API of
> the library, then this rebuild with g++-5 will trigger a transition
> for the library.

ecasound needs a transition. I already uploaded the version with the renamed
package to experimental and tested that both reverse build dependencies
(libaudio-ecasound-perl and soundscaperenderer) build fine (soundscaperenderer
is the only reverse dep that would be affected by the symbols renaming).

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#790446: mpv: Warning about mismatch between build and run-time ffmpeg libraries

[Alessandro Ghedini]

Control: tags -1 fixed-upstream

On Mon, Jun 29, 2015 at 06:01:04pm +0200, Guillem Jover wrote:
> Package: mpv
> Version: 0.9.2-1+ffmpeg
> Severity: normal
> 
> Hi!
> 
> [ First of all, thanks for providing a ffmpeg version of the package,
>   there's quite some media that does not play correctly with libav. ]
> 
> The mpv program emits the following warning on startup:
> 
> ,---
> Warning: mpv was compiled against a different version of ffmpeg than the 
> shared
> library it is linked against. This can expose subtle ABI compatibility issues
> and can lead to misbehavior and crashes.
> `---
> 
> Which, to me points out there's a problem somewhere. Either:
> 
>  * the warning is bogus, and
>- mpv should be silenced in common/av_log.c:print_libav_versions, or

Upstream removed the warning now, see [0].

Cheers

[0] 
https://github.com/mpv-player/mpv/commit/5594379b27f3c19a475b83a001a1cd96946c


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#790446: mpv: Warning about mismatch between build and run-time ffmpeg libraries

[Alessandro Ghedini]

Control: forwarded -1 https://github.com/mpv-player/mpv/issues/2110

Sorry for the delay.

On mer, lug 01, 2015 at 10:35:13 +0200, Andreas Cadhalpun wrote:
> Hi Guillem,
> 
> On 30.06.2015 23:14, Andreas Cadhalpun wrote:
> > On 30.06.2015 21:40, Guillem Jover wrote:
> >> Perhaps, but the comment at
> >> 
> >> was not very soothing, so that was one additional reason for the bug. :)
> > 
> > Hmm, this comment is indeed a bit worrisome.
> > But I'm not sure I understand the reasoning given there. As far as I know
> > the accessor functions are only necessary for API that is not present
> > in Libav (in order to be ABI compatible after Libav merges, as the comment
> > says). So whether or not one uses the accessors shouldn't make a difference
> > for compatibility with Libav.
> 
> I've investigated this a bit more and it seems that the only potentially
> problematic FFmpeg-only API used by mpv is AVFrame->metadata, which mpv
> accesses via av_frame_get_metadata. [1]
> Thus I think the comment is just wrong and the warning should be removed.

If I understand the comment correctly, the problem isn't so much ffmpeg-only
APIs like ->metadata, but the fact that mpv doesn't use accessor functions for
struct fields provided by ffmpeg to maintain ABI compatibility because libav
doesn't have those functions (but it still has the structs).

IMO the warning can be removed in the Debian packages because it's fairly
annoying and mostly useless (it's not like Debian users can do anything about
it besides recompiling the package), but maybe we should better investigate
this alleged ABI compatibility problem in ffmpeg.

For example the upstream-tracker thingy shows several ABI changes introduced in
ffmpeg 2.5 (e.g. new fields in the middle of structs) without a SONAME bump:
http://upstream.rosalinux.ru/versions/ffmpeg.html

The mpv Debian package could also start using the accessors that ffmpeg
provides but only when built with ffmpeg (which should hopefully become the
default soonish), but tracking down where these accessors should be used is
probably going to be a bit of a pain.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#788349: mpv: Segmentation fault after upgrade (libnettle6 installation)

[Alessandro Ghedini]

Control: reassign -1 libnettle4
Control: forcemerge 787620 -1

On Wed, Jun 10, 2015 at 03:31:13PM +0200, nfb wrote:
> Package: mpv
> Version: 0.9.2-1
> Severity: important
> 
> Hi,
> after today's upgrade which installed libnettle6 as dependency, i get
> segmentation fault running mpv.
> Here is the gdb output:
> 
> 
> $ gdb mpv
> (gdb) run
> Starting program: /usr/bin/mpv 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb468e580 in nettle_yarrow256_update () from
> /usr/lib/arm-linux-gnueabihf/libnettle.so.6
> (gdb) bt
> #0  0xb468e580 in nettle_yarrow256_update () from
> /usr/lib/arm-linux-gnueabihf/libnettle.so.6
> #1  0xb51bc76c in ?? () from
> /usr/lib/arm-linux-gnueabihf/libgnutls-deb0.so.28
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> 
> 
> May be related to bug #788333:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788333

Yep, same as #787620 as well. It's caused by the fact that libnettle4 doesn't
provide symbols versioning so both libenttle4 and libnettle6 may get loaded at
the same time.

To fix this you should make sure that packages that use nettle are updated, in
particular libgnutls-deb0-28.

Since mpv doesn't depend directly on nettle or gnutls (they are pulled in due
to other packages), there isn't anything I can do about this.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#786576: mpv: --vo=opengl-old:rectangle=1 fails to render OSD

[Alessandro Ghedini]

On sab, mag 23, 2015 at 03:02:17 +0300, Yuriy M. Kaminskiy wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> mpv --vo=opengl-old fails to render OSD (draws empty rectangles instead)
> when sub-option rectangle is 1 (it is set to 1 by default on some
> video-cards [with mesa ATI r200 driver], otherwise can be enabled by
> --vo=opengl-old:rectangle=1).
> OSD rendering assumes GL_TEXTURE_2D was glEnable'd, while with this
> sub-option video rendering glEnable(GL_TEXTURE_RECTANGLE) (which has higher
> priority).
> Attached patch (tested, seems to work) mitigates this by temporarily
> switching texture targets when rendering OSD.
> 
> Notes:
> 1) This bug does not affect testing and upstream (--vo=opengl-old was
> completely removed since mpv-0.8), only jessie is affected;
> 2) --vo=opengl-old is not used by default, however, it was suggested by mpv
> for very old videocards that lacks OpenGL-2.0, and on some of such cards
> rectangle suboption is enabled by default.

Same as the other one, I don't think this issue is serious enough to warrant
a stable update, sorry. Can you use a different vo? (e.g. xv, x11 or sdl).

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#786572: mpv: always dies in assert() on --vo=opengl-old:force-pbo=yes

[Alessandro Ghedini]

On sab, mag 23, 2015 at 02:15:05 +0300, Yuriy M. Kaminskiy wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> $ mpv --vo=opengl-old:force-pbo=yes any-video.avi
> [...]
> AO: [alsa] 48000Hz stereo 2ch float
> VO: [opengl-old] 1280x720 => 1280x720 yuv420p
> mpv: ../ta/ta.c:333: ta_dbg_check_header: Assertion `h->canary ==
> 0xD3ADB3EF' failed.
> $ gdb mpv core
> [...]
> Program terminated with signal SIGABRT, Aborted.
> (gdb) bt
> [...]
> #5  0xb75c6cf8 in ta_dbg_check_header (h=0xaf4f70cc) at ../ta/ta.c:333
> #6  0xb769d59e in ta_dbg_check_header (h=0xaf4f70cc) at ../ta/ta.c:269
> #7  get_header (ptr=0xaf4f70ec) at ../ta/ta.c:77
> #8  ta_free (ptr=0xaf4f70ec) at ../ta/ta.c:255
> #9  0xb768af19 in draw_image (vo=0xb81e2300, mpi=0xb8571730) at
> ../video/out/vo_opengl_old.c:2007
> #10 0xb7683582 in render_frame (vo=) at ../video/out/vo.c:581
> [...]
> 
> When force-pbo enabled, mpi == &mpi2, so it attempts to free variable on
> stack.
> Patch attached (tested, works).
> 
> Notes:
> 1) This bug does not affect testing and upstream (--vo=opengl-old was
> completely removed since mpv-0.8), only jessie is affected;
> 2) It can be only triggered by user with --vo=opengl-old:force-pbo=yes
> option;
> 3) It is expected to always die in assert, before triggering heap
> corruption, so there should be no security implications.

Given the above notes I don't think this issue warrants a stable update (I
don't think the release managers would allow one anyway), so there's not much
I can do about this.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Sat, May 16, 2015 at 03:43:37PM +0200, Alessandro Ghedini wrote:
> On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
> > On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> > > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > > > Version: 6:11.3-1
> > > > 
> > > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > > > Package: libavcodec56
> > > > > Version: 6:11.3-2
> > > > > Severity: grave
> > > > > Tags: security
> > > > > Justification: user security hole
> > > > > 
> > > > > Hi, as far as I can see this has not yet been reported or fixed:
> > > > > 
> > > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c 
> > > > > in
> > > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
> > > > > allow
> > > > > remote attackers to cause a denial of service (use-after-free) or 
> > > > > possibly
> > > > > have unspecified other impact via crafted Vorbis I data [1]
> > > > > 
> > > > > I marked this as grave as the impact is unclear and might include 
> > > > > arbitrary
> > > > > code execution. Feel free do downgrade if this can be ruled out.
> > > > > 
> > > > > (Actually I would like to have a look at the test case to check a bit 
> > > > > more
> > > > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > > > 
> > > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > > > >   
> > > > > https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > > > 
> > > > A similar commit to the one maintained in this mailing list post was 
> > > > applied to
> > > > 11.3. So closing with that version.
> > > 
> > > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
> > > patch at
> > > all, and the commit message doesn't even mention the bug fix. How can you 
> > > be so
> > > sure that the bug is fixed?
> > 
> > I might have read the commit wrong. Do you have a sample for this CVE?
> 
> Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
> it, I'll keep you posted.

I got the reproducer from ffmpeg and it seems that libav in sid isn't affected
like Sebastian said. So yeah, this bug should stay closed. I don't know if the
patch linked above is what fixed the issue though.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On lun, mag 18, 2015 at 01:47:25 +0100, Alessio Treglia wrote:
> Ciao Alessandro,
> 
> and thanks for sharing your thoughts, it's genuinely appreciated.
> 
> On Mon, May 18, 2015 at 1:26 PM, Alessandro Ghedini  wrote:
> > And it's already clear that libav just doesn't provide enough security 
> > coverage,
> 
> Can you please elaborate? AFAICS the versions in oldstable (0.8.17)
> and stable (11.3) are actively maintained upstream.
> Honestly that looks quite enough of security support.

The security tracker lists three vulnerabilities that don't have patches in
libav.git (but are fixed in ffmpeg in sid):
https://security-tracker.debian.org/tracker/source-package/libav

ffmpeg also provides a helpful security page that associates CVE ids with git
commits for easy cherry-picking (libav doesn't do this):
http://ffmpeg.org/security.html

Plus see what Moritz (from the Security team) said about ffmpeg security
responses (Andreas already mentioned this, but I think it's relevant here as
well):

> I think ffmpeg is doing better in terms of handling security issues; when
> I contacted Michael Niedermeyer in private we has always quick to reply,
> while libav-security@ seems understaffed: Several queries in the past needed
> additional poking, some were left unaddressed until today. Also, the Google 
> fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg.

https://lists.debian.org/debian-devel/2014/08/msg00060.html

> > I'm implying that users have been asking for what they need (ffmpeg) for a 
> > long
> > time, and Debian isn't providing it.
> 
> Well, that is an alleged opinion, not fact. Conversely libav backers
> couldn't say that "we are giving the users all what they really really
> want and need".
> So please let's all just refrain from taking this as we're 100% to
> have joined the battle on the right side ;)

Fair enough. I was trying to understand Jonas' point of view but I may have
been carried away at times, sorry about that everyone.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On Mon, May 18, 2015 at 11:15:04AM +0200, Jonas Smedegaard wrote:
> There are multiple ways to handle packages unsuitable for long-term 
> maintenance:
> 
>   * Treat as "experimental" - e.g. mpv

How is mpv unsuitable for long-term maintainance?

>   * Have security team treat as "too unreliable" - e.g. iceweasel

We do provide security support for iceweasel. Where did you get the idea that
we don't?

We don't backport fixes but just provide the latest stable release.

The situation with ffmpeg is completely different though, because ffmpeg
upstream actually documents which patches fix what security issue:
http://ffmpeg.org/security.html

Something that libav upstream doesn't do.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On Sun, May 17, 2015 at 10:53:37PM +0200, Jonas Smedegaard wrote:
> Quoting Alessandro Ghedini (2015-05-17 21:58:15)
> > The issues mentioned in the page were hardly wide ranging. One was 
> > about the fact that libav doesn't implement some video filters, which 
> > forces mpv to carry its own implementations (still true). Another 
> > about about libav HTTP support (most likely fixed but I'm not sure). 
> > The other were all about subtitles.
> > 
> > It's also true that the list wasn't really esaustive before it was 
> > deleted. For example one time I tried to convert a part of a movie 
> > into a GIF with mpv, before realizing that libav's GIF encoder is 
> > completely broken (I actually tried to backport it from ffmpeg, before 
> > giving up and switching to ffmpeg myself), but this wasn't mentioned 
> > in the wiki.
> 
> Oh.  Do I understand you correctly that neither wiki page nor README.md 
> file is really relevant,

How would they not be relevant? They recommend users to use ffmpeg and list
examples of problems they may encounter if they decide to use mpv with libav
(problems that are regularly reported as mpv bugs).

But my point was that they don't list all the problems, so trying to argue
that the problems listed aren't really that relevant is useless because it
doesn't take much to find other ones.

> >> Ok, so exotic subtitle formats is a "particular" reason for mpv authors 
> >> to favor FFmpeg over libav.
> >
> > Where did you get the "exotic" part?
> 
> Sorry that I didn't clarify.  I wanted to avoid the misconception (among 
> those reading along but not themselves using mpv) that _all_ mpv 
> subtitle handling was broken with Libav (it certainly is not), and 
> assumed from my own experience that those missing were less common than 
> the ones supported in both of the libraries.

Ok, that makes sense.

> > I've run into libav's lack of external vobsub files support several 
> > times already. I've also seen broken PGS subtitles decoding in the 
> > wild, even though I'm not really an avid watcher of BluRays.
> 
> > Several people also expressly asked me to provide mpv packages built 
> > against ffmpeg. I suppose they had their own reasons.
> 
> ...and you do build against ffmpeg.  Targeted experimental.  No doubt 
> those wanting it would prefer it being easier accessible than that, but 
> if their reason was "just to be sure to have the most bleeding edge 
> possible" then they'd never use our too boring stable release anyway.

You keep saying "bleeding edge", but is proper support for features that are
documented as being supported but are in practice buggy or unusable considered
bleeding edge? What about users of Debian stable that run into libav bugs?
Should they use experimental too?

> We don't know their reasons, so can only speculate and that speculation 
> can go in any direction, not only towards "ffmpeg is the better choice 
> for Debian."

That goes both ways. You can't assume people want to use ffmpeg just because
"it's bleeding-edge" either (your earlier proposal to have packages built with
ffmpeg in experimental, or that ffmpeg shouldn't receive security support sort
of implies that).

> > It might be true that there is no major issue that makes libav 
> > unusable for everyone,
> 
> I never said that.
> 
> My main concern is long-term maintainability.

(The following is sort of off-topic in respect to the point you were making,
sorry about that, but I'd like to understand your POV).

What does "long-term maintainability" even mean for you? What are the factors
that make something long-term maintanable and something else not in your opinion
and why is libav better in that regard?

As far as Debian stable is concerned the only relevant metric is security
support, simply because pretty much any other change will just be rejected by
the release team (unless it's for some really serious bug). And it's already
clear that libav just doesn't provide enough security coverage, so how can you
justify leaving Debian stable users open to security vulnerabilities and bugs
by keeping libav in stable and not ffmpeg (or by providing security "support"
for libav and not ffmpeg)?

> > but there are a lot of somewhat minor issues that make libav unusable 
> > for many different use-cases (e.g. see Fabian's earlier email). Which 
> > is kinda sad IMO, considering that the needs of our users is supposed 
> > to be one of Debian's main priorities.
> 
> "supposed to be"? - are you somehow implying that you know the needs of 
> our us

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On Sun, May 17, 2015 at 08:43:57PM +0200, Jonas Smedegaard wrote:
> Quoting Alessandro Ghedini (2015-05-17 18:55:14)
> > On Sun, May 17, 2015 at 11:28:47AM +0200, Jonas Smedegaard wrote:
> >> Also, it is apparently not their current position
> >
> > From the README.md file [0]:
> >
> >> Generally, mpv should work with the latest release as well as the git 
> >> version of both FFmpeg and Libav. But FFmpeg is preferred, and some 
> >> mpv features work with FFmpeg only (subtitle formats in particular).
> >
> > So no, the position hasn't really changed, but I don't know why the 
> > wiki page was removed.
> 
> Ah, thanks for that hint: Git commit be6cca78 indicates that the wiki 
> edit was deliberate, and that their position indeed have changed: It has 
> shrunk from a wide range of issues to only concretely mention subtitles.

The issues mentioned in the page were hardly wide ranging. One was about the
fact that libav doesn't implement some video filters, which forces mpv to carry
its own implementations (still true). Another about about libav HTTP support
(most likely fixed but I'm not sure). The other were all about subtitles.

It's also true that the list wasn't really esaustive before it was deleted. For
example one time I tried to convert a part of a movie into a GIF with mpv,
before realizing that libav's GIF encoder is completely broken (I actually
tried to backport it from ffmpeg, before giving up and switching to ffmpeg
myself), but this wasn't mentioned in the wiki.

> Ok, so exotic subtitle formats is a "particular" reason for mpv authors 
> to favor FFmpeg over libav.

Where did you get the "exotic" part?

> I personally use mpv almost daily, with material from many different 
> sources.  I am not a native english speaker so appreciate material with 
> subtitles and sometimes fetch it myself, and would notice material 
> including subtitles but failing to work.  Nevertheless I do not recall 
> subtitles ever failing to work.  No doubt subtitles exist in weird 
> formats somewhere, but my point is that personally I have not needed any 
> of those more exotic subtitle formats.
> 
> How many of you can honestly say that you suffer from inferior subtitle 
> support in mpv in Debian (i.e. the package linked against libav)?

I've run into libav's lack of external vobsub files support several times
already. I've also seen broken PGS subtitles decoding in the wild, even though
I'm not really an avid watcher of BluRays.

Several people also expressly asked me to provide mpv packages built against
ffmpeg. I suppose they had their own reasons.

It might be true that there is no major issue that makes libav unusable for
everyone, but there are a lot of somewhat minor issues that make libav unusable
for many different use-cases (e.g. see Fabian's earlier email). Which is kinda
sad IMO, considering that the needs of our users is supposed to be one of
Debian's main priorities.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On Sun, May 17, 2015 at 11:28:47AM +0200, Jonas Smedegaard wrote:
> Also, it is apparently not their current position

From the README.md file [0]:

> Generally, mpv should work with the latest release as well as the git version
> of both FFmpeg and Libav. But FFmpeg is preferred, and some mpv features work
> with FFmpeg only (subtitle formats in particular).

So no, the position hasn't really changed, but I don't know why the wiki page
was removed.

Cheers

[0] https://github.com/mpv-player/mpv#ffmpeg-vs-libav


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
> On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > > Version: 6:11.3-1
> > > 
> > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > > Package: libavcodec56
> > > > Version: 6:11.3-2
> > > > Severity: grave
> > > > Tags: security
> > > > Justification: user security hole
> > > > 
> > > > Hi, as far as I can see this has not yet been reported or fixed:
> > > > 
> > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
> > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
> > > > remote attackers to cause a denial of service (use-after-free) or 
> > > > possibly
> > > > have unspecified other impact via crafted Vorbis I data [1]
> > > > 
> > > > I marked this as grave as the impact is unclear and might include 
> > > > arbitrary
> > > > code execution. Feel free do downgrade if this can be ruled out.
> > > > 
> > > > (Actually I would like to have a look at the test case to check a bit 
> > > > more
> > > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > > 
> > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > > >   https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > > 
> > > A similar commit to the one maintained in this mailing list post was 
> > > applied to
> > > 11.3. So closing with that version.
> > 
> > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
> > patch at
> > all, and the commit message doesn't even mention the bug fix. How can you 
> > be so
> > sure that the bug is fixed?
> 
> I might have read the commit wrong. Do you have a sample for this CVE?

Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
it, I'll keep you posted.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Moving imlib2 to pkg-multimedia? (help needed)

[Alessandro Ghedini]

Hello,

currently I'm the sole maintainer of the imlib2 package, however I don't have
a lot of free time these days and imlib2 isn't really one of my top priorities.

So I was thinking to move the package under the pkg-multimedia umbrella and
find someone who can help maintaining it.

The package isn't extremely complicated, but there are currently a few bugs
that need investingating and upstream isn't very active.

Comments? Any takers?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> Version: 6:11.3-1
> 
> On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > Package: libavcodec56
> > Version: 6:11.3-2
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> > 
> > Hi, as far as I can see this has not yet been reported or fixed:
> > 
> > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
> > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
> > remote attackers to cause a denial of service (use-after-free) or possibly
> > have unspecified other impact via crafted Vorbis I data [1]
> > 
> > I marked this as grave as the impact is unclear and might include arbitrary
> > code execution. Feel free do downgrade if this can be ruled out.
> > 
> > (Actually I would like to have a look at the test case to check a bit more
> > thoroughly, but AFAICS I would need to talk to google for this.)
> > 
> > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> >   https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> 
> A similar commit to the one maintained in this mailing list post was applied 
> to
> 11.3. So closing with that version.

Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg patch at
all, and the commit message doesn't even mention the bug fix. How can you be so
sure that the bug is fixed?

Cheers

[0] 
https://github.com/libav/libav/commit/0025f7408a0fab2cab4a950064e4784a67463994


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#784267: mpv: please make the build reproducible

[Alessandro Ghedini]

Control: tags -1 pending

On Mon, May 04, 2015 at 07:53:23PM +0200, Jérémy Bobbio wrote:
> Source: mpv
> Version: 0.9.1-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> 
> Hi!
> 
> While working on the “reproducible builds” effort [1], we have noticed
> that foo could not be built reproducibly.
> 
> The attached patch disable recording the build date. Once applied,
> mpv can be built reproducibly in our current experimental framework.

I just merged your patch in the git repo, thanks.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Icecast2 2.4.2 and Ices2 2.0.2 for Debian unstable

[Alessandro Ghedini]

On Wed, Apr 29, 2015 at 12:02:02PM +0200, Alessandro Ghedini wrote:
> On Mon, Apr 27, 2015 at 07:08:41PM -0400, Unit 193 wrote:
> > Howdy,
> > 
> > Please review and sponsor Icecast2 2.4.2 and Ices2 2.0.2 into unstable.  
> > Both 
> > have several bug fixes, and Icecast2 has security fixes as well as a fix to 
> > correctly set passwords prompted for in debconf.
> > 
> > Icecast2: ssh://anonscm.debian.org/git/pkg-multimedia/icecast2.git
> > Ices2: ssh://anonscm.debian.org/git/pkg-multimedia/ices2.git
> > 
> > Changelog for Icecast2:
> > 
> >* Imported Upstream version 2.4.2 (Closes: #779968)
> >  - Set PATH_MAX to 4096 if not defined (Closes: #767542)
> >  - Fix crash with stream_auth (Closes: #782120, fixes: CVE-2015-3026)
> >* Update upstream-tarball hints for new upstream source.
> >* d/copyright, d/copyright_hints: Update for new upstream release.
> >* ACK NMU by Simon Richter, thanks.
> >* Debconf translation: Japanese, victory (Closes: #692970)
> >* Relax debhelper compat level to 8 for easier backporting.
> >* d/rules: Remove extra changelog.
> >* d/icecast2.postinst: Change ed calls to sed. (Closes: #740667)
> >* Update standards version to 3.9.6.
> 
> Uploaded, thanks. I may have time for reviewing the ices2 upload later today,
> but I can't promise anything.

ices2 uploaded as well.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On gio, apr 30, 2015 at 12:05:23 +0200, Alessandro Ghedini wrote:
> On Thu, Apr 30, 2015 at 11:30:08AM +0200, Jonas Smedegaard wrote:
> > Quoting Alessandro Ghedini (2015-04-30 11:19:39)
> > > While the work done by Reinard (and others) maintaining the libav 
> > > package is outstanding and very appreciated, it just seems to make 
> > > more sense to go with ffmpeg. So I vote ffmpeg too.
> > 
> > In what way do you find the work outstanding if essentially unusable?
> > 
> > (not a trick question - I honestly try to understand this)
> 
> Not unusable, it's just that ffmpeg seems to be better (see below).
> 
> Anyway, the libav package is a really complicated one: the upstream project 
> has
> tons of different options and optimizations that need to be handled 
> differently
> on different architectures, the Debian package has many reverse dependencies
> that make testing migrations difficult and time-consuming (it doesn't help 
> that
> libav upstream broke API compatibility so many times), and all bug reports 
> that
> I've either reported or seen have been handled in a responsive and helpful way
> by Reinard.

I've just realized that I've been misspelling his name all this time... sorry.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On Thu, Apr 30, 2015 at 11:30:08AM +0200, Jonas Smedegaard wrote:
> Quoting Alessandro Ghedini (2015-04-30 11:19:39)
> > While the work done by Reinard (and others) maintaining the libav 
> > package is outstanding and very appreciated, it just seems to make 
> > more sense to go with ffmpeg. So I vote ffmpeg too.
> 
> In what way do you find the work outstanding if essentially unusable?
> 
> (not a trick question - I honestly try to understand this)

Not unusable, it's just that ffmpeg seems to be better (see below).

Anyway, the libav package is a really complicated one: the upstream project has
tons of different options and optimizations that need to be handled differently
on different architectures, the Debian package has many reverse dependencies
that make testing migrations difficult and time-consuming (it doesn't help that
libav upstream broke API compatibility so many times), and all bug reports that
I've either reported or seen have been handled in a responsive and helpful way
by Reinard.

However, it seems to me that after the fork the libav project has fallen too far
behind to catch up at this point. It just doesn't have enough manpower. It has a
capable team of core developers but pretty much all other contributors send
their patches to ffmpeg only. All bugs that I reported to libav were in a way or
another already fixed in ffmpeg, and the few times I tried to backport features
and fixes to libav always ended up requiring a lot of time for the simple fact
that the two projects have diverged so much.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On Wed, Apr 29, 2015 at 11:48:23PM +0200, Bálint Réczey wrote:
> 2015-04-29 20:56 GMT+02:00 Alessio Treglia :
> > 'Evening Ladies and Gentlemen,
> >
> > I am afraid that I have to revive this discussion once again now that
> > Jessie is out as we have plenty of time before starting doing any
> > major work for Stretch: it's really the right time to make a final
> > decision about this subject.
> > The need to get this dichotomy solved may be found in Moritz's last email:
> >
> > On Wed, Apr 29, 2015 at 7:22 PM, Moritz Mühlenhoff  wrote:
> >> To properly migrate over a daemon they need to co-exist for a stable
> >> release, while a lib does not. Stretch will only have one of them.
> >
> > [snip]
> >
> >> Having both for a year along each other will only waste people's time. Now
> >> at the beginning of the release cycle is the time to make a decision,
> >> not by dragging things into a year as of today. Picking one of the two
> >> won't be any simpler in 12 months.
> >
> > It appears clear to me that the security team wouldn't be too happy to
> > support both FFmpeg and libav:
> > Therefore the question still remains:
> >
> > On Tue, Aug 26, 2014 at 11:36 PM, Benjamin Drung  wrote:
> >> So I am asking you: Should we ship libav or FFmpeg? Can we reach a
> >> consensus on this topic?
> According to my observations FFmpeg has better security support,
> accepts enhancement requests faster and is strongly preferred by
> XBMC/Kodi upstream thus I vote for FFmpeg as being the one library we
> ship if we can ship only one.

ffmpeg is also more feature-complete and has, in my experience, less bugs (not
just security ones). It's also recommended by mpv upstream.

While the work done by Reinard (and others) maintaining the libav package is
outstanding and very appreciated, it just seems to make more sense to go with
ffmpeg. So I vote ffmpeg too.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Alessandro Ghedini]

On Thu, Apr 30, 2015 at 11:01:20AM +0200, IOhannes m zmölnig (Debian/GNU) wrote:
> On 2015-04-29 23:48, Bálint Réczey wrote:
> > I disagree with the question and I in my eyes both of the
> > libraries should be allowed to enter testing. That would be fair
> > handling of maintainers' and upstreams' work.
> 
> /me would vote for inclusion of both as well (if possible at all).

That is not an option.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Icecast2 2.4.2 and Ices2 2.0.2 for Debian unstable

[Alessandro Ghedini]

On Mon, Apr 27, 2015 at 07:08:41PM -0400, Unit 193 wrote:
> Howdy,
> 
> Please review and sponsor Icecast2 2.4.2 and Ices2 2.0.2 into unstable.  Both 
> have several bug fixes, and Icecast2 has security fixes as well as a fix to 
> correctly set passwords prompted for in debconf.
> 
> Icecast2: ssh://anonscm.debian.org/git/pkg-multimedia/icecast2.git
> Ices2: ssh://anonscm.debian.org/git/pkg-multimedia/ices2.git
> 
> Changelog for Icecast2:
> 
>* Imported Upstream version 2.4.2 (Closes: #779968)
>  - Set PATH_MAX to 4096 if not defined (Closes: #767542)
>  - Fix crash with stream_auth (Closes: #782120, fixes: CVE-2015-3026)
>* Update upstream-tarball hints for new upstream source.
>* d/copyright, d/copyright_hints: Update for new upstream release.
>* ACK NMU by Simon Richter, thanks.
>* Debconf translation: Japanese, victory (Closes: #692970)
>* Relax debhelper compat level to 8 for easier backporting.
>* d/rules: Remove extra changelog.
>* d/icecast2.postinst: Change ed calls to sed. (Closes: #740667)
>* Update standards version to 3.9.6.

Uploaded, thanks. I may have time for reviewing the ices2 upload later today,
but I can't promise anything.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Icecast2 2.4.2 and Ices2 2.0.2 for Debian unstable

[Alessandro Ghedini]

On Mon, Apr 27, 2015 at 07:08:41PM -0400, Unit 193 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Howdy,

Hi,

> Please review and sponsor Icecast2 2.4.2 and Ices2 2.0.2 into unstable.
> Both have several bug fixes, and Icecast2 has security fixes as well as a
> fix to correctly set passwords prompted for in debconf.
> 
> Icecast2: ssh://anonscm.debian.org/git/pkg-multimedia/icecast2.git
> Ices2: ssh://anonscm.debian.org/git/pkg-multimedia/ices2.git
> 
> Changelog for Icecast2:
> 
>   * Imported Upstream version 2.4.2 (Closes: #779968)
> - Set PATH_MAX to 4096 if not defined (Closes: #767542)
> - Fix crash with stream_auth (Closes: #782120, fixes: CVE-2015-3026)

Would it be possible for you to prepare an upload for jessie-security fixing
this as well? The patch fixing the vulnerability is [0]. If you decide to do
this please have a look at [1] and once you are done send a debdiff to
t...@security.debian.org.

I'll have a look at the icecast2 update later, if no one beats me to it.

Cheers

[0] 
https://trac.xiph.org/changeset/27abfbbd688df3e3077b535997330aa06603250f/icecast-server
[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-building


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#783258: flac: FTBFS due to missing symbols

[Alessandro Ghedini]

On sab, apr 25, 2015 at 02:16:52 +0200, Fabian Greffrath wrote:
> Control: tags -1 + help
> 
> Hi Sebastian,
> 
> Am Freitag, den 24.04.2015, 21:27 +0200 schrieb Sebastian Ramacher: 
> > | - _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0
> > | + _ZN4FLAC7Decoder4File13read_callbackEPhPj@Base 1.3.1-1
> > | +#MISSING: 1.3.1-1# _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0
> 
> WTF is wrong with C++ symbols files? The symbols are all there, they
> differ just in name by their last character.

C++ symbols get mangled to arch-specific names. To make the *.symbols file work
you need to use the "c++" symbols pattern with the demangled C++ symbol names.

E.g. instead of:

  _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0

use:

  (c++)"FLAC::Decoder::File::read_callback(unsigned char*, unsigned 
long*)@Base" 1.3.0

The demangling can be done using c++filt as follows (not sure if there's an
automatic way to convert a whole symbols file):

  % echo "_ZN4FLAC7Decoder4File13read_callbackEPhPm@Base" | c++filt
  FLAC::Decoder::File::read_callback(unsigned char*, unsigned long*)@Base

Alternatively you could use the "regex" symbols pattern, but I don't think it's
the recommended way.

See dpkg-gensymbols(1) for more info.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#779789: mpv: free(): invalid pointer: 0xedf28020 ***

[Alessandro Ghedini]

On Tue, Mar 17, 2015 at 02:47:13PM +0100, Alessandro Ghedini wrote:
> Control: forwarded -1 https://github.com/mpv-player/mpv/issues/1698
> 
> On Fri, Mar 06, 2015 at 09:13:13PM +0100, Jakub Wilk wrote:
> > Control: found -1 0.8.2-1+ffmpeg
> > 
> > * Alessandro Ghedini , 2015-03-06, 20:49:
> > >>Could you try with these options?
> > >>
> > >>-vo=xv -vf=expand=1440/900
> > >>
> > >>Apparently they are needed to trigger the crash. I forgot I had them in
> > >>my mpv.conf.
> > >
> > >Still can't reproduce. You can try using the --no-config option to make
> > >sure configuration files don't interfere. Also, the output of playing the
> > >file with the --msg-level=all=trace option could be useful as well.
> > 
> > Please see the attachment.
> > 
> > As promised, I tried mpv_0.8.2-1+ffmpeg, and it also crashes.
> 
> Sorry for the delay.
> 
> I have forwarded the issue upstream now. It'd be nice if you could answer any
> possible follow-up questions directly at [0] (none at the moment).

Upstream has committed a patch [0] that may or may not fix the issue (he can't
reproduce either). Would it be possible for you to test it (e.g. by adding the
patch to the Debian source package)? If that doesn't work, could you also try to
build the git master [1] and see if the problem is still there?

Cheers

[0] 
https://github.com/mpv-player/mpv/commit/6b53897d75c3b57d018ca3faa34d732acae86b79
[1] https://github.com/mpv-player/mpv


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#779789: mpv: free(): invalid pointer: 0xedf28020 ***

[Alessandro Ghedini]

Control: forwarded -1 https://github.com/mpv-player/mpv/issues/1698

On Fri, Mar 06, 2015 at 09:13:13PM +0100, Jakub Wilk wrote:
> Control: found -1 0.8.2-1+ffmpeg
> 
> * Alessandro Ghedini , 2015-03-06, 20:49:
> >>Could you try with these options?
> >>
> >>-vo=xv -vf=expand=1440/900
> >>
> >>Apparently they are needed to trigger the crash. I forgot I had them in
> >>my mpv.conf.
> >
> >Still can't reproduce. You can try using the --no-config option to make
> >sure configuration files don't interfere. Also, the output of playing the
> >file with the --msg-level=all=trace option could be useful as well.
> 
> Please see the attachment.
> 
> As promised, I tried mpv_0.8.2-1+ffmpeg, and it also crashes.

Sorry for the delay.

I have forwarded the issue upstream now. It'd be nice if you could answer any
possible follow-up questions directly at [0] (none at the moment).

Cheers

[0] https://github.com/mpv-player/mpv/issues/1698


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#779789: mpv: free(): invalid pointer: 0xedf28020 ***

[Alessandro Ghedini]

On ven, mar 06, 2015 at 03:46:12 +0100, Jakub Wilk wrote:
> * Alessandro Ghedini , 2015-03-06, 15:05:
> >>$ mpv crash.mp4
> >>Playing: crash.mp4
> >>[libav/video] h264: AVC: nal size 889
> >>[libav/video] h264: no frame!
> >>[libav/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, offset 0x8c69: partial 
> >>file
> >>(+) Video --vid=1 (*) (h264)
> >>File tags:
> >>Title: 860240514032667
> >>Opening video filter: [expand aspect=1440/900]
> >>[expand] Expand: -1 x -1, -1 ; -1, aspect: 1.60, round: 1
> >>[libav/video] h264: AVC: nal size 889
> >>[libav/video] h264: AVC: nal size 889
> >>[libav/video] h264: no frame!
> >>VO: [xv] 3642x720 => 3642x2276 yuv420p
> >>V: 00:00:00 / 00:00:15 (0%)
> >>
> >>
> >>Exiting... (End of file)
> >>*** Error in `mpv': free(): invalid pointer: 0xedf28020 ***
> >>Aborted
> >
> >I can't reproduce.
> 
> Could you try with these options?
> 
> -vo=xv -vf=expand=1440/900
> 
> Apparently they are needed to trigger the crash. I forgot I had them in my
> mpv.conf.

Still can't reproduce. You can try using the --no-config option to make sure
configuration files don't interfere. Also, the output of playing the file with
the --msg-level=all=trace option could be useful as well.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#779789: mpv: free(): invalid pointer: 0xedf28020 ***

[Alessandro Ghedini]

On mer, mar 04, 2015 at 08:12:49 +0100, Jakub Wilk wrote:
> Package: mpv
> Version: 0.8.2-1
> 
> mpv crashes on the attached file:
> 
> $ mpv crash.mp4
> Playing: crash.mp4
> [libav/video] h264: AVC: nal size 889
> [libav/video] h264: no frame!
> [libav/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 0, offset 0x8c69: partial file
> (+) Video --vid=1 (*) (h264)
> File tags:
> Title: 860240514032667
> Opening video filter: [expand aspect=1440/900]
> [expand] Expand: -1 x -1, -1 ; -1, aspect: 1.60, round: 1
> [libav/video] h264: AVC: nal size 889
> [libav/video] h264: AVC: nal size 889
> [libav/video] h264: no frame!
> VO: [xv] 3642x720 => 3642x2276 yuv420p
> V: 00:00:00 / 00:00:15 (0%)
> 
> 
> Exiting... (End of file)
> *** Error in `mpv': free(): invalid pointer: 0xedf28020 ***
> Aborted

I can't reproduce. Could you please also provide a backtrace (with both mpv and
libav debug symbols)? It would also be nice if you could test the package in
experimental that uses ffmpeg instead of libav.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#778356: Subtitles unreadable in 0.7.3

[Alessandro Ghedini]

On sab, feb 14, 2015 at 12:33:55 +0100, Juliusz Chroboczek wrote:
> Package: mpv
> Version: 0.7.3-1
> 
> In both 0.7.3-1 and 0.7.3-1ffmpeg, SRT subtitles appear as opaque white
> squares, one per character.  The same video shows the subtitles just fine
> with 0.6.2-2.
> 
> This is a netbook using the N450 integrated GPU (GMA 3150, I believe),
> with the X.Org Intel driver version 2.3.3 and kernel 3.16.0-4-amd64.

Does this happen with all files or just some specific ones? If the latter, could
you please send one of them too? Also, please provide the output of "mpv -vvv"
when playing one of those files.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#774216: mpv: uses lots of RAM

[Alessandro Ghedini]

On mar, dic 30, 2014 at 01:32:22 +0100, Kurt Roeckx wrote:
> Package: mpv
> Version: 0.6.2-2
> 
> Hi,
> 
> When using mpv to play a movie after an hour it has several GB of
> RAM in use.  When I then quiet it seems to clean up part at least
> a part of it.  I see that it goes in D state to swap things back
> in as it reduces the memory usage.  So I think it or one of it's
> libraries is holding on to something that it might not need
> anymore.

I think this is related to #770930 (a libav bug). Could you try using the mpv
version in experimental built against ffmpeg and see if the problem is still
there?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#773680: mpv: wrong version number in --version

[Alessandro Ghedini]

On lun, dic 22, 2014 at 12:42:04 +0100, Ayke van Laethem wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> MPV will give the wrong version number when running without arguments, or when
> running mpv --version.

Looks good here:

  $ mpv --version
  mpv 0.6.2 (C) 2000-2014 mpv/MPlayer/mplayer2 projects
   built on 2014-10-25T13:21:01
  libav library versions:
 libavutil   54.3.0
 libavcodec  56.1.0
 libavformat 56.1.0
 libswscale  3.0.0
 libavfilter 5.0.0
 libavresample   2.1.0

> Example:
> 
> ~$ mpv --version
> mpv 0.5.0-git-88f247c (C) 2000-2014 mpv/MPlayer/mplayer2 projects
>  built on 2014-08-15T12:38:45

This is not the Debian package... on 2014-08-15 0.6.2 wasn't even released yet
and the 88f247cf git commit is the one that created the 0.5.0 release. Also, the
Debian package isn't built directly from git so it doesn't get the -git-xxx
suffix in the version number.

Maybe the mpv executable you are using isn't the one from the Debian package
(e.g. if you rebuilt mpv from the upstream git repository and changed $PATH to
point to it, then forgot about it). What does the "which mpv" command say?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#773234: Joystick does not work

[Alessandro Ghedini]

Control: severity -1 wishlist
Control: forcemerge -1 773219
Control: tags -1 pending

On lun, dic 15, 2014 at 08:51:13 +, Kristoffer Brånemyr wrote:
> Package: mpv
> Version: 0.7.1-1
> 
> Using the joystick to perform various actions will not work, even when 
> starting mpv with --input-joystick=yes. I think the package has not been 
> built with joystick support. I have built mpv myself from source, 
> enabling joystick when configuring it, and then it will work.
> 
> So it would be nice if you could enable the joystick support when you build 
> it in the future!

Ok, I'll enable it in the next upload.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#772615: mpv: incorrect aspect ratio

[Alessandro Ghedini]

On mar, dic 09, 2014 at 01:25:16 +0530, Ritesh Raj Sarraf wrote:
> Package: mpv
> Version: 0.7.1-1+ffmpeg
> Severity: important
> 
> With this new release, the aspect raito of the video is completely
> broken. I have verified the same video with mplayer and it renders
> correct.

What's the expected behaviour, and what do you actually get (i.e. define
"broken")? Can you post the mpv output with "-v -v -v" and possibly upload a
sample of the affected video somewhere? Also, does 0.7.1-1 (from unstable) work
for you?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#772472: mpv: Doesn't properly stream from YouTube URLs

[Alessandro Ghedini]

On dom, dic 07, 2014 at 09:32:12 -0600, David McMackins wrote:
> Package: mpv
> Version: 0.7.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> When passing a YouTube URL to mpv, I get a TLS error:
> 
> [libav] tls: The TLS connection was non-properly terminated.
> Failed to recognize file format.

Try passing --ytdl on the command-line or setting ytdl=yes in your configuration
file. The built-in youtube-dl-based Lua script is not enabled by default in the
0.7.x series because it has some problems, but it will probably be enabled in
0.8.x so the ytdl=yes workaround is only temporary.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#770930: mpv memory leak

[Alessandro Ghedini]

Control: affects -1 mpv
Control: tags -1 fixed-upstream

On mar, nov 25, 2014 at 11:12:17 +0100, Moritz Fiedler wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: important
> 
> Hello,
> 
> when you use mpv with bigger files it happens that mpv consumes all RAM and
> swap and the system gets unusable.
> 
> The mpv team investigated the issue:
> 
> https://github.com/mpv-player/mpv/issues/1204
> 
> It looks like there is a problem with libav. But there is a patch.

The patch has now been merged in libav upstream [0].

Cheers

[0] 
http://git.libav.org/?p=libav.git;a=commit;h=fbd6c97f9ca858140df16dd07200ea0d4bdc1a83


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#770930: mpv memory leak

[Alessandro Ghedini]

Control: reassign -1 libavutil54
Control: retitle -1 libavutil54: lavu memory leak
Control: forwarded -1 
http://lists.libav.org/pipermail/libav-devel/2014-November/064747.html

On mar, nov 25, 2014 at 11:12:17 +0100, Moritz Fiedler wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: important
> 
> Hello,
> 
> when you use mpv with bigger files it happens that mpv consumes all RAM and
> swap and the system gets unusable.
> 
> The mpv team investigated the issue:
> 
> https://github.com/mpv-player/mpv/issues/1204
> 
> It looks like there is a problem with libav. But there is a patch.
> 
> I think there are two solutions:
> 
>  * compile with ffmpeg

There is an mpv package compiled against ffmpeg in experimental (the version is
0.6.2-2+ffmpeg). You may want to try that, however it's not possible to have it
in unstable (and thus testing) yet.

>  * patch libav

Unfortunately the patch doesn't seem to be merged upstream yet so this may take
a while.

> I filed the bug here, because i only experience the problem with mpv.

Still, it's a libav bug, hence reassigning.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#769564: mpv: Segfault when playing in fullscreen

[Alessandro Ghedini]

Control: reassign -1 libgl1-mesa-dri
Control: forcemerge 762809 -1
Control: affects 762809 mpv

On ven, nov 14, 2014 at 08:40:48 -0600, David McMackins wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Steps to reproduce:
> 
> - Play a webm video file with mpv, no other arguments (not sure if format
>   is relevant)
> - Strike F to enter fullscreen mode
> - Wait 2-10 seconds
> - mpv will crash
> 
> For me, it caused gnome-shell to refresh, and reported a segfault. Log:
> 
> $ mpv /media/david/TOSHIBA\ EXT/vid/TED/TEDxGE2014_Stallman05_HQ.ogg
> Playing: /media/david/TOSHIBA EXT/vid/TED/TEDxGE2014_Stallman05_HQ.ogg
> [libav/video] theora: 7 bits left in packet 82
> [stream] Video (+) --vid=1 (theora)
> [stream] Audio (+) --aid=1 (vorbis)
> [libav/video] theora: 7 bits left in packet 82
> AO: [pulse] 48000Hz stereo 2ch float
> VO: [opengl] 1920x1088 => 1920x1088 yuv420p
> Failed to open BO for returned DRI2 buffer (1920x1080, dri2 back buffer,
> named 11).
> This is likely a bug in the X Server that will lead to a crash soon.
> Segmentation fault

This looks like a video driver bug, see https://bugs.debian.org/762809. There's
also a workaround at https://bugs.freedesktop.org/show_bug.cgi?id=84372 (scroll
to the bottom).

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#766725: mpv: Can't play audio CDs with cdda://: Either "No stream found to handle url" or "Error parsing option cdrom-device (option not found)"

[Alessandro Ghedini]

On sab, ott 25, 2014 at 02:35:22 +0200, Axel Beckert wrote:
> Hi,
> 
> Alessandro Ghedini wrote:
> > Yeah, native cdda support (via libcdio) was disabled, but you can still 
> > play CDs
> > by using libavdevice. Something like:
> > 
> > mpv av://libcdio:/dev/cdrom
> 
> Doesn't work for me:
> 
> → mpv av://libcdio:/dev/cdrom
> Playing: av://libcdio:/dev/cdrom
> [stream] Audio (+) --aid=1 (pcm_s16le)
> Error initializing audio.
> : 00:00:00 / 00:54:23 (0%)
> 
> And then it hangs until I exit mpv.

Well, I guess libavdevice's libcdio support is inferior to mplayer/mpv's... the
whole cdda:// support implemented via libavdevice won't work either then.

> > Anyway, I'll probably re-enable the native cdda support for the time
> > being.
> 
> That'd be nice, thanks!

Done. I hope this fixes the problem and that it'll make it into jessie in time.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#766725: mpv: Can't play audio CDs with cdda://: Either "No stream found to handle url" or "Error parsing option cdrom-device (option not found)"

[Alessandro Ghedini]

On sab, ott 25, 2014 at 12:15:33 +0200, Axel Beckert wrote:
> Package: mpv
> Version: 0.6.2-1
> Control: found -1 0.6.2-1+ffmpeg
> 
> Dear Debian Multimedia Maintainers,
> 
> I've tried to play an audio CD with mpv.
> 
> From the man page mpv(1):
> 
>cdda://track[-endtrack][:speed][/device] --cdrom-device=PATH --cdda-...
>   Play CD.
> 
>[…]
> 
>--cdrom-device=
>   Specify the CD-ROM device (default: /dev/cdrom).

Yeah, native cdda support (via libcdio) was disabled, but you can still play CDs
by using libavdevice. Something like:

mpv av://libcdio:/dev/cdrom

However this is not very user-friendly I guess, and it'd be nice if mpv
automaticcaly translated all the cdda:// URLs and --cdrom-device/--cdda-*
options to libavdevice automatically, so I opened [0] upstream.

> Then I tried
> 
> → mpv --cdrom-device=/dev/cdrom cdda://
> Error parsing option cdrom-device (option not found)
> Setting commandline option --cdrom-device=/dev/cdrom failed.
> 
> Exiting... (Fatal error)

That's actually normal because --cdrom-device is only available when cdda
support is enabled.

Anyway, I'll probably re-enable the native cdda support for the time being.

Cheers

[0] https://github.com/mpv-player/mpv/pull/1214


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bits from the Debian Multimedia Team [RELOADED]

[Alessandro Ghedini]

On sab, ott 18, 2014 at 04:40:12 +0100, Alessio Treglia wrote:
> The draft is ready:
> 
>https://wiki.debian.org/DebianMultimedia/BitsFrom

After a quick read, it looks good to me. I fixed a couple of typos in the
mplayer removal section (see [0]).

Cheers

[0] 
https://wiki.debian.org/DebianMultimedia/BitsFrom?action=diff&rev2=138&rev1=137


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bits from the Debian Multimedia Team [RELOADED]

[Alessandro Ghedini]

On dom, ott 12, 2014 at 02:18:42 -0400, Reinhard Tartler wrote:
> On Sun, Oct 12, 2014 at 11:47 AM, Alessio Treglia  wrote:
> > On Sat, Oct 11, 2014 at 9:49 PM, Reinhard Tartler  
> > wrote:
> >> FWIW, I personally think we should not mention any of "lame",
> >> "xvidcore", "x264" or "mplayer2". All of these packages are already in
> >> stable, so the text as current is not exactly news.
> >
> > Sounds absolutely sensible.
> 
> Dropped in Revision 131. Feel free to revert if you disagree.

I removed mplayer2 as well. The note about mencoder is also present below where
the removal of mplayer is mentioned.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#764419: mpv: vo=x11 broken on 0.6.0

[Alessandro Ghedini]

Control: tags -1 fixed-upstream

On Tue, Oct 07, 2014 at 11:47:08PM +0200, Trecourt Nicolas wrote:
> Package: mpv
> Version: 0.6.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I recently hit a bug with the X11 video output driver on mpv 0.6.0.
> 
> $ mpv test.mp4 -vo x11
> Playing: test.mp4
> [stream] Video (+) --vid=1 (*) (h264)
> [stream] Audio (+) --aid=1 --alang=und (*) (aac)
> File tags:
>  major_brand: mp42
>  minor_version: 0
>  compatible_brands: isommp42
>  creation_time: 2014-05-07 14:05:44
> AO: [pulse] 44100Hz stereo 2ch float
> VO: [x11] 1280x720 => 1280x720 yuv420p
> [libav] swscaler: 1280x720 -> 1x1 is invalid scaling dimension
> Could not initialize video chain.
> [vo/x11] Shared memory error,disabling ( seg id error )
> [vo/x11] Shared memory error,disabling ( seg id error )
> [libav] swscaler: Value 0.00 for parameter 'dstw' out of range
> [libav] swscaler: Value 0.00 for parameter 'dsth' out of range
> 
> In practice, the window is created, than immediately destroyed, and no
> video is played.

Does this happen with all files? If no, can you please upload your test file
somewhere? This is mostly so I can verify that the bug has been fixed before
uploading a new version.

> The following upstream commit seems to fix the bug:
> https://github.com/mpv-player/mpv/commit/64fb37c173e0ecee0e62d78b96c03d609845e8a4

This commit will be part of the 0.6.1 release which will be released tomorrow at
the latest.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bits from the Debian Multimedia Team [RELOADED]

[Alessandro Ghedini]

On Fri, Oct 10, 2014 at 07:01:09PM +0100, Alessio Treglia wrote:
> Folks,
> 
> If you want to add some last bits, please do it by tomorrow morning,

I updated the mplayer2 section and added mplayer to the dropped section (I also
slightly edited the mpv description). They all probably need some proof-reading
though.

Also, I noticed that a lot of the changes mentioned are mostly relevant to
wheezy (e.g. lame, x264, libav, xvidcore, ...), so maybe the fact that the
changes presented are not only relevant to jessie should be mentioned (the first
paragraph kinda does this, but IMO it's not very clear).

Also^2, the libav section IMO should be more about what version are we going to
release and what new changes it brings since wheezy. This can be compiled from
libav release notes [0] [1] [2], though I'll leave that to the libav maintainer
judgment. The fact that we switched from ffmpeg is, I think, pretty clear to
everyone already.

> I'd intend to mail it in the early afternoon.

Will you send a draft to this list before that?

Cheers

[0] http://libav.org/releases/libav-9.17.release
[1] http://libav.org/releases/libav-10.5.release
[2] http://libav.org/releases/libav-11.release


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#763736: Consider adding mpv-ffmpeg using ffmpeg instead of libav

[Alessandro Ghedini]

On gio, ott 02, 2014 at 11:13:04 +0200, Milan Straka wrote:
> Package: mpv
> Version: 0.6.0-1
> Severity: wishlist
> 
> Now that ffmpeg is in experimental (via #729203), would you consider
> creating a mpv-ffmpeg package, which would be identical to mpv, but
> instead of linking libav would link ffmpeg?

That's not going to happen, however, I was thinking about uploading the mpv
package (the normal mpv package), built against ffmpeg in experimental only, so
we'd have the usual libav mpv in sid/testing/stable and the ffmpeg one in
experimental.

Would that be useful to you as well?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#763904: mpv: stereo3d video filter is broken

[Alessandro Ghedini]

Control: forwarded -1 https://github.com/mpv-player/mpv/pull/1146
Control: tags -1 fixed-upstream

On ven, ott 03, 2014 at 06:37:03 +0200, Sebastian Reichel wrote:
> Package: mpv
> Version: 0.6.0-1
> Severity: normal
> 
> Hi,
> 
> I currently have no time to debug this further, but the 3D video filter
> support is broken. mpv 0.6 is the first release, which automatically
> inserts the video filter based on tags in the video file [0].
> 
> You can test for the issue using the following commands:
> 
> Test Call for mpv 0.5.4 (video filter must be inserted manually):
> mpv -vo x11 --vf stereo3d=sbs2l:ml "http://elektranox.org/test.mk3d";
> 
> Test Call for mpv 0.6 (broken video filter is inserted automatically):
> mpv "http://elektranox.org/test.mk3d";
> 
> I can also see the issue when building mpv master from source, but it
> worked directly after upstream bug #1045 has been marked as resolved by
> me, so it's probably an upstream regression.
> 
> [0] https://github.com/mpv-player/mpv/issues/1045

It should be fixed upstream now, and the fix will be in the next stable release
in a few days.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bits from the Debian Multimedia Team [RELOADED]

[Alessandro Ghedini]

On Fri, Oct 03, 2014 at 08:54:30PM +0100, Alessio Treglia wrote:
> Bump.
> 
> I know that it's a quite boring thing to do but IMHO we'd do a great
> service to all our users by releasing an update on what they'll find on
> Jessie.
> 
> I'll try to allocate some time tomorrow to do my bits (LV2, various libs
> and programs), I would also love to see updates on:
> 
> - Jack (Adrian?)
> - Libav (Reinhard?)
> - XBMC (Balínt?)
> - MPV (Alessandro?)
> - Mediatomb (Hector?)
> - VLC (Benjamin?)
> - Handbrake (Sebastian?)
> 
> Jonas, Jaromír, Matteo, Stuart et al : anything to declare? :)

It may also be worth mentioning that MPlayer has been dropped, and that mplayer2
is essentially dead upstream.

Anyway, I filled the mpv section with some info now.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bits from the Debian Multimedia Team [RELOADED]

[Alessandro Ghedini]

On ven, ott 03, 2014 at 08:54:30 +0100, Alessio Treglia wrote:
> Bump.
> 
> I know that it's a quite boring thing to do but IMHO we'd do a great
> service to all our users by releasing an update on what they'll find on
> Jessie.
> 
> I'll try to allocate some time tomorrow to do my bits (LV2, various libs
> and programs), I would also love to see updates on:
> 
> - Jack (Adrian?)
> - Libav (Reinhard?)
> - XBMC (Balínt?)
> - MPV (Alessandro?)

Not sure what kind of information would be useful here. mpv v0.6.0 has just been
released and that's pretty much what will get in jessie (there are going to be
a couple of bugfix releases before the freeze though).

The mpv package description has a short list of changes from mplayer2, but I
haven't touched it in a while so it may be a little outdated. If needed I can
prepare a better list of improvements vs mplayer/mplayer2.

Also, worth mentioning maybe is that a) mpv's command-line options are not
compatible with the mplayer ones and that b) since mpv dropped some old mplayer
code in favor of libav/ffmpeg features, there may be some incompatibilities
there as well (also, considering that Debian uses libav instead of ffmpeg, some
mpv features work better with ffmpeg or don't work at all with libav).

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#763484: mpv: Please change build dependency to libjpeg-dev (libjpeg-turbo transition)

[Alessandro Ghedini]

Control: tags -1 pending

On Tue, Sep 30, 2014 at 03:06:25PM +0200, Ondřej Surý wrote:
> Source: mpv
> Version: 0.5.4-1
> Severity: important
> Tags: patch
> User: ond...@debian.org
> Usertags: libjpeg-turbo-transition
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear maintainer(s),
> 
> Debian is transitioning from IJG JPEG library (src:libjpeg8) to
> libjpeg-turbo implementation (src:libjpeg-turbo)[1] of libjpeg62 API
> with "decode from memory buffer" interface (jpeg_mem_{src,dest}).

I have committed the change in the git repository. I'll do an upload in the next
few days for a new upstream release, so this will be included as well (i.e. no
need to NMU).

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#763173: mpv: Please add video/ogg as supported mime type for Ogg Theora

[Alessandro Ghedini]

Control: forwarded -1 https://github.com/mpv-player/mpv/pull/1132

On Sun, Sep 28, 2014 at 02:25:15PM +0200, Petter Reinholdtsen wrote:
> 
> Package: mpv
> Version: 0.5.3-1
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: debian-edu
> 
> Please add video/ogg to the mpv desktop file, to indicate that mpv can
> play Ogg Theora files.
> 
> This is the use case: I record a screen session using
> gtk-recordmydesktop, and when I stop the recording it store the video as
> Ogg Theora and I end up with a file out.ogv in my home directory.  I
> next visit the KDE file manager, and click on the video to play the
> recording.  The audacity program is started, and it fail to display
> anything and just hang.  I believe the same problem happen with other
> file managers too, but have not checked them all.  The audacity hang of
> course is an error in itself, but the real error here is that the wrong
> program is started.  For Ogg Theora files, it would be better if mpv or
> another installed video player is started.  The audio tools are not fit
> for the task!
> 
> For this to work, the "file --mime-type out.ogv" program should not
> return "application/ogg" but a video related MIME type like "video/ogg",
> and all video players capable of playing Ogg Theora files should list
> that MIME type in their .desktop file.  I've asked for file to change
> behavour (bug #762561), and now ask the video players to change their
> list of MIME types handled and add "video/ogg".  Please add it before
> Jessie to make this happen. :)

Sounds good. I sent a patch upstream.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#754510: mpv: segfaults on too short tracks

[Alessandro Ghedini]

On Sun, Jul 13, 2014 at 08:52:22PM +0200, arne anka wrote:
> On Sun, 13 Jul 2014 16:35:10 +0200, Alessandro Ghedini 
> wrote:
> 
> >On Fri, Jul 11, 2014 at 11:37:39PM +0200, arne anka wrote:
> >>Package: mpv
> >>Version: 1:0.4.1-dmo1
> >
> >Could you please stop filing bugs for versions that are not in Debian? It
> >happened in the past that bugs filed for versions of packages from
> >deb-multimedia were not present in the official Debian packages.
> 
> dpkg -s mpv
> 
> ...
> Maintainer: Christian Marillat 
> Bugs: mailto:maril...@deb-multimedia.org
> ...
> 
> i am still under the impression, that these tags designate the receiver of
> bug reports -- if that is wrong, there's obviously a bug in reportbug --

I don't know about that. This "Bugs" header is certainly not documented in the
Debian Policy. I don't know who invented it, or if the reportbug developers are
aware of it though.

[0] 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles

> and nevertheless it certainly wouldn't hurt to make your issue clear in a less
> offensive way.
> you did not yet say anything about that, unless i am supposed to read that
> from "uhmm"!

If you refer to my message in #753265, yes, I realize that was rather enigmatic
(and I didn't intend to offend anyone either), in fact I let it "slip" without
explaining it any further because I could actually reproduce what was reported,
so it wasn't really that important.

That was not the case with this report, and that's why I expanded on that part
in my response in this case, in a way that, again, was certainly not intended to
be offensive (in fact, I think it was rather polite, but then again English is
not my first language so I may be wrong).

Now that this is cleared, please let's all get back to bug fixing.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#754511: mpv: after each track it either displays dvd menu or copyright blurb

[Alessandro Ghedini]

On Fri, Jul 11, 2014 at 11:41:25PM +0200, arne anka wrote:
> Package: mpv
> Version: 1:0.4.1-dmo1
> Severity: normal
> 
> Dear Maintainer,
> 
> having a dvd image with 3 tracks, i play it via
> 
> mpv -dvd-image  dvd://0-2
> 
> but instead of siwtching seamlessly to the next track, after track 0 and 1 i 
> get the dvd menu and after track 2 it plays the copyright blurb. while after 
> the blurb at leats it finishes, it stays at the menu unless i intervene.
> i'd expect it to behave like mplayer does: play all tracks after each 
> automatically other without

This also happens with vlc, so I think it could be a bug in libdvdnav. Though I
have a multi-dvd movie that at the end of the track shows a "Go to disc 2"
pseudo-menu thing, instead of the main menu, so I guess this has actually some
use (albeit pretty questionable).

FWIW, you can go back to "mplayer behaviour" by using dvdread:// instead of
dvd://.


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#754512: mpv: dvd:// plays second track

[Alessandro Ghedini]

On ven, lug 11, 2014 at 11:44:46 +0200, arne anka wrote:
> Package: mpv
> Version: 1:0.4.1-dmo1
> Severity: normal
> 
> Dear Maintainer,
> 
> playing a dvd image with 7 tracks (0-3 are episodes, 4-6 are just the usual 
> fillers) via
> 
> mpv -dvd-image  dvd://
> 
> plays the second track, not the first. i am not quite sure what exactly to
> expect (just playing or presenting the dvd menu or something entirely
> different), but i think it shouldn't skip the first track.

From the manpage:

> If no title is given, the longest title is auto-selected.

So this is actually a feature. E.g. if you are playing a movie DVD, it plays the
movie track by default, which is IMO a good thing, but it kinda falls apart in
your case, since longest track doesn't really mean "most important".

(I also just noticed that this is not mentioned in the 0.4.0 release notes,
gonna fix that now).

I'm gonna see if upstream wants to change this back to "0" or something like
that.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#754510: mpv: segfaults on too short tracks

[Alessandro Ghedini]

On Fri, Jul 11, 2014 at 11:37:39PM +0200, arne anka wrote:
> Package: mpv
> Version: 1:0.4.1-dmo1

Could you please stop filing bugs for versions that are not in Debian? It
happened in the past that bugs filed for versions of packages from
deb-multimedia were not present in the official Debian packages.

> Severity: normal
> 
> Dear Maintainer,
> 
> lsdvd 
> 
> Title: 01, Length: 00:22:04.000 Chapters: 01, Cells: 01, Audio streams: 06, 
> Subpictures: 12
> Title: 02, Length: 00:21:54.400 Chapters: 01, Cells: 01, Audio streams: 06, 
> Subpictures: 12
> Title: 03, Length: 00:21:52.000 Chapters: 01, Cells: 01, Audio streams: 06, 
> Subpictures: 12
> Title: 04, Length: 00:00:00.480 Chapters: 01, Cells: 01, Audio streams: 06, 
> Subpictures: 12
> Title: 05, Length: 00:00:12.800 Chapters: 01, Cells: 01, Audio streams: 06, 
> Subpictures: 12
> Title: 06, Length: 00:00:00.480 Chapters: 01, Cells: 01, Audio streams: 06, 
> Subpictures: 12
> Title: 07, Length: 00:03:14.000 Chapters: 01, Cells: 01, Audio streams: 06, 
> Subpictures: 12
> Longest track: 01
> 
> playing
> 
> mpv -dvd-image  dvd://3

The "dvd-image" option doesn't exist, did you mean --dvd-device?

> causes mpv to segfault (since mpv starts with 0 whereas lsdvd starts at 1, 
> track 3 for mpv is track 4 of lsdvd output)
> 
> let me know what i can do to provide more info.

I can't reproduce.

Would it be possible for you to upload this dvd image somewhere so I can test
this? Or even an image with only the affected track, if it still causes the bug.

It would be also useful if you could provide a backtrace of the crash (using
gdb) with the mpv-dbg package installed.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#722997: File currently included as changelog is (at most) a NEWS file

[Alessandro Ghedini]

On Sat, Jul 12, 2014 at 01:16:34PM +0200, Jonas Smedegaard wrote:
> Makes perfect sense for a NEWS file to include only major changes (which 
> in effect means only changes applied to major releases when release 
> management is strict about not sneaking in major changes in minro 
> releases).
> 
> So please ignore my too harsh judgement on that file - only thing 
> confusing is shipping it as "changelog": A changelog is expected to 
> _cover_ all changes even if not necessarily very granularly - i.e. 
> shortening to say "Misc. internal code cleanup" is fine, but making a 
> release with *no* changelog entry is weird.

Now that I think about this, it would probably make sense to include the point
releases in the RELEASE_NOTES too. Something like:

Release 0.4.1
=

- change
- change
...

Release 0.4.0
=

- change
- change
...

This "changelog" would only include releases in the current 0.X branch (which
I think is ok) from the latest .0 release up to the latest point release.

This way users can see what was fixed in a later point release (e.g. if they hit
a bug in, say, the .0 release, they can check if that's been fixed in .1).

FWIW, I did write release notes for the 0.4.1 release [0] but I didn't include
them in the RELEASE_NOTES file, so that wouldn't really be much more work.

Cheers

[0] https://github.com/mpv-player/mpv/releases/tag/v0.4.1


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#722997: File currently included as changelog is (at most) a NEWS file

[Alessandro Ghedini]

On Sat, Jul 12, 2014 at 12:24:11AM +0200, Jonas Smedegaard wrote:
> reopen 722997
> thanks
> 
> Thanks for including upstream release notes.  That file, however, seems 
> at most a NEWS file: It is apparently an unmaintained broad overview of 
> changes for some specific release - without mention of which one, but 
> didn't at all since it was included and mentions only two git hashes, no 
> version numbers.

The RELEASE_NOTES file *is* maintained (in fact *I* maintain it, since I somehow
became mpv's release manager) and it refers to the latest major release (0.X.0).

It's also not really "broad", since it reflects pretty accurately what
user-facing changes went into the release (of course, I could have missed
something since the 0.4.0 release had something like 1400 new commits).

But I can see why it's confusing. I guess I can add the version number at the
top or something, that's not a problem.

The notes however do not include changes in the point releases (e.g. 0.4.1),
which are only fixes for regressions introduced by previous releases in the same
0.X branch. Not sure if it would make sense to include them as well (or how). In
the future there won't be as many point releases as in the past tough (which is
a good thing I guess), since major releases will be released more often, so
maybe this isn't that much of a problem.

I've also thought about having a proper ChangeLog file that includes all the
releases, but it would be difficiult to maintain due to mpv's release process
(releases come from separate release/0.X branches, which are never merged back
into master, so at best the chanelog would only include releases from the same
0.X series).

I'm still getting the hang of this release manager business tough (v0.4.0 was my
first release, snd it was a pretty big one), so suggestions are appreciated.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#753265: mpv: dvd tracks index starts at 0 instead of 1

[Alessandro Ghedini]

On dom, giu 29, 2014 at 11:06:57 +0200, arne anka wrote:
> Package: mpv
> Version: 1:0.4.0-dmo1

Uhm...

> Severity: normal
> 
> Dear Maintainer,
> 
> recent version suddenly starts to enumerate dvd tracks at 0 instead of the
> usual 1, which means that dvd://1-3 will play tracks 2-4 

Yeah, seems like this was on purpose, to make the "disc-title" property
consistent across bd, mkv and dvd streams (the other two already start from 0).

I don't think there's much I can do about this.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#753296: Acknowledgement (mpv completion fails)

[Alessandro Ghedini]

On Mon, Jun 30, 2014 at 03:38:48PM +0200, Yuri D'Elia wrote:
> On 06/30/2014 01:40 PM, Alessandro Ghedini wrote:
> >>> The problem you're describing looks like a broken completions-cache
> >>> file. Before you proceed, try this:
> >>>
> >>>   % rm ~/.zcompdump
> >>>   % exec zsh
> >>>
> >>> And see if the problem persists.
> >>
> >> It persists.
> > 
> > Can you post the content of /usr/share/zsh/vendor-completions/_mpv? Also, 
> > what
> > architecture are you on? The script is generated at build time, so it might 
> > be
> > that the generation broke on some platforms.
> 
> Attaching.

Yep, that's definitely broken... what architecture are you on? AFAICT both amd64
and i386 look fine.

Does running "apt-get install --reinstall mpv" help?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#753296: Acknowledgement (mpv completion fails)

[Alessandro Ghedini]

On lun, giu 30, 2014 at 12:26:09 +0200, Yuri D'Elia wrote:
> On 06/30/2014 12:17 PM, Frank Terbeck wrote:
> > Yuri D'Elia wrote:
> >> Ahh sorry, I noticed only now that the _mpv function is shipped with mpv
> >> itself.
> >>
> >> Could you reassign it to mpv?
> > 
> > The problem you're describing looks like a broken completions-cache
> > file. Before you proceed, try this:
> > 
> >   % rm ~/.zcompdump
> >   % exec zsh
> > 
> > And see if the problem persists.
> 
> It persists.

Can you post the content of /usr/share/zsh/vendor-completions/_mpv? Also, what
architecture are you on? The script is generated at build time, so it might be
that the generation broke on some platforms.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#753090: [mpv] refuses to work

[Alessandro Ghedini]

On dom, giu 29, 2014 at 08:45:57 +0100, Bartek wrote:
> Package: mpv
> Version: 0.4.0-1
> Severity: normal
> 
> 
> Hi,
> 
> When trying to open any multimedia file mpv gives an error:
> 
> mpv -vvv --msg-level=all=trace any_multimedia.file
> [cplayer] mpv 0.4.0 (C) 2000-2014 mpv/MPlayer/mplayer2 projects
> [cplayer]  built on 2014-06-25T19:12:56
> [cplayer] libav library versions:
> [cplayer]libavutil   53.3.0
> [cplayer]libavcodec  55.34.1
> [cplayer]libavformat 55.12.0
> [cplayer]libswscale  2.1.2 (runtime 2.1.100)

This libswscale version doesn't come from Debian...

> libswscale2 (>= 6:10~beta1~) | 7:0.10.3-dmo1

As I suspected, this comes from deb-multimedia... please install the official
Debian version and try again.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#751321: mpv: non-standard gcc/g++ used for build (gcc-4.7)

[Alessandro Ghedini]

Control: tags -1 pending

On mer, giu 11, 2014 at 08:07:54 +, Matthias Klose wrote:
> Package: mpv
> Version: 0.3.10-2
> Severity: important
> Tags: sid jessie
> User: debian-...@lists.debian.org
> Usertags: non-standard-compiler, gcc-4.7, gcc-4.7-legacy
> 
> This package builds with a non standard compiler version; please check
> if this package can be built with the default version of gcc/g++, or
> with gcc-4.9/g++-4.9.

mpv requires at least gcc-4.8 to build, so I made it Build-Depends on it on
sparc (and powerpc, but that was fixed a while ago) because it had the wrong
default gcc version. I see now that this is not needed anymore, so I removed the
Build-Depends for sparc too.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] mpv/experimental: Update symbols

[Alessandro Ghedini]

On dom, giu 08, 2014 at 01:30:48 -0400, Reinhard Tartler wrote:
> Usually dropping a symbol is an ABI break that warrants bumping the SONAME.
> What's the story here?

Well, this is just a git snapshot uploaded to experimental: upstream is not
going to bump the SONAME since the library thing hasn't been in an official
release yet, and on the Debian side, since it's in experimental I don't think
it warrants a SONAME bump and package rename either.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#749179: mpv: "Segment violation" when trying to reproduce any mpeg-4 video

[Alessandro Ghedini]

On sab, mag 24, 2014 at 11:38:53 +0200, David wrote:
> Package: mpv
> Version: 0.3.9-2
> Severity: important
> 
> Dear Maintainer,
> 
> I don't know the reason, but last few days I get "Segment violation" error 
> when
> trying to reproduce any mpeg-4 video, mpeg1... Mplayer2 works with some
> problems, and vlc works flawlessly.
> 
> Perhaps some library versions updated in last days in testing. I don't know.
> Error message only says "segment violation", without eny detail.
> 
> If you need more info, please ask me.

I can't reproduce this so a sample file that causes the problem would be quite
useful. Alternatively, it would be nice if you could post a backtrace of the
crash taken with gdb. This is most likely a bug in libav so make sure to install
libav-dbg as well to get a better trace.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#747680: FTBFS: error: redefinition of 'struct Lilv::UI'

[Alessandro Ghedini]

Control: reassing -1 liblilv-dev
Control: retitle -1 liblilv-dev: error: redefinition of 'struct Lilv::UI' in 
C++ header
Control: tags -1 pending
Control: affects -1 ecasound

On dom, mag 11, 2014 at 02:09:28 +0200, Christian Hofstaedtler wrote:
> Source: ecasound
> Version: 2.9.1-4
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear Maintainer,
> 
> during a rebuild of ruby-related packages, your package failed to build
> with these errors:

Sorry for the delay, I somehow missed the report.

> In file included from audiofx_lv2.h:11:0,
>  from eca-object-factory.cpp:51:
> /usr/include/lilv-0/lilv/lilvmm.hpp:173:8: error: redefinition of 'struct 
> Lilv::UI'
>  struct UI {
> ^
> /usr/include/lilv-0/lilv/lilvmm.hpp:152:8: error: previous definition of 
> 'struct Lilv::UI'
>  struct UI {
> ^
> /usr/include/lilv-0/lilv/lilvmm.hpp:190:8: error: redefinition of 'struct 
> Lilv::UIs'
>  struct UIs {
> ^
> /usr/include/lilv-0/lilv/lilvmm.hpp:169:8: error: previous definition of 
> 'struct Lilv::UIs'
>  struct UIs {
> ^
> [..]
> Makefile:1282: recipe for target 'eca-object-factory.lo' failed
> [..]
> debian/rules:16: recipe for target 'override_dh_auto_build' failed
> make[1]: Leaving directory '/«PKGBUILDDIR»'
> make: *** [build] Error 2
> debian/rules:10: recipe for target 'build' failed
> dpkg-buildpackage: error: debian/rules build gave error exit status 2

This looks like a bug in lilv. In the lilvmm.hpp header the structs UI and UIs
are repeated. It seems that a misapplied patch (that should have been removed)
is the cause. I'm working on a fix right now.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#747663: mpv: hwdev=vaapi has bad quality output

[Alessandro Ghedini]

On dom, mag 11, 2014 at 12:19:14 +0200, Kurt Roeckx wrote:
> On Sat, May 10, 2014 at 11:34:27PM +0200, Alessandro Ghedini wrote:
> > On sab, mag 10, 2014 at 10:55:09 +0200, Kurt Roeckx wrote:
> > > Package: mpv
> > > Version: 0.3.9-1
> > > 
> > > Hi,
> > > 
> > > I've been using hwdec=vaapi for a while now and things looked
> > > good.  Yesterday I upgraded from 0.3.8-1 to 0.3.9-1 and everything
> > > I look at now looks really bad.
> > 
> > Does this mean that downgrading to 0.3.8-1 fixes the problem? There haven't 
> > been
> > any changess to the vaapi code in 0.3.9, so I suspect this may not be mpv's
> > fault.
> 
> No, still the same with 0.3.8-1.
> 
> > In particular, the most recent libav in sid/testing is supposed to fix a
> > vaapi-related bug (#745655), what version of 
> > libavcodec54/libavformat54/etc...
> > are you using? Does it get better if you upgrade/downgrade to a different
> > version?
> 
> So today I got an update of those from 6:9.11-3+b3 to 6:9.13-1.
> Downgradeing libavcodec54 back to 6:9.11-3+b3 fixes the issue.

Does this still happen with mpv 0.3.9-2 (which is built against libav10) in sid?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#739936: closed by Alessandro Ghedini (Re: Bug#739936: mpv: no 'ICY Info' metadata printed when playing from playlist stream)

[Alessandro Ghedini]

On Sun, May 11, 2014 at 10:06:16PM -0500, Brian Paterni wrote:
> Thanks for your work on this bug Alessandro!
> 
> Since I'm running unstable, I've been patiently waiting for the
> transition to libav10. I see that it has apparently hit today with
> libavformat55 6:10.1-1, but I'm still not seeing printing of metadata
> by mpv. My assumption was that I'd be able to see this information
> once the transition went through. Is this not the case? Must I tell
> mpv to print stream metadata manually somehow?

The transition just barely started (it will end when libav0 migrates to
testing), and mpv hasn't been rebuilt yet. Anyway, I just uploaded 0.3.9-2 to
try to speed things up a bit.


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#739079: transition: libav10

[Alessandro Ghedini]

On dom, mag 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote:
> On Sun, May 11, 2014 at 11:50 AM, Julien Cristau  wrote:
> > For reference last time took 2 months.
> 
> I'll be doing my best to make it happen faster this time.

If help is needed I can lend a hand.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#747663: libavcodec54: vaapi doesn't work (Was: mpv: hwdev=vaapi has bad quality output)

[Alessandro Ghedini]

Control: retitle -1 libavcodec54: vaapi doesn't work
Control: reassign -1 libavcodec54

On dom, mag 11, 2014 at 12:19:14 +0200, Kurt Roeckx wrote:
> On Sat, May 10, 2014 at 11:34:27PM +0200, Alessandro Ghedini wrote:
> > On sab, mag 10, 2014 at 10:55:09 +0200, Kurt Roeckx wrote:
> > > Package: mpv
> > > Version: 0.3.9-1
> > > 
> > > Hi,
> > > 
> > > I've been using hwdec=vaapi for a while now and things looked
> > > good.  Yesterday I upgraded from 0.3.8-1 to 0.3.9-1 and everything
> > > I look at now looks really bad.
> > 
> > Does this mean that downgrading to 0.3.8-1 fixes the problem? There haven't 
> > been
> > any changess to the vaapi code in 0.3.9, so I suspect this may not be mpv's
> > fault.
> 
> No, still the same with 0.3.8-1.
> 
> > In particular, the most recent libav in sid/testing is supposed to fix a
> > vaapi-related bug (#745655), what version of 
> > libavcodec54/libavformat54/etc...
> > are you using? Does it get better if you upgrade/downgrade to a different
> > version?
> 
> So today I got an update of those from 6:9.11-3+b3 to 6:9.13-1.
> Downgradeing libavcodec54 back to 6:9.11-3+b3 fixes the issue.

Ok, I'm reassigning this to libavcodec54. This may be fixed in libav10 though,
which has been uploaded to unstable just today.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#747663: mpv: hwdev=vaapi has bad quality output

[Alessandro Ghedini]

On sab, mag 10, 2014 at 10:55:09 +0200, Kurt Roeckx wrote:
> Package: mpv
> Version: 0.3.9-1
> 
> Hi,
> 
> I've been using hwdec=vaapi for a while now and things looked
> good.  Yesterday I upgraded from 0.3.8-1 to 0.3.9-1 and everything
> I look at now looks really bad.

Does this mean that downgrading to 0.3.8-1 fixes the problem? There haven't been
any changess to the vaapi code in 0.3.9, so I suspect this may not be mpv's
fault.

In particular, the most recent libav in sid/testing is supposed to fix a
vaapi-related bug (#745655), what version of libavcodec54/libavformat54/etc...
are you using? Does it get better if you upgrade/downgrade to a different
version?

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#745216: librtmp-dev: Does package really depend on libgnutls-dev?

[Alessandro Ghedini]

Control: block 741568 by -1

On sab, apr 19, 2014 at 02:49:59 +0930, Arthur Marsh wrote:
> Package: librtmp-dev
> Version: 2.4+20131018.git79459a2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Trying to install the package on a system with libgnutls28-dev installed.
> 
> Is there a fundamental conflict between these packages, or is this just
> a packaging issue.

Indeed, this is preventing me to switch curl to libgnutls28. AFAICT, the only
reason librtmp-dev depends on libgnutls-dev is because librtmp.pc has a
"Requires: gnutls", but it doesn't seem to actually need it (i.e. none of the
librtmp-dev headers #includes gnutls.h, and librtmp.pc doesn't have -lgnutls
anywhere), but I may be wrong.

FWIW, librtmp could just switch to libgnutls28.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736088: libavcodec54: file command reports wrong bitrate on mp3 file encoded by libav

[Alessandro Ghedini]

Control: tags -1 fixed-upstream

On sab, mar 08, 2014 at 09:25:35 -0500, Reinhard Tartler wrote:
> On Fri, Mar 07, 2014 at 12:04:25PM +0100, Alessandro Ghedini wrote:
> > So, I've done a bit of investigation, and it turns out that this is caused 
> > by
> > the way libavformat writes the XING header to mp3 files. Essentially, it 
> > uses
> > a fixed value for bitrate_idx... for any bitrate values.
> > 
> > This also makes tools like mediainfo detect an avconv-encoded mp3 file as
> > using constant bitrate, while in fact it might be using a variable bitrate
> > (though I'm not sure if this is actually the same bug, or a different bug 
> > in the
> > same code).
> > 
> > More or less copy-pasting the mp3_write_xing() function 
> > (libavformat/mp3enc.c)
> > from ffmpeg to libav seems to fix the problem.
> 
> Could you please provide a patch, and send (or copy) it to 
> libav-de...@libav.org, please?

This is now fixed upstream [0].

Cheers

[0] 
https://git.libav.org/?p=libav.git;a=commit;h=617a1a98a6be3e59db6fbfc21afab2fb9a049c03

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#743713: x264: FTBFS on sparc: cc1: error: unrecognized command line option '-fno-aggressive-loop-optimizations'

[Alessandro Ghedini]

On sab, apr 05, 2014 at 05:50:26 -0400, Reinhard Tartler wrote:
> On Sat, Apr 5, 2014 at 10:35 AM, Julien Cristau  wrote:
> > Source: x264
> > Version: 2:0.142.2389+git956c8d8-3
> > Severity: important
> >
> > See the build log at
> > https://buildd.debian.org/status/fetch.php?pkg=x264&arch=sparc&ver=2%3A0.142.2389%2Bgit956c8d8-3&stamp=1396707861
> >
> > Looks like that option is not recognized by gcc 4.6.
> 
> Uhm, isn't gcc-4.8 supposed to be the default compiler for all archs
> in wheezy? I notice that you did not file this as an RC bug, does that
> mean that you don't consider sparc critical for the current x264
> transition?

sparc is not a testing blocker anymore (at least for the time being), in part
for that reason. See [0] [1] [2].

Cheers

[0] https://lists.debian.org/debian-devel-announce/2013/11/msg7.html
[1] https://lists.debian.org/debian-devel-announce/2013/12/msg8.html
[2] https://lists.debian.org/debian-devel-announce/2014/01/msg8.html

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#741439: mpv: Please enable all hardening options

[Alessandro Ghedini]

On Sun, Mar 23, 2014 at 04:21:46PM +0100, Simon Ruderich wrote:
> On Wed, Mar 12, 2014 at 04:49:31PM +0100, Alessandro Ghedini wrote:
> > Pushed to git, thanks! Note that we already pass "-v" to waf, so "V := 1" 
> > isn't
> > needed (and it doesn't work with waf anyway).
> 
> Hello,
> 
> Thanks for fixing it so quickly.
> 
> Would it be possible to patch/modify the build system to generate
> output parseable by blhc to verify all hardening flags are
> applied correctly?
> 
> At the moment it looks like this:
> 
> 15:39:24 runner ['/usr/bin/cc', '-D_FORTIFY_SOURCE=2', '-g', '-O2',
> 
> If this could get changed to:
> 
> 15:39:24 runner /usr/bin/cc -D_FORTIFY_SOURCE=2 -g -O2 ..
> 
> then blhc (used by the buildd log scanner [1]) could verify the
> compiler commands.

I don't think that's posible (the "waf --help" output doesn't show anything
relevant), not without patching waf anyway. It'd be probably easier to make
blhc support this kind of output. But I'm not a waf expert so I may be wrong.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#740421: mpv: Really slow to start playing audio stream

[Alessandro Ghedini]

Control: tags -1 fixed-upstream -patch

On sab, mar 01, 2014 at 01:38:46 +0100, Kurt Roeckx wrote:
> Package: mpv
> Version: 0.3.5-1
> 
> Hi,
> 
> When using mpv to play an audio stream I get:
> $ mpv http://mp3.streampower.be/radio1.aac
> Playing: http://mp3.streampower.be/radio1.aac
> [cache] Cache size set to 320 KiB
> Cache fill: 20.62% (67584 bytes)   
> [cache] Cache is not responding - slow/stuck network connection?
> [cache] Cache keeps not responding.
> [cache] Cache is not responding - slow/stuck network connection?
> [cache] Cache keeps not responding.
> [cache] Cache is not responding - slow/stuck network connection?
> [cache] Cache is not responding - slow/stuck network connection?
> [libav/audio] aac: get_buffer() failed
> [libav/demuxer] aac: max_analyze_duration reached
> [libav/demuxer] aac: Estimating duration from bitrate, this may be inaccurate
> Detected file format: raw ADTS AAC (Advanced Audio Coding) (libavformat)
> File is not seekable, but there's a cache: enabling seeking.
> [stream] Audio (+) --aid=1 (aac)
> Video: no video
> [libav/audio] aac: invalid band type
> Selected audio codec: AAC (Advanced Audio Coding) [lavc:aac]
> AO: [alsa] 48000Hz stereo 2ch floatp
> A: 00:01:03 / 00:00:00 (0%) Cache: 47%
> 
> It gets to this "Cache fill: 20.62% (67584 bytes)" fast, and then
> stalls and starts to show thise cache lines.  Then after some time
> it plays audio for like 0.2 seconds or something, then it starts
> showing the "A: " line and cache is filling for a while, and then
> after some time it starts to play, with a huge delay between when
> it's send and when I hear it.

This has now been fixed in libav.git (commit [0]).

> (It also shows the stream info, which mpv doesn't)

Same. See #739936.

Cheers

[0] 
http://git.libav.org/?p=libav.git;a=commit;h=e58c85b0686892960042232e51c77168b264838a

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#739936: mpv: no 'ICY Info' metadata printed when playing from playlist stream

[Alessandro Ghedini]

Control: tags -1 fixed-upstream -patch

On Sun, Feb 23, 2014 at 11:03:29PM -0600, Brian Paterni wrote:
> Package: mpv
> Version: 0.3.5-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I sometimes use mpv to listen to online audio streams. Something useful that I
> find lacking in mpv but available in mplayer2 though is the output of stream
> metadata. mplayer2 for example displays the artist and title of the currently
> playing song. This is something I would like to have displayed in mpv's output
> as well, but either mpv currently doesn't have this ability or I can't seem to
> find how to tell it to do so.
> 
> I would very much appreciate it if the maintainer/upstream could look into 
> this
> functionality.

This has now been fixed in libav.git (commits [0] and [1]).

Cheers

[0] 
http://git.libav.org/?p=libav.git;a=commit;h=8075c3d8bb1f6aade0cc7c5c40db9bc1bcd84cab
[1] 
http://git.libav.org/?p=libav.git;a=commit;h=6998a9f4c4e069f515c50614179f4cfc7d0184f5

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#741439: mpv: Please enable all hardening options

[Alessandro Ghedini]

Control: tags -1 pending

On Wed, Mar 12, 2014 at 02:38:47PM +0100, Simon Ruderich wrote:
> Package: mpv
> Version: 0.3.6-1
> Severity: normal
> Tags: patch
> 
> Hello,
> 
> As audio/movie player, mpv is vulnerable to exploits in the used
> libraries, which are common. PIE and bindnow provide additional
> hardening against those attacks. Please enable them by default.
> 
> The following patch enables all additional flags (PIE and
> bindnow) and enables a verbose build to detect missing flags:

Pushed to git, thanks! Note that we already pass "-v" to waf, so "V := 1" isn't
needed (and it doesn't work with waf anyway).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736088: libavcodec54: file command reports wrong bitrate on mp3 file encoded by libav

[Alessandro Ghedini]

On sab, mar 08, 2014 at 09:25:35 -0500, Reinhard Tartler wrote:
> tags 736088 +upstream
> stop
> 
> On Fri, Mar 07, 2014 at 12:04:25PM +0100, Alessandro Ghedini wrote:
> > So, I've done a bit of investigation, and it turns out that this is caused 
> > by
> > the way libavformat writes the XING header to mp3 files. Essentially, it 
> > uses
> > a fixed value for bitrate_idx... for any bitrate values.
> > 
> > This also makes tools like mediainfo detect an avconv-encoded mp3 file as
> > using constant bitrate, while in fact it might be using a variable bitrate
> > (though I'm not sure if this is actually the same bug, or a different bug 
> > in the
> > same code).
> > 
> > More or less copy-pasting the mp3_write_xing() function 
> > (libavformat/mp3enc.c)
> > from ffmpeg to libav seems to fix the problem.
> 
> Could you please provide a patch, and send (or copy) it to 
> libav-de...@libav.org, please?

TBQH I don't really care much about this being fixed... now that I know what's
the problem I'm simply using "write_xing=0" since I'm only interested in
constant bitrate.

Also, I found that my "copy what ffmpeg does" patch introduces another bug that
makes mediainfo print some garbage (just after the LAME version), so it would
require someone who actually knows what the code is supposed to do to debug
this.

I'll try to look into this as soon as I have a bit of time, but I can't really
promise anything.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736088: libavcodec54: file command reports wrong bitrate on mp3 file encoded by libav

[Alessandro Ghedini]

Control: reassing -1 libavformat54
Control: retitle libavcodec54: wrongly set bitrate in XING header (mp3enc)

On dom, gen 19, 2014 at 11:33:13 -0500, Reinhard Tartler wrote:
> Also note that avprobe does report the "correct" bitrate:
> 
> avprobe version 0.8.9-6:0.8.9-0ubuntu0.13.04.1, Copyright (c)
> 2007-2013 the Libav developers
>   built on Nov  9 2013 19:09:48 with gcc 4.7.3
> Input #0, mp3, from 'noise_avconv.mp3':
>   Metadata:
> encoder : Lavf53.21.1
>   Duration: 00:00:05.04, start: 0.00, bitrate: 320 kb/s
> Stream #0.0: Audio: mp3, 48000 Hz, mono, s16, 320 kb/s

So, I've done a bit of investigation, and it turns out that this is caused by
the way libavformat writes the XING header to mp3 files. Essentially, it uses
a fixed value for bitrate_idx... for any bitrate values.

This also makes tools like mediainfo detect an avconv-encoded mp3 file as
using constant bitrate, while in fact it might be using a variable bitrate
(though I'm not sure if this is actually the same bug, or a different bug in the
same code).

More or less copy-pasting the mp3_write_xing() function (libavformat/mp3enc.c)
from ffmpeg to libav seems to fix the problem.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#739936: libavformat54: merge HTTP parser from ffmpeg

[Alessandro Ghedini]

Control: tags 739936 patch
Control: tags 740421 patch

As reported in #740421 libav's HTTP audio streaming is really slow on startup,
and as reported in #739936 it doesn't support ICY metadata. So I decided to see
if I could merge ffmpeg's HTTP thingy in libav... and it turns out that it was
actually rather easy.

Basically I copied libavformat/http.c from ffmpeg to libav, and fixed a bunch
of compile issues. The patch also includes the addtion of av_asprintf() and
av_strtok() since they are needed to build.

Again, I don't know what's libav policy for merging stuff from ffmpeg, but this
patch brings a pretty big improvement to libav's audio streaming support.

(also worth noting is that I only tested this patch with libav's package from
experimental).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
From a0bc33f5fa8290f5724252784cabf4f167f18ebf Mon Sep 17 00:00:00 2001
From: Alessandro Ghedini 
Date: Wed, 5 Mar 2014 16:53:03 +0100
Subject: [PATCH] http: merge HTTP parser from ffmpeg

Bug-Debian: https://bugs.debian.org/740421
Bug-Debian: https://bugs.debian.org/739936
---
 libavformat/http.c   | 248 ---
 libavutil/avstring.c |  55 
 libavutil/avstring.h |  34 +++
 3 files changed, 324 insertions(+), 13 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 96f56f8..2e529f3 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -50,18 +50,30 @@ typedef struct {
 int line_count;
 int http_code;
 int64_t chunksize;  /**< Used if "Transfer-Encoding: chunked" otherwise -1. */
-int64_t off, filesize;
+char *content_type;
+char *user_agent;
+int64_t off, filesize, req_end_offset;
+int icy_data_read;  ///< how much data was read since last ICY metadata packet
+int icy_metaint;///< after how many bytes of read data a new metadata packet will be found
 char *location;
 HTTPAuthState auth_state;
 HTTPAuthState proxy_auth_state;
 char *headers;
 int willclose;  /**< Set if the server correctly handles Connection: close and will close the connection after feeding us the content. */
+int seekable;   /**< Control seekability, 0 = disable, 1 = enable, -1 = probe. */
 int chunked_post;
 int end_chunked_post;   /**< A flag which indicates if the end of chunked encoding has been sent. */
 int end_header; /**< A flag which indicates we have finished to read POST reply. */
 int multiple_requests;  /**< A flag which indicates if we use persistent connections. */
 uint8_t *post_data;
 int post_datalen;
+int is_akamai;
+int is_mediagateway;
+char *mime_type;
+char *cookies;  ///< holds newline (\n) delimited Set-Cookie header field values (without the "Set-Cookie: " field name)
+int icy;
+char *icy_metadata_headers;
+char *icy_metadata_packet;
 #if CONFIG_ZLIB
 int compressed;
 z_stream inflate_stream;
@@ -74,16 +86,27 @@ typedef struct {
 #define OFFSET(x) offsetof(HTTPContext, x)
 #define D AV_OPT_FLAG_DECODING_PARAM
 #define E AV_OPT_FLAG_ENCODING_PARAM
+#define DEFAULT_USER_AGENT "Lavf/" AV_STRINGIFY(LIBAVFORMAT_VERSION)
 static const AVOption options[] = {
+{"seekable", "control seekability of connection", OFFSET(seekable), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, D },
 {"chunked_post", "use chunked transfer-encoding for posts", OFFSET(chunked_post), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, E },
-{"headers", "custom HTTP headers, can override built in default headers", OFFSET(headers), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D|E },
+{"headers", "set custom HTTP headers, can override built in default headers", OFFSET(headers), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D|E },
+{"content_type", "force a content type", OFFSET(content_type), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D|E },
+{"user-agent", "override User-Agent header", OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = DEFAULT_USER_AGENT}, 0, 0, D },
 {"multiple_requests", "use persistent connections", OFFSET(multiple_requests), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, D|E },
-{"post_data", "custom HTTP post data", OFFSET(post_data), AV_OPT_TYPE_BINARY, .flags = D|E },
+{"post_data", "set custom HTTP post data", OFFSET(post_data), AV_OPT_TYPE_BINARY, .flags = D|E },
+{"mime_type", "set MIME type", OFFSET(mime_type), AV_OPT_TYPE_STRING, {0}, 0, 0, 0 },
+{"cookies", "set cookies to be sent in applicable future requests, use newline delimited Set-Cookie HTTP field value syntax", OFFSET(cookies), AV_OPT_TYPE_STRING, {0}, 0, 0, D },
+{"icy", "request ICY metadata", OFFSET(icy), AV_OPT_TYPE_INT, {.

Bug#740421: mpv: Really slow to start playing audio stream

[Alessandro Ghedini]

Control: reassign -1 libavformat54
Control: retitle -1 libavformat54: really slow HTTP audio streaming (unlike 
ffmpeg)
Control: affects -1 mpv

On sab, mar 01, 2014 at 01:38:46 +0100, Kurt Roeckx wrote:
> Package: mpv
> Version: 0.3.5-1
> 
> Hi,
> 
> When using mpv to play an audio stream I get:
> $ mpv http://mp3.streampower.be/radio1.aac
> Playing: http://mp3.streampower.be/radio1.aac
> [...]
> 
> It gets to this "Cache fill: 20.62% (67584 bytes)" fast, and then
> stalls and starts to show thise cache lines.  Then after some time
> it plays audio for like 0.2 seconds or something, then it starts
> showing the "A: " line and cache is filling for a while, and then
> after some time it starts to play, with a huge delay between when
> it's send and when I hear it.

This is a libav problem. In essence, mpv relies on libavformat for the HTTP
streaming, while mplayer2 implements its own client.

It turns out that the HTTP implementation in libav sucks, because I do not have
this problem with mpv built againt ffmpeg, but I can reproduce it when built
against the libav version in Debian (both sid and experimental) and from
upstream git.

Reassigning to libavformat.

> (It also shows the stream info, which mpv doesn't)

Yet another libav bug (not present in ffmpeg), see #739936.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#739936: mpv: no 'ICY Info' metadata printed when playing from playlist stream

[Alessandro Ghedini]

Control: reassign -1 libavformat54
Control: retitle -1 libavformat54: support for ICY stream metadata (like ffmpeg)
Control: affects -1 mpv

On dom, feb 23, 2014 at 11:03:29 -0600, Brian Paterni wrote:
> Package: mpv
> Version: 0.3.5-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I sometimes use mpv to listen to online audio streams. Something useful that I
> find lacking in mpv but available in mplayer2 though is the output of stream
> metadata. mplayer2 for example displays the artist and title of the currently
> playing song. This is something I would like to have displayed in mpv's output
> as well, but either mpv currently doesn't have this ability or I can't seem to
> find how to tell it to do so.

The fact is, mpv relies on libav/ffmpeg for the http streaming handling while
mplayer2 implements its own parser.

So, mpv does support reading of ICY metadata, but it only works with a recent
enough version of ffmpeg, and AFAICT it doesn't work at all with libav.

So, I'm reassigning this to libav.

(I don't know what's the libav policy for merging stuff from ffmpeg, but the
ffmpeg commit that added support for this seems to be [0], which incidentally
was done by mpv's upstream author).

Cheers

[0] 
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a92fbe16f2dc118c0d3adc222484268831388648

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: what does Debian Multimedia team think about uploading libgroove?

[Alessandro Ghedini]

On sab, feb 22, 2014 at 07:07:24 -0500, Andrew Kelley wrote:
> Alessandro,
> 
> Again thank you for your feedback. I have addressed all of it.
> 
> What is the next step?

I just tagged and uploaded it. Feel free to contact me privately (at the
gh...@debian.org address) or on the mailing list next time you need an upload.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#739801: mpv: Selected GLX FB config has no associated X visual issue

[Alessandro Ghedini]

Control: reassign -1 libgl1-mesa-glx
Control: forcemerge 739691 -1
Control: affects 739691 mpv
Control: tags 739691 fixed-upstream
Control: forwarded 739691 https://bugs.freedesktop.org/show_bug.cgi?id=70706

On sab, feb 22, 2014 at 11:58:32 -0500, Doug McMahon wrote:
> Package:mpv
> Version:0.3.5-1
> 
> Due to 2 bugs in mesa  in around 15% of sessions when using xserver-1.15 mpv 
> will use the default GLXFBconfig that has no visual id.
> This will produce any number of visual glitches, wrong colors ect.
> Prior to mpv commit67769db1a4e3a765c5f770f44f8b2b041a0246a9  in these cases 
> mpv would just use xv & unless the user had specified  gl the vid would 
> playback fine.
> mpv bugs -
> https://github.com/mpv-player/mpv/issues/564
> https://github.com/mpv-player/mpv/issues/573
> 
> upstream mesa bugs -
> http://patchwork.freedesktop.org/patch/20464/
> http://patchwork.freedesktop.org/patch/20458/
> 
> Launchpad mesa bug that is fixed released-
> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1278168

Reassigning to mesa.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: what does Debian Multimedia team think about uploading libgroove?

[Alessandro Ghedini]

On sab, feb 22, 2014 at 10:49:45 -0300, Felipe Sateler wrote:
> On Thu, Feb 20, 2014 at 6:30 PM, Andrew Kelley  wrote:
> > * Package name: libgroove
> >Version : 3.0.6-1
> >Upstream Author : Andrew Kelley 
> >  * URL : https://github.com/andrewrk/libgroove
> >  * License : Expat
> >Section : libs
> 
> As I said before, groovebasin looks cool. Are you planning on uploading it 
> too?
> 
> I'm interested, but a bit short on time. It might take me some time to
> go over the libgroove packaging.

I'm interested too (but I seem to have missed the original email from Anrew).

So, I had a quick look at the packaging and it generally looks good, but here
are a few comments:

* Since it requires libav10 to be built (e.g. libavutil/frame.h), you should
  note that in debian/control with appropriate versioned Build-Depends.

Build-Depends:
 [...]
 libavcodec-dev (>= 6:10~),
 libavfilter-dev (>= 6:10~),
 libavformat-dev (>= 6:10~),
 libavutil-dev (>= 6:10~),
 [...]

* While at it, there should be one Build-Depends per line, as per team policy.

Build-Depends: a,
 b,
 c,
 d

* The tarball downloaded with "uscan --download-current-version" is different
  from the one in the pristine-tar branch.

The difference seems to be that the upstream repository contains a deps/ folder
bundling the libraries needed to build it. The canonical Debian way to handle
this would be to repack the upstream tarball removing the directories (which is
what you did) but also providing an automated way to do that.

This is usually done by adding a "get-orig-source" target to debian/rules that
downloads the tarball using uscan, unpacks it, rm -rf the folder and repacks it.

Another way would be [0].

See Developer's Reference §6.7.8.2.

(I'm not quite sure if the team's packaging policy says anything about this).

[0] http://pkg-perl.alioth.debian.org/howto/repacking.html

* The file downloaded by uscan gets called "-3.0.6.tar.gz" instead
  of "libgroove-3.0.6.tar.gz" (not really a problem but it's kinda ugly).

* Any reason why you are using "version=2" instead of "version=3" in
  debian/watch?

* The comments in debian/rules added by dh_make should be removed.

* It'd be nice if you also provided *.symbols files for all the libraries built,
  see dpkg-gensymbols(1).

* It'd be nice if you provided -dbg packages for all the libraries built (or a
  single -dbg for all the libraries). This should be done e.g. by overriding
  dh_strip and calling it like "dh_strip --dbg-package=libgroove3-dbg".

That's all I think, but I may still have missed something. Feel free to ask if
you have any question.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#737838: [vo/vdpau] Error when calling vdp_device_create_x11: 1

[Alessandro Ghedini]

On lun, feb 10, 2014 at 03:34:13 +0100, Mathieu Malaterre wrote:
> $ glxinfo | grep OpenGL
> OpenGL vendor string: ATI Technologies Inc.
> OpenGL renderer string: AMD Radeon HD 7800M Series
> OpenGL version string: 4.3.12618 Compatibility Profile Context FireGL 8.982.13
> OpenGL shading language version string: 4.30
> OpenGL extensions:

So I looked into libvdpau code and the problem here is just that libvdpau can't
find a proper VDPAU driver, so it defaults to "nvidia". It's not really a
problem here, since you don't have a vdpau driver installed anyway (that is,
unless you use libvdpau-va-gl1, but in that case you have to manually set
VDPAU_DRIVER anyway).

The error you see from mpv is harmless, since it falls back automatically to
using the opengl vo if vdpau doesn't work. But if it bothers you, you can
silence it by defaulting to opengl manually (e.g. via the command-line or in the
configuration file)... or by using libvdpau-va-gl1.

> The opengl* family seems to be working nicely. However -hwdec=vaapi
> does not seems to be working for me:
> 
> [...]
> 
> [vaapi] Decoder profile 'VAProfileH264Main' not available.
> 
> [...]
> 
> I am guessing VAProfileH264High is not compatible with VAProfileH264Main

Yeah, I think so. It depends on how the video was encoded though, so other files
may work fine (the h264 "high" profile is used for HD movies and such).

> > On gio, feb 06, 2014 at 01:05:44 +0100, Mathieu Malaterre wrote:
> > If you do want to use vdpau instead of vaapi/xvba, and it is supported by 
> > your
> > video card, you need a working vdpau driver (which, AFAICT, is not 
> > available in
> > Debian for fglrx).
> 
> What do you mean ? What's broken about fglrx and vaapi in debian ?

fglrx and *vdpau* :) The problem is just that there is no VDPAU driver for fglrx
(even one that uses XvBA as backend like xvba-va-driver), unless you go the
libvdpau-va-gl1 -> xvba-va-driver route (the open-source Mesa Gallium3D drivers
do include vdpau drivers, but they don't seem to be built in Debian).

So um, overall I don't think there's really a bug in mpv here, so I'm closing
this report. Feel free to ask if you have any doubt, or reopen the report if you
think there's something to be fixed in mpv.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#737838: [vo/vdpau] Error when calling vdp_device_create_x11: 1

[Alessandro Ghedini]

Sorry for the delay, I seem to have missed the report.

On gio, feb 06, 2014 at 12:59:25 +0100, Mathieu Malaterre wrote:
> Package: mpv
> Version: 0.3.4-1
> 
> I am trying to use mpv on a wheezy system. It does build nicely
> however I cannot get the vdpau from amy AMD/ATI card to work.
> 
> [...]
> 
> $ mpv The\ Simpsons\ Movie\ -\ Trailer.mp4
> Playing: The Simpsons Movie - Trailer.mp4
> Detected file format: QuickTime / MOV (libavformat)
> Clip info:
>  major_brand: isom
>  minor_version: 1
>  compatible_brands: isomavc1
>  creation_time: 2007-02-19 05:03:04
> [stream] Video (+) --vid=1 (h264)
> [stream] Audio (+) --aid=1 --alang=und (aac)
> Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared
> object file: No such file or directory

If the video card has been misdetected, it would be a bug in libvdpau1... I
think. Can you please run "glxinfo | grep OpenGL"?

> However:
> 
> $ dpkg -S /usr/lib/x86_64-linux-gnu/dri/xvba_drv_video.so
> xvba-va-driver: /usr/lib/x86_64-linux-gnu/dri/xvba_drv_video.so

I think you are confusing VA-API and VDPAU here. They are two different things,
and xvba-va-driver only provides a backend for VA-API.

Incidentally mpv suports VA-API as well, so you may want to try to enable it
using "-vo=opengl" (or "-vo=opengl-hq") and "-hwdec=vaapi", or directly using
the vaapi vo ("-vo=vaapi") and "-hwdec=vaapi" (but the opengl one should be
better).

On gio, feb 06, 2014 at 01:05:44 +0100, Mathieu Malaterre wrote:
> Hum, googl'ing the issue I finally found:
> 
> https://wiki.archlinux.org/index.php/VDPAU#Configuration
> 
> Steps:
> 
> $ VDPAU_DRIVER=va_gl mpv The\ Simpsons\ Movie\ -\ Trailer.mp4

Yeah, but it's kinda convoluted (VDPAU frontend that uses VAAPI frontend that
uses XvBA hardware... assuming thet it actually uses the xvba-va driver instead
of just falling back to opengl). Using VAAPI/XvBA directly should be better (if
anything it's one package less to have installed).

If you do want to use vdpau instead of vaapi/xvba, and it is supported by your
video card, you need a working vdpau driver (which, AFAICT, is not available in
Debian for fglrx).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#737346: mpv: fails to play a CDXA/MPEG-PS video file

[Alessandro Ghedini]

Control: forcemerge 703206 -1

On dom, feb 02, 2014 at 01:03:06 +0400, Bob Bib wrote:
> Package: mpv
> Version: 0.3.2-1
> Severity: normal
> 
> Dear Maintainer,
> mpv fails to play a CDXA/MPEG-PS video file.
> 
> I suspect it's closely related to Debian bug #703206 (a bug in Libav).

Yeah, that's probably a libav bug, since mpv doesn't do any decoding by itself.

You may want to try mpv from experimental which is built against libav 10
(though it may change nothing).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736616: Bug#637757: libaudio-ecasound-perl: FTBFS on mips

[Alessandro Ghedini]

On lun, gen 27, 2014 at 08:48:10 +0200, Damyan Ivanov wrote:
> -=| Alessandro Ghedini, 26.01.2014 13:51:58 +0100 |=-
> > > The trace ends with:
> > > 
> > > ->8--
> > > [...]
> > > ->8--
> > 
> > This unfortunately doesn't seem to be very helpful since it doesn't show the
> > error (which actually happens in the middle of the clock_gettime()s). In any
> > case I don't think it would add much anyway.
> 
> I attach the trace (compressed) just in case.

Turns out that the trace was, in fact, quite useful, it's just that I missed the
most important part:

> 9068  <... poll resumed> )  = 0 (Timeout)

So, yeah, I have a patch that seems to work and I'm now waiting for upstream's
comments on it.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736616: Bug#637757: libaudio-ecasound-perl: FTBFS on mips

[Alessandro Ghedini]

On Sat, Jan 25, 2014 at 05:55:29PM +0200, Damyan Ivanov wrote:
> Control: clone -1 -2
> Control: reassign -2 libecasoundc1/2.9.1-1
> Control: retitle -2 libecasoundc1: int-cmd-list command fails on mips
> Control: block -1 by -2
> 
> Dear ecasound maintainers,
> 
> It appears there is a problem with ecasound/libecasoundc1 on mips, 
> which causes failures in the test suite of libaudio-ecasound-perl, 
> making it FTBFS.
> 
> I was able to isolate the problem using the following C program:

The problem seems to be that eci_init() fails, so a better test case would be:

#include 

#include 

int main(int argc, char *argv[]) {
eci_init();

if (eci_ready() == 0) {
puts("fail");
return 1;
}

return 0;
}

> The trace ends with:
> 
> ->8--
> [...]
> ->8--

This unfortunately doesn't seem to be very helpful since it doesn't show the
error (which actually happens in the middle of the clock_gettime()s). In any
case I don't think it would add much anyway.

Anyway, the problem seems to be in the eci_impl_read_return_value() function,
called by eci_init_r(). In particular, the last check fails, but I'm not quite
sure what it's supposed to test. I'll forward this upstream.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736088: libavcodec54: file command reports wrong bitrate on mp3 file encoded by libav

[Alessandro Ghedini]

Package: libavcodec54
Version: 6:9.10-2
Severity: normal

Hi,

I recently noticed something weird, but I'm not sure if it's actually a libav
bug (it doesn't happen with ffmpeg though). I noticed this while using mpv's
encoding facility, but it happens when using avconv as well.

So, basically, when I encode an audio file using libav's libmp3lame encoder, and
set a default bitrate (-b:a 320k), and then run  the file command on it, the
printed bitrate is always "64 kbps" even if the file is, in fact, 320 kbps.

To reproduce:

* Generate an audio file (you can also use another audio file, it doesn't
  change anything):

$ sox -n noise.wav synth 00:05 whitenoise

* Convert the file using avconv:

$ avconv -i noise.wav -c:a libmp3lame -b:a 320k -vn noise_avconv.mp3

* Run file on it:

$ file noise_avconv.mp3
noise_avconv.mp3: Audio file with ID3 version 2.4.0, contains: MPEG ADTS, 
layer III, v1,  64 kbps, 48 kHz, Monaural

You'll notice that the "64 kbps" doesn't match the "-b:a 320k", but the *.mp3
file *is* 320 kbps (the size of the file match and mp3info reports the correct
bitrate).

The same doesn't happen when using ffmpeg:

$ ffmpeg -i noise.wav -c:a libmp3lame -b:a 320k -vn noise_ffmpeg.mp3
$ file noise_ffmpeg.mp3
noise_ffmpeg.mp3: Audio file with ID3 version 2.4.0, contains: MPEG ADTS, 
layer III, v1, 320 kbps, 48 kHz, Monaural

Since mp3info reports the correct bitrate on both files (and the file are indeed
320 kbps), this may very well be a bug in file... but why doesn't the file
encoded using ffmpeg have this problem?

Also, yes, the libmp3lame is the same used to build both libav (installed from
Debian archive) and ffmpeg (manually built) and this happens with avconv and
libavcodec55 from experimental as well.

Cheers

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libavcodec54 depends on:
ii  libavutil526:9.10-2
ii  libc6  2.17-97
ii  libgsm11.0.13-4
ii  libmp3lame03.99.5+repack1-3
ii  libopenjpeg2   1.3+dfsg-4.7+b1
ii  libopus0   1.1-1
ii  libschroedinger-1.0-0  1.0.11-2
ii  libspeex1  1.2~rc1.1-1
ii  libtheora0 1.1.1+dfsg.1-3.1
ii  libva1 1.2.1-2
ii  libvorbis0a1.3.2-1.3
ii  libvorbisenc2  1.3.2-1.3
ii  libvpx11.3.0-2
ii  libx264-1332:0.133.2339+git585324f-2+b1
ii  libxvidcore4   2:1.3.2-9
ii  multiarch-support  2.17-97
ii  zlib1g 1:1.2.8.dfsg-1

libavcodec54 recommends no packages.

libavcodec54 suggests no packages.

-- no debconf information

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#735332: mpv: Doesn't use vaapi by default

[Alessandro Ghedini]

On Wed, Jan 15, 2014 at 06:33:17PM +0100, Kurt Roeckx wrote:
> On Wed, Jan 15, 2014 at 04:31:27PM +0100, Alessandro Ghedini wrote:
> > On mar, gen 14, 2014 at 10:09:02 +0100, Kurt Roeckx wrote:
> > > Package: mpv
> > > Version: 0.3.2-1
> > > 
> > > Hi,
> > > 
> > > It seems mpv tries to use vpdau and tries to load
> > > libvdpau_nvidia.so by default and fails.
> > > 
> > > It then tries to use gl instead, which works perfectly.
> > > 
> > > But I have an intel GPU, and I would make sense to use vaapi
> > > instead.  Using -vo vaapi at least seems to work for me.
> > > 
> > > Would it make sense to try to use vaapi by default?
> > 
> > Well, generally speaking VA API is kinda bad for video output (e.g. the OSD 
> > is
> > generally low quality, and in some cases the OSD and subtitles can't even be
> > drawn at the same time). I've never really used the VA API backend though, 
> > but
> > this seems to be upstream's opinion as well.
> 
> Both the OSD and subtitles work and seem to be good quality to me
> with using vaapi or gl, I can't see the difference and I've tried
> hard to look at the difference.  xv on the other hand has blurry fonts,
> like it has been scaled up with the rest of the image.

I don't know, it probably depends on the hardware/drivers.

> > As for video decoding, you can enable vaapi-powered hardware decoding with 
> > the
> > opengl backend too (manually using the hwdec=vaapi option, since IIRC it's 
> > not
> > auto detected).
> 
> This clearly reduced cpu usage by a factor of 3-4.

Yeah, I forgot to add: hwdec defaults to "no", so even when using vo=vaapi no
hardware decoding is done by default. This is kinda odd, but I guess software
decoding is always the safest default (the hwdec auto-detection is also not very
smart...).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#735332: mpv: Doesn't use vaapi by default

[Alessandro Ghedini]

On mar, gen 14, 2014 at 10:09:02 +0100, Kurt Roeckx wrote:
> Package: mpv
> Version: 0.3.2-1
> 
> Hi,
> 
> It seems mpv tries to use vpdau and tries to load
> libvdpau_nvidia.so by default and fails.
> 
> It then tries to use gl instead, which works perfectly.
> 
> But I have an intel GPU, and I would make sense to use vaapi
> instead.  Using -vo vaapi at least seems to work for me.
> 
> Would it make sense to try to use vaapi by default?

Well, generally speaking VA API is kinda bad for video output (e.g. the OSD is
generally low quality, and in some cases the OSD and subtitles can't even be
drawn at the same time). I've never really used the VA API backend though, but
this seems to be upstream's opinion as well.

As for video decoding, you can enable vaapi-powered hardware decoding with the
opengl backend too (manually using the hwdec=vaapi option, since IIRC it's not
auto detected).

The only useful thing about VA API video output is probably lower power
consumption on laptops, but I don't think that's a good enough reason to enable
it by default instead of, say, the opengl backend.

You can however set it as default in your configuration file so that you don't
have to always pass --vo=vaapi, if that's what you want. Or, idk, you can also
use libvdpau-va-gl, but setting the configuration option is probably a better
idea.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#734796: [mpv] 'libwayland-egl.so.1: cannot open shared object file' when running

[Alessandro Ghedini]

On gio, gen 09, 2014 at 10:35:23 +, Omega Weapon wrote:
> I did the usual 'sudo aptitude install mpv' to get the package, and
> it did pull other packages down.

Well, weird. I guess that list didn't mean what I thought it meant.

Can you please run the following commands and post the result?

 * apt-cache show mpv
 * apt-cache policy mpv
 * dpkg -l mpv
 * apt-cache policy libegl1-mesa-drivers
 * dpkg -l libegl1-mesa-drivers
 * ldd /usr/bin/mpv

From the error you reported, it seems like the libegl1-mesa-drivers package
isn't installed, but it should, since it's a dependency.

Also, there should be a new mpv version available (0.3.2-1) in unstable. Can
you please upgrade to it?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#734796: [mpv] 'libwayland-egl.so.1: cannot open shared object file' when running

[Alessandro Ghedini]

On gio, gen 09, 2014 at 09:34:13 +, Omega Weapon wrote:
> Package: mpv
> Version: 0.3.1-1
> Severity: normal
> 
> Simply running 'mpv' results in the following:
> 
> 
> 
> mpv: error while loading shared libraries: libwayland-egl.so.1:
> cannot open shared object file: No such file or directory
> 
> 

According to the Depends list in your report, you haven't installed any of mpv
dependencies... it's not surprising that it doesn't even start.

Please run:

 # apt-get install -f

and try again.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#733924: mpv: FTBFS: gcc-4.8 missing

[Alessandro Ghedini]

Control: tags -1 pending

On gio, gen 02, 2014 at 10:25:09 +0100, Roland Stigge wrote:
> Package: mpv
> Version: 0.3.1-1
> Severity: wishlist
> Tags: patch
> User: debian-powerpc...@breakpoint.cc
> Usertags: powerpcspe
> 
> [...]
> 
> Adding powerpcspe to the list of arches of the gcc-4.8 build-dep in
> debian/control fixes this issue.

Does this mean that DEB_HOST_ARCH_CPU is the same as powerpc on powerpcspe?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers