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#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#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#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
  http://sources.debian.net/src/mpv/0.9.2-1%2Bffmpeg/common/av_log.c/#L229
  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#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=optimized out) 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#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

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 users

I'm implying that users have been asking for what they need (ffmpeg) for a long
time, and Debian isn't providing it. And no just having packages using ffmpeg
in experimental is IMO not a solution (it's a PITA for both the maintainers and
the users).

 and I do not (or do and don't give a shit)?

Well, do you? You already made clear several times that your main concern is
this concept of long-term maintanability that no one else is apparently
sharing. That by itself implies that you rate what users have asked multiple
times over the years less important

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 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 gh...@debian.org 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

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 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

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

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

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

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#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: 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 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: 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: 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 gh...@debian.org, 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 gh...@debian.org, 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 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#779789: mpv: free(): invalid pointer: 0xedf28020 ***

[Alessandro Ghedini]

On ven, mar 06, 2015 at 03:46:12 +0100, Jakub Wilk wrote:
 * Alessandro Ghedini gh...@debian.org, 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#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#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#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#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 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=path
   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

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

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=diffrev2=138rev1=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 ales...@debian.org wrote:
  On Sat, Oct 11, 2014 at 9:49 PM, Reinhard Tartler siret...@gmail.com 
  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

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#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 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#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

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#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#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#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 dvdimage
 
 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 dvdimage 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#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 dvdimage 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#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 dvdimage 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#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 gh...@debian.org
 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 maril...@deb-multimedia.org
 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#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 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#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#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#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#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 gh...@debian.org (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

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

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 jcris...@debian.org 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: 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#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 jcris...@debian.org 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=x264arch=sparcver=2%3A0.142.2389%2Bgit956c8d8-3stamp=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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;eg;say~~reverse'
From a0bc33f5fa8290f5724252784cabf4f167f18ebf Mon Sep 17 00:00:00 2001
From: Alessandro Ghedini alessan...@ghedini.me
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, {.i64 = 0}, 0, 1, D },
+{icy_metadata_headers, return ICY metadata headers, OFFSET(icy_metadata_headers), AV_OPT_TYPE_STRING, {0}, 0, 0, 0 },
+{icy_metadata_packet, return current ICY metadata packet, OFFSET(icy_metadata_packet), AV_OPT_TYPE_STRING, {0}, 0, 0, 0 },
 {auth_type, HTTP authentication type, OFFSET(auth_state.auth_type), AV_OPT_TYPE_INT, {.i64 = HTTP_AUTH_NONE

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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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 stdio.h

#include libecasoundc/ecasoundc.h

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+;inidehG ordnasselA;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 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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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+;inidehG ordnasselA;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#733632: mpv: FTBFS on mips/mipsel/powerpc/sparc: undefined reference to `__sync_add_and_fetch_8'

[Alessandro Ghedini]

On lun, dic 30, 2013 at 03:22:38 +0100, Aurelien Jarno wrote:
 Package: mpv
 Version: 0.3.0-1
 Severity: serious
 Tags: upstream patch
 Justification: fails to build from source (but built successfully in the past)
 
 mpv fails to build from source on mips/mipsel/powerpc/sparc with the
 following error message:
 
 | [243/243] linking - build/mpv
 | common/msg.c.10.o: In function `mp_msg_update_msglevels':
 | /«PKGBUILDDIR»/build/../common/msg.c:243: undefined reference to 
 `__sync_add_and_fetch_8'
 | collect2: error: ld returned 1 exit status
 | Waf: Leaving directory `/«PKGBUILDDIR»/build'
 | Build failed

Yeah, I'm already working on a patch (which would use __atomic built-ins
directly) with upstream.

 --- mpv-0.3.0/debian/control
 +++ mpv-0.3.0/debian/control
 @@ -45,7 +45,8 @@
   pkg-config,
   python,
   python-docutils,
 - yasm
 + yasm,
 + gcc-4.8

I'd rather build-depends on gcc-4.8 (and use it directly) only where it's
needed ([powerpc, sparc]), since e.g. ia64 (and all the other *64) will work
just fine with the default 4.6.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;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#731542: libglyr1: basically useless lyrics search

[Alessandro Ghedini]

Package: libglyr1
Version: 1.0.1-1
Severity: normal

Hi,

lately the glyr lyrics search has become rather useless, since, more often than
not, it returns stuff like:

 Amazon: search for... The Beatles • Magical Mystery Tour • Your Mother Should 
 Know
 Hype Machine: search for... The Beatles • Your Mother Should Know
 Last.fm: search for... The Beatles • Magical Mystery Tour • Your Mother 
 Should Know
 Pandora: search for... The Beatles • Your Mother Should Know GoEar: Your 
 Mother Should Know YouTube: Your Mother Should Know allmusic: Your Mother 
 Should Know MusicBrainz: Your Mother Should Know

Instead of actual lyrics.

I also tried to use the version from upstream's git and all the problems seem
to have gone away, so it'd be nice if the Debian package either incorporated
upstream patches to fix this or (more easily) simply tracked upstream's git
repository. I guess convincing the upstream author to cut a new release would
work as well.

Cheers

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

Kernel: Linux 3.11-2-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 libglyr1 depends on:
ii  libc6  2.17-97
ii  libcurl3-gnutls7.33.0-1
ii  libglib2.0-0   2.36.4-1
ii  libsqlite3-0   3.8.1-2
ii  multiarch-support  2.17-97

libglyr1 recommends no packages.

libglyr1 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#728032: [mpv] Installs apparently useless mpv.desktop file.

[Alessandro Ghedini]

On Sun, Oct 27, 2013 at 09:15:40PM +0100, Alessandro Ghedini wrote:
 On Sun, Oct 27, 2013 at 07:38:16PM +0100, Bruno Kleinert wrote:
  Package: mpv
  Version: 0.2.1-1
  Severity: normal
  
  --- Please enter the report below this line. ---
  Hi,
  
  the package installs /usr/share/applications/mpv.desktop, which seems
  useless to me. When a user clicks the mpv entry in a start menu, nothing
  happens since mpv without any arguments just spits out some text on
  stdout. In my opinion a user probably expects something to pop up on the
  screen, e.g., to select a movie file to playback with mpv.
 
 If I understand the *.desktop thing correctly, it is also used by the desktop
 environment to decide which application should open a particular type of file,
 and that's a pretty important part IMO.
 
 I don't think that there's a way to make it not show up in menus though, so
 it's an all or nothing thing I'm afraid.

As Sebastian pointed out, there actually is a way to do it, and apparently
mpv.desktop is already doing it (and it seems to generally work). So if you do
see mpv in your menu, it's probably a bug in whatever software manages your
menus (that is, it doesn't respect NoDisplay=true).

So feel free to reassign this bug, or I'll close it.

  PS: [Try-]Exec=mpv is bad, it should be an absolute path pointing to
  binaries, to avoid possibly weird/broken users' $PATH environments.
 
 Right.

This is now tracked by #728149.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;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#728032: [mpv] Installs apparently useless mpv.desktop file.

[Alessandro Ghedini]

On Sun, Oct 27, 2013 at 07:38:16PM +0100, Bruno Kleinert wrote:
 Package: mpv
 Version: 0.2.1-1
 Severity: normal
 
 --- Please enter the report below this line. ---
 Hi,
 
 the package installs /usr/share/applications/mpv.desktop, which seems
 useless to me. When a user clicks the mpv entry in a start menu, nothing
 happens since mpv without any arguments just spits out some text on
 stdout. In my opinion a user probably expects something to pop up on the
 screen, e.g., to select a movie file to playback with mpv.

If I understand the *.desktop thing correctly, it is also used by the desktop
environment to decide which application should open a particular type of file,
and that's a pretty important part IMO.

I don't think that there's a way to make it not show up in menus though, so
it's an all or nothing thing I'm afraid.

 PS: [Try-]Exec=mpv is bad, it should be an absolute path pointing to
 binaries, to avoid possibly weird/broken users' $PATH environments.

Right.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;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#728032: [mpv] Installs apparently useless mpv.desktop file.

[Alessandro Ghedini]

On Sun, Oct 27, 2013 at 10:11:34PM +0100, Sebastian Ramacher wrote:
 On 2013-10-27 21:15:40, Alessandro Ghedini wrote:
  On Sun, Oct 27, 2013 at 07:38:16PM +0100, Bruno Kleinert wrote:
   Package: mpv
   Version: 0.2.1-1
   Severity: normal
   
   --- Please enter the report below this line. ---
   Hi,
   
   the package installs /usr/share/applications/mpv.desktop, which seems
   useless to me. When a user clicks the mpv entry in a start menu, nothing
   happens since mpv without any arguments just spits out some text on
   stdout. In my opinion a user probably expects something to pop up on the
   screen, e.g., to select a movie file to playback with mpv.
  
  If I understand the *.desktop thing correctly, it is also used by the 
  desktop
  environment to decide which application should open a particular type of 
  file,
  and that's a pretty important part IMO.
  
  I don't think that there's a way to make it not show up in menus though, so
  it's an all or nothing thing I'm afraid.
 
 You can use NoDisplay=true if you only want the mime type associations.

Well, mpv.desktop does use NoDisplay=true AFAICT... the plot thickens.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;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#722997: mpv: Upstream changelog is missing

[Alessandro Ghedini]

On Sun, Sep 15, 2013 at 10:59:54AM +0200, Jonas Smedegaard wrote:
 Package: mpv
 Severity: normal
 
 Upstream changelog should be included in the binary package.

The problem being that there is no such thing as an upstream changelog (except
for the git history).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;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#722143: caps: The library Caps does not provide the module Eq anymore

[Alessandro Ghedini]

On Sun, Sep 08, 2013 at 02:17:53PM +0200, Olivier_G wrote:
 Package: caps
 Version: 0.9.16-1
 Severity: important
 
 Dear Maintainer,
 
* What led up to the situation?
 Upgraded from 0.4.2-1 to 0.9.16.
 Now, when starting any media player i get the error message
 Unable to find label Eq in plugin library file /usr/lib/ladspa/caps.so.

The Eq plugin was renamed to Eq10 apparently (see #721355), so whatever it is
that uses that plugin should be updated to use the new name. If you are using
the libasound2-plugin-equal package, it will migrate to testing in a couple of
days with the fix.

It would have been nice if the caps package had a Debian.NEWS entry about this
(at the very least) though, along with all the other renames.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;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: [PATCH mpv 1/3] Fix Vcs-Browser url

[Alessandro Ghedini]

On ven, set 06, 2013 at 11:29:56 +0200, Andreas Boll wrote:
 Signed-off-by: Andreas Boll andreas.boll@gmail.com

Hi,

I imported your patches (except the changelog one) in git, thanks!

Next time it'd probebly be better if you use the Debian BTS instead of sending
the patches to this list though, so that we can more easily track them and we
don't risk to lose them in the list traffic.

Thanks again for your contribution!

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;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