Re: CEF in Debian?
On Sat, Feb 24, 2018 at 02:06:39PM +0100, Steinar H. Gunderson wrote: > I'm wondering if there's a chance of having CEF (Chromium Embedded Framework) > in Debian. For those who don't know, CEF is a library that enables easy use > of Chromium from other applications, either as a UI or for offscreen > rendering -- my own video mixer Nageru is getting CEF support these days, > which is why I'm interested. Ping :-) I forgot to mention last time, but I assume obs-studio (already in Debian) would also be interested in CEF, for similar reasons. Cc-ing the maintainer list. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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#839941: whishlist ffmpeg
On Tue, Oct 18, 2016 at 03:27:02PM +0200, Jonas Smedegaard wrote: > Copyright laws in most jurisdictions obey the Berne convention, which > requires freedoms to be explicitly stated (and that the classic phrase > "all rights reserved" is obsolete). Stating that it is provided "as is" > does not rxpand to the range of freedoms defined as the Debian Free > Software Guidelines (later adopted as the definition for the Open Source > movement). The DeckLink SDK header files are really DFSG-free; they are under a BSD-style license with explicit grants of the required freedoms. (ftpmasters have also accepted the license as free, as they are embedded in Nageru, which is shipped in Debian.) The full license text reads: /* -LICENSE-START- ** Copyright (c) 2009 Blackmagic Design ** ** Permission is hereby granted, free of charge, to any person or organization ** obtaining a copy of the software and accompanying documentation covered by ** this license (the "Software") to use, reproduce, display, distribute, ** execute, and transmit the Software, and to prepare derivative works of the ** Software, and to permit third-parties to whom the Software is furnished to ** do so, all subject to the following: ** ** The copyright notices in the Software and this entire statement, including ** the above license grant, this restriction and the following disclaimer, ** must be included in all copies of the Software, in whole or in part, and ** all derivative works of the Software, unless such copies or derivative ** works are solely in the form of machine-executable object code generated by ** a source language processor. ** ** THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR ** IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, ** FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT ** SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE ** FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ** ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER ** DEALINGS IN THE SOFTWARE. ** -LICENSE-END- */ /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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#866512: SIGFPE when encoding H.264 video
reassign 866512 nageru tags 866512 + pending thanks On Fri, Jun 30, 2017 at 10:22:49AM +0200, Sebastian Ramacher wrote: >>> 1.8.3-1 just got accepted. Could you please test if the issue persits with >>> that >>> version? If it's still there, we should take this upstream. >> 1.8.3-1 has same issue. > Thanks for checking. I've forwarded the issue upstream. Upstream found out that it's a bug in Nageru, triggered by the fact that 1.8.x now supports VBR rate control. I have a fix in git, which will go into the 1.6.1 release. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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#866512: SIGFPE when encoding H.264 video
On Thu, Jun 29, 2017 at 09:13:36PM +0200, Sebastian Ramacher wrote: > 1.8.3-1 just got accepted. Could you please test if the issue persits with > that > version? If it's still there, we should take this upstream. 1.8.3-1 has same issue. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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#866512: SIGFPE when encoding H.264 video
On Thu, Jun 29, 2017 at 09:13:36PM +0200, Sebastian Ramacher wrote: > 1.8.3-1 just got accepted. Could you please test if the issue persits with > that > version? If it's still there, we should take this upstream. I don't see it on the mirrors yet. Will give it a try when I do. /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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#832095: zita-resampler - debian bug
On Mon, Aug 29, 2016 at 06:58:24PM +, Fons Adriaensen wrote:
> I wil not accept the patch in its current form, but OTOH the
> code is too good to just be ignored, so I will integrate it
> in another way.
>
> For the next release of zita-resampler I will reorganise the
> code a bit, so it will be possible to have separate optimised
> Resampler1,2,4 classes (for 1,2,4 channels respectively) using
> the SSE code, and without too much code duplication. Same for
> Vresampler.
>
> So Steinar, could you provide optimised 1 and 4 chan versions
> as well ? Even better would be if the latter could handle any
> multiple of 4 channels. In all cases you may assume (hlen % 4 == 0).
Hi Fons,
I expanded on the patch; this new version supports 1, 2 and multiples of 4
channels, and it no longer relies on the serial code (when I can't write past
the end, I just write to a temporary buffer and copy out from there).
Of course, you'll need to reorganize to fit the new structure once you have
it, but hopefully, that should be simple.
The code is pretty much straight-up; the multiples-of-4 VResampler
version isn't optimal for 4 nor for multiples-of-4, but it should be a
reasonable compromise between the two. I guess that if multiples-of-4
is the more important case, we should go to storing the coefficients
(like the scalar version does) instead of computing them anew for each
group of four. (Except for hlen <= 32, in which case it probably would
be optimal to keep them in registers, but I'm not writing special code
for that :-) )
I didn't write AVX versions yet because they would need function
multiversioning to be useful, and in the current structure, that would
mean quite a lot of duplicated code. (Unfortunately, you can't multiversion
inlined functions yet.)
I wrote some test code to make sure I didn't mess up. My original test for
this was based on resampling noise and comparing it to a reference rendering,
but this required my entire audio pipeline running, so I made a simpler one
that simply resamples a sine and compares to another sine. It is simplistic,
but catches most kinds of SSE-ification mistakes instantly, so I've included
it in case you find it useful. Consider both the patch and the test file
licensed under GPLv3+ -- let me know if you want some other kind of license.
/* Steinar */
--
Homepage: https://www.sesse.net/
// zita-resampler tests; meant only to verify correctness of
// e.g. SSE optimizations, not as a means of comparing quality
// of different resamplers, or as exhaustive tests.
#include
#include
#include
#include
#include
#include
using namespace std;
constexpr int in_freq = 44100;
constexpr int out_freq = 48000;
constexpr int samples_per_block = 137; // Prime.
vector make_freqs(unsigned num_channels)
{
vector ret;
for (unsigned i = 0; i < num_channels; ++i) {
ret.push_back(440 - i);
}
return ret;
}
void setup_resampler(VResampler *resampler, unsigned in_freq, unsigned out_freq, unsigned num_channels, float rratio)
{
resampler->setup(double(out_freq) / double(in_freq), num_channels, /*hlen=*/32);
resampler->set_rratio(rratio);
}
void setup_resampler(Resampler *resampler, unsigned in_freq, unsigned out_freq, unsigned num_channels, float rratio)
{
resampler->setup(in_freq, out_freq, num_channels, /*hlen=*/32);
assert(rratio == 1.0f);
}
void print_result(VResampler *resampler, unsigned num_channels, float rratio, float max_err_db, float rms_err_db)
{
printf("VResampler test: %u channel(s), rratio=%.2f max error = %+7.2f dB RMS error = %+7.2f dB\n",
num_channels, rratio, max_err_db, rms_err_db);
}
void print_result(Resampler *resampler, unsigned num_channels, float rratio, float max_err_db, float rms_err_db)
{
printf("Resampler test: %u channel(s)max error = %+7.2f dB RMS error = %+7.2f dB\n",
num_channels, max_err_db, rms_err_db);
}
template
void test_resampler(int num_channels, float rratio = 1.0f)
{
vector freqs = make_freqs(num_channels);
T resampler;
setup_resampler(, in_freq, out_freq, num_channels, rratio);
const int initial_delay = resampler.inpsize() / 2 - 1;
vector in_phaser_speeds, out_phaser_speeds;
for (unsigned i = 0; i < num_channels; ++i) {
in_phaser_speeds.push_back(2.0 * M_PI * freqs[i] / in_freq);
out_phaser_speeds.push_back(2.0 * M_PI * freqs[i] / (out_freq * rratio));
}
float max_err = 0.0f, sum_sq_err = 0.0f;
unsigned num_output_samples = 0;
vector in, out;
out.resize(samples_per_block * num_channels * 2); // Plenty.
for (unsigned block = 0; block < 10; ++block) {
in.clear();
for (unsigned i = 0; i < samples_per_block; ++i) {
int sample_num = block * samples_per_block + i;
for (unsigned channel = 0; channel < num_channels; ++channel) {
in.push_back(sin((sample_num - initial_delay) * in_phaser_speeds[channel]));
}
}
resampler.inp_count = in.size() / num_channels;
resampler.inp_data = [0];
resampler.out_count = out.size() / num_channels;
resampler.out_data = [0];
Bug#832095: patch for SSE-optimizing resampling of stereo signals
On Sun, Jul 24, 2016 at 02:24:48PM +0200, Jaromír Mikeš wrote: > as the patch is rather complex and change code quite a lot I would > like to see rather a new upstream release > including your work. Than apply it only in debian. > Or at least upstream approval of this patch. I've made another attempt at reaching Fons, but to no avail. Have you been in contact with him recently? /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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#832095: patch for SSE-optimizing resampling of stereo signals
On Sun, Jul 24, 2016 at 02:24:48PM +0200, Jaromír Mikeš wrote: > as the patch is rather complex and change code quite a lot I would > like to see rather a new upstream release > including your work. Than apply it only in debian. > Or at least upstream approval of this patch. That would be nice, but like I said earlier, upstream stopped replying to my messages at some point (my assumption was that he got busy with other things). /* Steinar */ -- Homepage: https://www.sesse.net/ ___ 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#750199: xbmc: No Video but audio and subtitiles
On Sun, Jul 27, 2014 at 02:01:58PM -0600, Carlos Ramos wrote: I can confirm this problem. The package vdpau-va-driver is installed by default with xbmc now, but the problem is not fixed. Sound and subtitles are good, but video is just black when output is anything ff-*-vdpau, the output ff-h264-vaapi does work fine for most videos but it creates weird screen artifacts for at least one of my older videos. Software rendering works too. I'm seeing this issue as well; vdpau-va-driver is installed, but any H.264 file fails to decode, with only artifacts on the screen. For me, just turning off VAAPI (keeping VDPAU on) solves the problem. This is on a GT218 (NVIDIA ION). It would seem natural that XBMC should prefer the native VDPAU API rather than VDPAU through VAAPI on NVIDIA cards, but I'm not sure how easy this is to detect. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ 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#722188: Optimizations are not properly applied
Source: libdvbcsa Version: 1.1.0-2 Severity: normal Hello, It seems that debian/rules contains: ifeq ($(DEB_HOST_ARCH),amd64) EXTRA_CONFIGURE_ARGS += --enable-mmx --enable-sse2 endif --enable-mmx overrides --enable-sse2, so this means that the package is built without SSE2 optimizations. Furthermore, it means that 32-bit packages are not built with MMX or SSE2 support, despite every single CPU the last ten years (and certainly every CPU anyone would want to decode DVB-CSA on) has supported SSE2. (MMX was added in 1997!) Finally, --enable-altivec should probably be enabled on appropriate CPUs. -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (750, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.0-rc5 (SMP w/16 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
