Bug#865353: libdvd-pkg: packages show up as obsolete packages, installs -dev and -dbgsym packaegs without need

Package: libdvd-pkg Version: 1.4.0-1-2 Severity: normal Hi. 1) When running libdvd-pkg it installs all built packages automatically: libdvdcss2 libdvdcss-dev libdvdcss2-dbgsym which is already not so nice. 2) These packages show up as local/obsolete packages, which isn't that nice either.

Bug#865349: libdvd-pkg doesn't necessarily really provide libdvdcss2/-dev

Package: libdvd-pkg Version: 1.4.0-1-2 Severity: normal Hi. libdvd-pkg provides the libdvdcss2 and libdvdcss-dev packages. However, this is not really guaranteed, as installation may fail or simply not be performed. Thus it may be a bad idea to actually provide the packages, isn't it?

Bug#865348: libdvd-pkg: perhaps rename to libdvdcss-pkg?

Package: libdvd-pkg Version: 1.4.0-1-2 Severity: wishlist Hi. Well not so important, since it anyway provides libdvdcss2... but wouldn't it make sense to name it libdvdcss-pkg? Cheers, Chris. ___ pkg-multimedia-maintainers mailing list

Bug#865347: libdvd-pkg: use https for the download

Package: libdvd-pkg Version: 1.4.0-1-2 Severity: wishlist Hi. The videolan servers support https, I suggest using this for the download. While this doesn't help with security, it adds privacy for the download process. Of course one needs to add some --ca-certificate= to wget, of course best

Bug#835066: RFP: libhdcd -- HDCD (High Definition Compatible Digital) decoder

Package: wnpp Severity: wishlist * Package name: libhdcd Version : git Upstream Author : Burt P. * URL : https://github.com/bp0/libhdcd * License : BSD Programming Lang: C Description : HDCD (High Definition Compatible Digital)

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

Hey. Andreas, anything new on this? What happened to your proposed patch? Carl: - The command lines are given in the initial mail of this bug. - IIRC a sample link was provided somewhere as well, but if that   doesn't suit you, simply take *any* wav file on earth, split it in   two halfs a a

Bug#815692: mpv: new upstream version

Package: mpv Version: 0.14.0-1 Severity: wishlist Hi. AFAICS, there is a version 0.15 :-) Cheers, Chris. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

On Sat, 2015-12-19 at 21:05 +0100, Andreas Cadhalpun wrote: > Unless you can reproduce this with ffmpeg's test sample (in which > case, please elaborate what the problem is), please send my privately > (a link to) a small sample. Wait a few minutes... smime.p7s Description: S/MIME cryptographic

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

On Sat, 2015-12-19 at 20:59 +0100, Andreas Cadhalpun wrote: > I might be missing what the problem is, but this command seems to > work > just fine with ffmpeg's test sample [1]. > Can you confirm this, or describe more precisely what the problem is? You need two WAV files, which contain

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

On Sat, 2015-12-19 at 20:40 +0100, Petter Reinholdtsen wrote: > As the bs1770gain developer Peter Belkner explain, this issue is > really an issue in ffmpeg and not in bs1770gain.  Because of this, I > reassign it to ffmpeg. Well I think it's still also some kind of a design issue. The problem is

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

On Sat, 2015-12-19 at 20:47 +0100, Andreas Cadhalpun wrote: > Can you provide a sample for reproducing this problem? Providing samples is always a bit problematic for copyrightreasons, especially when providing them publicly. Any CD-DA, which has gapless tracks (e.g. typically live CDs) will do.

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

On Sat, 2015-12-19 at 23:24 +0100, Andreas Cadhalpun wrote: > OK, so the problem is that after remuxing with ffmpeg, there is > a barely audible ... gap ... between the two files, right? Yes > Now I'm a bit skeptical about "LAME adding some special tags". IIRC, the LAME tag isn't actually an ID3

Bug#797963: bs1770gain: support writing Apple SoundCheck tags

On Sat, 2015-12-19 at 23:38 +0100, Andreas Cadhalpun wrote: > So is this a feature request to support iTunes Normalization Settings > [1]? If that's required for bs1770gain, then yes,... it's a feature request :) Apart from that, it may generally make sense for ffmpeg to support these, i.e. when

Bug#805899: lame: suggest lame-doc

Package: lame Version: 3.99.5+repack1-9 Severity: wishlist Hey. Maybe it makes sense that lame suggests lame-doc :) Cheers, Chris. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org

Bug#797965: BS1770GAIN

Peter (=upstream) has asked me off list to check whether: $ ffmpeg -i in.mp3 -acodec copy -y out.mp3 also makes the resulting files having gaps. The back story is that bs1770gain apparently somehow uses ffmpeg. And the answer is yes, after copying the files as above with ffmpeg, they have gaps

Bug#797838: faac: build with mp4v2

One idea perhaps: Could one fulfil the license if the lib was dynamically loaded? I think about something what e.g. gtkpod does (which is, AFAICS als gpl2 and still uses libmp4v2) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature

Bug#797838: faac: build with mp4v2

