libv4lconvert: fix RGB32 conversion
The RGB32 formats start with an alpha byte in memory. So before calling the
v4lconvert_rgb32_to_rgb24 or v4lconvert_rgb24_to_yuv420 function skip that
initial
alpha byte so the src pointer is aligned with the first color component, since
that is what those functions expect.
Signed-off-by: Hans Verkuil
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index cea65aa..e4aa54a 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -1132,6 +1132,7 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
errno = EPIPE;
result = -1;
}
+ src++;
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
v4lconvert_rgb32_to_rgb24(src, dest, width, height, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Siano Rio problems (idVendor=187f, idProduct=0600)
Hi Roberto,
thanks for the reply (I guess I should have replied to the list only
as you are _probably_ subscribed?) I relly appreciate your input!
I guess you are on the right track, indeed I am trying to convince the
card (the usb stick) to do DVB-T Europe. The firmware name I am using
is hardcoded in the sms modules, see attached file "report2.txt", lines
21 and 22. The firmware seems to be at least a correct one for the
chip, loading works (line 38), probably I need to set the correct
device mode when loading the modules (line 43?) I tried to include the
mode in a modprobe.d/siano.conf file as in the smscoreapi.h, where it
has
enum SMS_DEVICE_MODE {
DEVICE_MODE_NONE = -1,
DEVICE_MODE_DVBT = 0,
...
...
which indeed leads to w_scan telling me:
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> TERRESTRIAL "Siano Mobile
Digital MDTV Receiver": good :-)
I now need to find the aerial and see if it works... and if it does
maybe write up a solution somewhere.
(What is also weird is that the firmware is included nowhere, but
referred to in the kernel modules)
Best,
Johannes
On Fri, 18 Jul 2014 21:27:56 -0300
Roberto Alcantara wrote:
> Johannes,
>
> For now Mauro Chehab is the maintainer for Siano tuners. Guys from Siano
> stops to send patch a long time ago.
>
> I’m using SMS2270 (Siano RIO) with ISDB-T. But your log shows "DVB-T Europe”.
>
> Are you trying to tune ISDB-T Terrestrial stations as your firmware file name
> suggest?
>
> Try to enable debug inserting these options inside some file in
> /etc/modprobe.d/
>
> options smsusb debug=3
> options smsmdtv debug=3
>
> and be sure your firmware is loaded.
>
> regards,
> - Roberto
>
>
> Em 16/07/2014, à(s) 09:14, Johannes Werner
> escreveu:
>
> > Dear all,
> >
> > I hope this is the right place to ask for help / clarification
> > (linuxtv.org/ suggests it). I saw that Siano does indeed contribute to
> > the media drivers in the kernel (so I hope somebody relevant is reading
> > this). I have some questions about the Siano Rio chip that I could not
> > answer by asking google...
> >
> > First of all, the chip seems to be supported by the kernel (modules
> > load), but the firmware isdbt_rio.inp is not distributed by Ubuntu. I
> > could find a package at
> > http://repo.huayra.conectarigualdad.gob.ar/huayra/pool/non-free/f/firmware-siano-rio/
> > and this contains a file with this name. This is the only place I could
> > find it on the interwebs.
> > Anyway, below is the actual problem (assuming the firmware mentioned
> > above is correct). I hope to get some hints on what I could try. I am
> > not afraid of building kernels, but haven't done so in a while...
> > Should I write a bug report? (where)?
> >
> > Thanks in advance,
> > Jo
> >
> >
> > Description:
> > Changes to the siano driver between 3.11 and 3.13 removed TERRESTRIAL
> > support for Siano Rio chipset from the driver.
> >
> >
> > Report:
> >
> > On my Netbook (Ubuntu 14.04, kernel 3.13) inserting the USB stick
> > results in
> >
> > -- dmesg output --
> > [] usb 1-1: new high-speed USB device number 5 using ehci-pci
> > [] usb 1-1: New USB device found, idVendor=187f,idProduct=0600
> > [] usb 1-1: New USB device strings: Mfr=1,Product=2, SerialNumber=0
> > [] usb 1-1: Product: MDTV Receiver
> > [] usb 1-1: Manufacturer: MDTV Receiver
> > [] DVB: registering new adapter (Siano Rio Digital Receiver)
> > [] usb 1-1: DVB: registering adapter 0 frontend 0 (Siano Mobile Digital
> > MDTV Receiver)...
> > -- end dmesg --
> >
> > and the modules being loaded.
> >
> > -- lsmod output
> > smsdvb 18071 0
> > dvb_core 101206 1 smsdvb
> > smsusb 17531 0
> > smsmdtv48244 2 smsdvb,smsusb
> > rc_core26724 1 smsmdtv
> > -- end lsmod --
> >
> > This looks promising. When trying to scan for station using w_scan
> > however:
> >
> > -- w_scan output --
> > w_scan version 20130331 (compiled for DVB API 5.10)
> > guessing country 'DE', use -c to override
> > using settings for GERMANY
> > DVB aerial
> > DVB-T Europe
> > scan type TERRESTRIAL, channellist 4
> > output format vdr-2.0
> > output charset 'UTF-8', use -C to override
> > Info: using DVB adapter auto detection.
> > /dev/dvb/adapter0/frontend0 -> "Siano Mobile Digital MDTV
> > Receiver" doesnt support TERRESTRIAL -> SEARCH NEXT ONE. main:3228:
> > FATAL: * NO USEABLE TERRESTRIAL CARD FOUND. * Please check
> > wether dvb driver is loaded and verify that no dvb application (i.e.
> > vdr) is running.
> > -- end w_scan --
> >
> > even though this is a DVB-T receiver stick. Trying it on another machine
> > (where I cannot install the firmware) using Ubuntu 12.04.4, kernel 3.11
> > w_scan does indeed scan (but cannot find a signal because the firmware
> > is not loaded), see below. REMARK: even when not loading a firmware the
> > behaviour above (TERRESTRIAL not support
Re: modern software with analog (BT787) overlay support? / XAWTV replacement ?
Hi Moses, On 07/19/2014 02:08 AM, Moses wrote: > Hello, > > I need a replacement for an aging box that is using xawtv to display > CCTV cameras (from a BT878 card) on a X windows display. Xawtv is > capable of hardware overlay directly onto the X display with almost no > CPU usage and pretty much real time, it has worked great for years.. but > now the box needs modern hardware and software. I have attempted to > compile xawtv using more modern versions of linux.. but I think xawtv is > just too old to mess with at this point.. so the question is.. > > Anyone know of any other suitable software that will allow analog video > overlay from BT878 chips? The problem is not xawtv, the problem is that modern gpus no longer support overlays. On the other hand, modern gpus are much faster and should have no problem handling the video bttv delivers. Xawtv still works fine for modern hardware, it just won't be using the overlay capability anymore. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4lconvert: fix RGB32 conversion
Hi,
On 07/19/2014 09:18 AM, Hans Verkuil wrote:
The RGB32 formats start with an alpha byte in memory. So before calling the
v4lconvert_rgb32_to_rgb24 or v4lconvert_rgb24_to_yuv420 function skip that
initial
alpha byte so the src pointer is aligned with the first color component, since
that is what those functions expect.
Signed-off-by: Hans Verkuil
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index cea65aa..e4aa54a 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -1132,6 +1132,7 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
errno = EPIPE;
result = -1;
}
+ src++;
Hmm what about bgr versus rgb, since those are mirrored, maybe the location of
the alpha byte is mirrored to, and we should only do the src++ for one of them ?
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
v4lconvert_rgb32_to_rgb24(src, dest, width, height, 0);
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4lconvert: fix RGB32 conversion
On 07/19/2014 02:37 PM, Hans de Goede wrote:
> Hi,
>
> On 07/19/2014 09:18 AM, Hans Verkuil wrote:
>> The RGB32 formats start with an alpha byte in memory. So before calling the
>> v4lconvert_rgb32_to_rgb24 or v4lconvert_rgb24_to_yuv420 function skip that
>> initial
>> alpha byte so the src pointer is aligned with the first color component,
>> since
>> that is what those functions expect.
>>
>> Signed-off-by: Hans Verkuil
>>
>> diff --git a/lib/libv4lconvert/libv4lconvert.c
>> b/lib/libv4lconvert/libv4lconvert.c
>> index cea65aa..e4aa54a 100644
>> --- a/lib/libv4lconvert/libv4lconvert.c
>> +++ b/lib/libv4lconvert/libv4lconvert.c
>> @@ -1132,6 +1132,7 @@ static int v4lconvert_convert_pixfmt(struct
>> v4lconvert_data *data,
>> errno = EPIPE;
>> result = -1;
>> }
>> +src++;
>
> Hmm what about bgr versus rgb, since those are mirrored, maybe the location of
> the alpha byte is mirrored to, and we should only do the src++ for one of
> them ?
Uh, that's what I do. Only for the RGB32 pixformats does the src have to be
increased by one. The BGR32 pixformats have the alpha at the end, so there is
no need to increment src.
Regards,
Hans
>
>> switch (dest_pix_fmt) {
>> case V4L2_PIX_FMT_RGB24:
>> v4lconvert_rgb32_to_rgb24(src, dest, width, height, 0);
>>
>
> Regards,
>
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
On 07/18/2014 03:28 PM, Rudy Zijlstra wrote: Dears, I have a ddbridge device: 03:00.0 Multimedia controller: Device dd01:0003 Subsystem: Device dd01:0021 Flags: fast devsel, IRQ 17 Memory at f090 (64-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Capabilities: [90] Express Endpoint, MSI 00 Capabilities: [100] Vendor Specific Information: ID= Rev=0 Len=00c Kernel driver in use: DDBridge The kernel recognises as seen in dmesg: [1.811626] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH [1.813996] pci :01:19.0: enabling device ( -> 0002) [1.816033] DDBridge driver detected: Digital Devices PCIe bridge [1.816273] HW 0001000d FW 00010004 But /dev/dvb remains empty, only /dev/ddbridge exists. Any pointers are much appreciated Cheers Rudy Hello Rudy I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 3.13.0-32-generic. Support for this card was not build into the kernel and I had to compile it myself. I had to use media_build_experimental from Mr. Endriss. http://linuxtv.org/hg/~endriss/media_build_experimental Your card should be supported with this version. Regards, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Jul 20 04:00:19 CEST 2014 git branch: test git hash: 0ca1ba2aac5f6b26672099b13040c5b40db93486 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.14-5.slh.5-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16-rc1-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
