Bug#667573: x264: 10 bit builds
Am 12.10.2012 04:41, schrieb Reinhard Tartler: That's indeed something that I could do in the Debian package: Install a regular libx264.so in /usr/lib, and a 10bit in /usr/lib/x264-10bit/libx264.so in addition, and document how to use it in some README.Debian file. Not really nice, but I guess better than nothing. How about Debian's alternatives system? I think it is easier to use and more consistent than a LD_LIBRARY_PATH hack. - Fabian ___ 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#644901: Slightly different behavior, title update or new bugreport needed ?
I have a quite similar problem on two different copmputers (a manually assembled PC and a Lenovo X200s laptop). Since the symptoms are slightly different, I don't know if I should file a different bugreport, or if this one should be changed to reflect the more general nature of the bug. The differences are : - The crackling sound generally disappear after a few seconds, and it happens only at the beginning of playback. This problem affects every software based on VLC (freetuxtv when changing channel, Amarok with phonon-backend-vlc at the beginning of a song (but not always), etc etc). - It also happen (with Amaork at least) when manually changing position with the time counter, and sometimes when changing song (either automatically or manually), or 30 seconds or so before the song automatically changes. In the latter case, there is no crackling at the beginning of the next song. - It happens on both of the computers I use : a manually assembled desktop PC (lspci says 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40)) and a Lenovo ThinkPad X200s (00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)), so it must not be limited to ca0106 HDAudio device like the title says. -- Raphaël HALIMI ___ 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#667573: x264: 10 bit builds
Le primidi 21 vendémiaire, an CCXXI, Fabian Greffrath a écrit : How about Debian's alternatives system? I think it is easier to use and more consistent than a LD_LIBRARY_PATH hack. AFAIK, the alternative system requires root privileges to change the selected alternative, whereas LD_LIBRARY_PATH can be changed by any user on a per-encode basis. Several encodes can be started with different LD_LIBRARY_PATH, and therefore different bit depth. The only limitation with that system is that a single process is limited to a single bit depth. Of course, the alternative system could be used on top of that, to allow to configure the default bit depth, when no LD_LIBRARY_PATH is specified. Regards, -- Nicolas George ___ 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#667573: x264: 10 bit builds
On 10/11/12 21:07, Jason Garrett-Glaser wrote: Would dlopen() work to hack around this sort of limitation? I recall seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding by doing this. Jason Certainly a dlopen() approach works adequately for me now. It is just that my approach to generating an installable package is ugly. I had considered two different approaches, 1) Install a parallel build of x264 in a new directory hierarchy and knowing that path, open the .so with dlopen(). 2) Try to modify the configure scripts and makefile to in order to produce libx264-10bit.so that could be placed in the usual install location alongside the 8 bit version. The name of the built libraries could be controlled by a configure option. You would still need a dlopen() based approach in some cases but the location of the library would no need to be specified. I ended up doing 1) simply because it was easier, but I feel that 2) might actually be a better solution, as everything could live in standard locations. Regards, Jonathan. ___ 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#667573: x264: 10 bit builds
On 10/12/12 09:15, Nicolas George wrote: Le primidi 21 vendémiaire, an CCXXI, Fabian Greffrath a écrit : How about Debian's alternatives system? I think it is easier to use and more consistent than a LD_LIBRARY_PATH hack. AFAIK, the alternative system requires root privileges to change the selected alternative, whereas LD_LIBRARY_PATH can be changed by any user on a per-encode basis. Several encodes can be started with different LD_LIBRARY_PATH, and therefore different bit depth. The only limitation with that system is that a single process is limited to a single bit depth. Of course, the alternative system could be used on top of that, to allow to configure the default bit depth, when no LD_LIBRARY_PATH is specified. I agree. There are different cases here, mine was the most complex where I need to decide at runtime if 8 or 10 bit was needed. As others have said this can be achieved by using a suitable arrangement of dlopen() to select the required library. From a debian packaging point of view, the key thing is what is the correct way to package up and install the 10 bit version alongside the 8 bit. From an x264 perspective, is there anything that needs to be done to the build system to support this in a clean way. Regards, Jonathan. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: retitle 444368 to ITP: dvd95 -- DVD9 to DVD5 converter, owner 444368
Processing commands for cont...@bugs.debian.org: retitle 444368 ITP: dvd95 -- DVD9 to DVD5 converter Bug #444368 [wnpp] RFP: dvd95 -- DVD9 to DVD5 converter Changed Bug title to 'ITP: dvd95 -- DVD9 to DVD5 converter' from 'RFP: dvd95 -- DVD9 to DVD5 converter' owner 444368 Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Bug #444368 [wnpp] ITP: dvd95 -- DVD9 to DVD5 converter Owner recorded as Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org. thanks Stopping processing here. Please contact me if you need assistance. -- 444368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444368 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ 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#690300: New upstream release: 0.7.1
Package: dvdauthor Severity: wishlist Hello, some months ago, the upstream author released a new version: http://sourceforge.net/projects/dvdauthor/files/dvdauthor/0.7.1/ A list of changes (as taken from the ChangeLog file) introduced by the new release follows: 0.7.1: 2012 August 20 No longer silently fail to build dvdunauthor if libdvdread is not present; must be explicitly disabled with --disable-dvdunauthor, otherwise configure reports an error Allow format specification at top level of dvdauthor control file mpeg2desc now reports more details about video frames More explanatory XML-parsing errors Could you please update the packaging to such release? If you need sponsoring, please consider to join the Debian Multimedia Maintainers team: http://wiki.debian.org/DebianMultimedia#Get_involved We'd be glad to support you in co-maintaining the packaging and, for sure, sponsoring uploads for you. Thanks in advance for any reply, cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
another collaboration -- libltc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Alessio et al, Are you up for another collaboration? Since today Ardour3 has an optional dependency on https://github.com/x42/libltc Could you look into downstreaming it to debian? NB. the tagged [1] downloads come without debian/ folder. If it makes your job easier I can upload dedicated releases. Should I open a WNPP request? or are you faster with that? Cheers! robin [1] https://github.com/x42/libltc/tags -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQd+thAAoJEKCQvOAs9X8ESHEP/2inVitXGWVAGSWElqKI5nyl Id+fBkdMsnv4NXYnGlCHnuXFzRS59TIuyHYqTdWHnkSl3jfvW5aaupWQK7gbtMH+ mycYIzKTtzbPr5A9Yw1BO99ybcELdI96RRL4KCAgeXUQ5N87y/o5TTjsWcWTwO2F qKTVwDujybpoyooby1jSrdGtZViSdcTyRXwL59mD1vkZUbQIUhOOuF5FlcPKzS2j WbbyFQ4jMmtm5J6K3IkL+F+3OujxCxMu3n4/NMK7/Vk91Ek/VL8FP2USDPLdQiOh xmvlpsESHlu3PqB+lh8ANjVr9PLPIX2oGoKdo7xxy84Z80XvYxuskzNRiJqKqHV2 BK2mbIob1nJRhYav311C76fYsqLjHvWsiJN4parztqtZfAF4HbHowMoOm8QBwGHs rJOTmA87/hKdWY2IBiBWbc2Wcf3+m0FQ2NhFkgFpiPXgO9p6LXNalJq1fXmjgJ/K a+P4woNagV16qA6Pf7Fcs49yDmdsqu/s3HNCnsGIQe99ny/fnCg7D61N4CSldWQE eEAG68JIBJ1VeYTqs21qDInexZOsP6y1nlyCtznQKJBrg15/zanXB2QSLly1q5AY kiKYFadT0YQkeD4Sw/M5f+/CXG4FTnV1XQPcC4+ESZjluLLeP/+F724JfVLWs4zS rJY/M4jQFsIbiKx2zV/u =JU+j -END 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
Re: mjpegtools_2.0.0+debian-1_source+amd64.changes ACCEPTED into unstable, unstable
Am Sonntag, den 07.10.2012, 11:13 -0700 schrieb Reinhard Tartler: Next steps: avidemux and transcode! Well, transcode is already in. ;) And avidemux does at least build and install cleanly with its own ffmpeg copy as of this evening. I have, however, given up to build it against the system libav libraries... - Fabian ___ 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: mjpegtools_2.0.0+debian-1_source+amd64.changes ACCEPTED into unstable, unstable
Well, that's just fine for experimental IMO Am 12.10.2012 18:02 schrieb Fabian Greffrath fab...@greffrath.com: Am Sonntag, den 07.10.2012, 11:13 -0700 schrieb Reinhard Tartler: Next steps: avidemux and transcode! Well, transcode is already in. ;) And avidemux does at least build and install cleanly with its own ffmpeg copy as of this evening. I have, however, given up to build it against the system libav libraries... - Fabian ___ 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: mjpegtools_2.0.0+debian-1_source+amd64.changes ACCEPTED into unstable, unstable
Wow, amazing! Good job guys! On Fri, Oct 12, 2012 at 6:38 PM, Reinhard Tartler siret...@gmail.com wrote: Well, that's just fine for experimental IMO Am 12.10.2012 18:02 schrieb Fabian Greffrath fab...@greffrath.com: Am Sonntag, den 07.10.2012, 11:13 -0700 schrieb Reinhard Tartler: Next steps: avidemux and transcode! Well, transcode is already in. ;) And avidemux does at least build and install cleanly with its own ffmpeg copy as of this evening. I have, however, given up to build it against the system libav libraries... - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres ___ 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#667573: x264: 10 bit builds
On Fri, Oct 12, 2012 at 2:21 AM, Jonathan Rosser jonathan.ros...@rd.bbc.co.uk wrote: Here is my somewhat incomplete attempt at doing just that. It was more involved than I expected. https://github.com/jrosser/x264-10bit-deb Oh I see what you did there. I don't think that's gonna work in debian. TBH, I think we should just install the 10 bit libx264.so binary into the regular libx264-NN package and document it properly in ./usr/share/doc/libx264-NN/README.Debian. On the second thought, we could even install some wrapper into /usr/bin that starts the passed on argument with proper LD_LIBRARY_PATH. In any case, I don't see the point in adding new source or binary packages. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