On Thu, 2015-09-03 at 07:11 +0200, Fabian Greffrath wrote: > this is because libmp4v2 is licensed under the MPL-1.1 whereas faac > is > licensed under the GPL. Since both licenses are incompatible, the > resulting binaries would be unredistributable. Ah... I somehow missed that mp4v2 was MPL

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

Package: bs1770gain Version: 0.4.5-1+b1 Severity: important Tags: upstream Hi. It seems that bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s. For example, when I encode gapless WAV files via e.g.: lame --verbose -q 0 -v -V 3 --noreplaygain --id3v2-utf16

Bug#797838: faac: build with mp4v2

Package: faac Version: 1.28+cvs20150510-1 Severity: wishlist Hey. libmp4v2 seems to be in debian main... is there any reason why this has been disabled for faac? :-( Cheers, Chris. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable')

Bug#795823: blender: Uninstallable in sid

Control: reopen -1 Hey. I doubt this won't be fixed by itself; as said in the bug mentioned by the original reporter, boost 1.55 won't build with GCC5, so you'll have to change the package to use a newer version (e.g. 1.58)... and I don't think this would happen automatically by the transitions.

Bug#738554: libbluray-bdj security issues

On Mon, 2015-05-04 at 07:42 +0200, Fabian Greffrath wrote: It should be handled on the application level. The library's job is to parse and execute that stuff, not user interaction. Well that's just the point.. I think this *is* a user decision. Do you want to execute foreign code? Nothing

Bug#738554: libbluray-bdj security issues

On Sun, 2015-05-03 at 09:16 +0200, Fabian Greffrath wrote: If we had a bug opened against every package which *by principle* could hold a security issue, we'd have a lot. Well as I've said... I guess one doesn't need to have much imagination that one can think that a system like BD-J may be

Bug#738554: libbluray-bdj security issues

Control: reopen -1 Hey Sebastian. On Sun, 2015-05-03 at 01:59 +0200, Sebastian Ramacher wrote: libbluray now implements a Security Manager for BD-J code. From my point of view, the addition of the SM fixes this general complaint. Phew.. I wouldn't think so. That would be the first jailing

Bug#774800: libav: take measurements not to include or automatically download binary blobs

On Wed, 2015-01-07 at 20:17 +0100, Sebastian Ramacher wrote: Do you understand the change you've linked to? As I've said, I've only had a first glance i.e. looking at the commit log, which mentioned that the downloading must take place, but didn't clearly say whether this is automated or not.

Bug#774800: libav: take measurements not to include or automatically download binary blobs

Source: libav Severity: wishlist Tags: security Hi. Apparently upstream has choosen the same stupid way, that Mozilla (see e.g. #769716) did before to include OpenH264. AFAICS on a first glance, this is done via downloading the blob distributed by Cisco, for which no one knows what it really

Bug#774800: libav: take measurements not to include or automatically download binary blobs

On Wed, 2015-01-07 at 20:07 +0100, Sebastian Ramacher wrote: So, no bug here. There's not even an alpha release of libav 12 available yet. Well... first, it was severity=wishlist, thus not necessarily a bug... and 2nd, these changes will likely hit a release or may be introduced via some

Bug#741132: lives: opening a file makes the program crash

Package: lives Version: 2.2.2~ds0-1 Severity: grave Justification: renders package unusable Hi. When opening a video file I get: avformat detected format: mov,mp4,m4a,3gp,3g2,mj2 /usr/lib/lives/lives-exe: symbol lookup error: /usr/lib//lives/plugins/decoders/zzavformat_decoder.so: undefined

Bug#738554: libbluray-bdj security issues

Package: libbluray-bdj Version: 1:0.5.0-2 Severity: normal Hi. AFAIU, BD-J allows BluRays to run some Java code for an extended experience... No even if that was sandboxed... we all know how problematic this is with respect to security and that Java has a really bad record in terms of that.

Bug#726838: mplayer depends upon old libavutil under unstable

Removing mplayer in favour of mplayer2 seems to be quite a bad idea,... as the later seems to be more or less dead upstream, while the former is actively developed. So this is probably a no-go. It should be mentioned btw, that the mplayer and mplayer2 packages from DMO just work fine (and can

Bug#726838: mplayer depends upon old libavutil under unstable

severity 726838 grave stop Raising severity, since the issue makes the package uninstallable and thus unusable. Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list

Bug#719928: blender: stale files after upgrade

reopen 719928 stop Hey Matteo Uhm... On Wed, 2013-08-21 at 09:46 +0200, Matteo F. Vescovi wrote: On upgrade one gets these errors: Unpacking replacement blender ... dpkg: warning: unable to delete old directory '/usr/lib/blender/scripts/presets/framerate': Directory not empty dpkg:

Bug#719928: blender: stale files after upgrade

Package: blender Version: 2.68a-3 Severity: normal Hi. On upgrade one gets these errors: Unpacking replacement blender ... dpkg: warning: unable to delete old directory '/usr/lib/blender/scripts/presets/framerate': Directory not empty dpkg: warning: unable to delete old directory

Bug#578150: closable?

Hi. It seems 0.1.1 has been packaged?! Can we close this? btw: Are you going to incorporate the upstream svn changes? And are there any plans to package python-pycdio ? Cheers, Chris. ___ pkg-multimedia-maintainers mailing list