mjpeg-developer — Developers on MJPEG/MPEG tools project

Re: [Mjpeg-developer] Unnecessary check for mmap/trigger in audiolib.c

[Bernhard P. <sha...@ut...>]

Hallo

>> It turned out that audiolib.c, as far as I can tell, doesn't honor the
>> mmap_io,  nor the use_read_write flag, and look for mmap/trigger
>> support even when it  shouldn't. My proposed patch takes care of that,
>> skipping the check when read/write  is requested instead of mmap.
>
> No reaction at all to this patch? Does it look like an appropriate
> solution to the  problem with playing sound through padsp?

I did want to inculde that patch after the 2.0.0 realease.
I will test it in a few day's. I'm currently traveling and have limited
time for testing and so on.

Regards Bernhard

Re: [Mjpeg-developer] Unnecessary check for mmap/trigger in audiolib.c

[Martin S. <sa...@ho...>]

On Sun, 29 May 2011 02:50:21 +0200
Martin Samuelsson <sa...@ho...> wrote:

> Hi, developers!
> 
> Today, I decided to try setting up some tools for a project of mine. It would 
> involve three lavplays in parallel, and require use of the padsp wrapper for 
> the sound, as I don't have OSS on this computer, and only one hardware channel, anyway.
> 
> I was rewarded with a curious message: "Soundcard cant do mmap or trigger"
> 
> Fair enough, the PA OSS emulation can't do mmap, but that's what lavplay's -U flag 
> is for. Still no cake when using that, though; still the message about no mmap 
> support (which I already knew, and tried to avoid...).
> 
> It turned out that audiolib.c, as far as I can tell, doesn't honor the mmap_io, 
> nor the use_read_write flag, and look for mmap/trigger support even when it 
> shouldn't. My proposed patch takes care of that, skipping the check when read/write 
> is requested instead of mmap.

No reaction at all to this patch? Does it look like an appropriate solution to the 
problem with playing sound through padsp?

> This let me play the audio through padsp, but lavplay will often hang
> with the message "Buffer overflow writing audio". I haven't yet tried
> to improve that situation, but I have observed the hang occur in either one of the
> audio_errno = AUDIO_ERR_BOVFL lines.

Some more digging reveal that the hang occur after a failed
lavplay_queue_next_frame() in lavplay_playback_cycle() has invoked audio_shutdown(), 
in audiolib.c:

void audio_shutdown(void)
{
   if(!initialized) return;

   /* show the child we want to exit */

   shmemptr->exit_flag = 1;
#ifdef FORK_NOT_THREAD
   waitpid(pid,0,0);
#else
   pthread_join( capture_thread, NULL );
#endif

   initialized = 0;
}

If I do not waitpid or pthread_join, lavplay exits instead of hanging indefinitely. 
I interpret this as the audio thread (do_audio()) being locked up in some way, 
not able to react to exit_flag, and thus not able to exit, leaving lavplay 
waiting forever for it to exit

Does this seem like a correct conclusion? Getting debug messages out from the 
audio thread is not the easiest thing to do; how would you proceed with 
the debugging of it?

Regards,
/Sam

Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Bernhard P. <sha...@ut...>]

Hallo

>>> No. On Debian squeeze I didn't have to load anything manually. It just
>>> works out of the box.
>> Are the driver for the additional IC's like advc7175, or saa7110 also
>> loaded ?
> Yes. The reason why those aren't loaded on your machine is because the
> autodetection of those depends on the proper initialization of the
> i2c-bus on the zoran card. If that doesn't work, the zoran driver won't
> issue a request to load those drivers.
You are right if the zoran driver (zr36067) is loaded the other modules 
are loaded as well:
...
zr36060                 8673  1
saa7185                 3920  1
saa7115                15063  1
zr36067                76446  0
videocodec              6286  2 zr36060,zr36067
osst                   53092  0
v4l2_common            11391  3 saa7185,saa7115,zr36067
snd_timer              22130  2 snd_seq,snd_pcm
videodev               75998  4 saa7185,saa7115,zr36067,v4l2_common
---END---

> Ok, thanks. After having a closer look on the ic2-algo-bit driver again,
> I think found the culprit (at least I can reproduce it now). I noticed
> that the bus testing that fails on your machine is supposed to be
> disabled by default; At least on my machine it doesn't even try it in
> the first place, and if I explicitly enable it, I get the same error you
> reported ;-)
Having the same problem as someone else helps a lot in fixing them :)

> So, could you try to execute "rgrep bit_test /etc/ 2>/dev/null" and see
> if bit_test is set to 1 in one of your module configuration files? Does
> it work if you set it to zero instead, or reload the i2c-algo-bit module
> with bit_test=0 as parameter? Note that you may have to rebuild your
> initramfs for your kernel after changing the module configuration.
You are a hero :)

# grep bit_test -r /etc/ 2>/dev/null
/etc/modprobe.d/50-tv.conf:options i2c-algo-bit bit_test=1

> I also found some recommendation in the Linux documentation to enable
> the bit_test for bttv cards, in case the driver needs a very long time
> to start. Maybe you enabled that when testing with a bttv, or the
> default on the SuSE distributions is just different for some reason.
I did not set that option. I didn't know that is was set anywhere. (I 
learn every day something interesting ;) )

I did set the bit_test to 0 and did generate the kernel initrd new. And 
that seems to do the trick. I did still specify on the start paramter 
i2c_debug=3 and bit_test=0, just to make things sure.

>>> Additionally, you should try to get more debug output for both the
>>> i2c_algo_bit and zr36067 modules. You can try to remove both modules and
>>> load them again with modprobe and the parameters i2c_debug=3 for
>>> i2c_algo_bit and debug=5 for zr36067.
>> Is the proper command for loading the module with that option:
>> modprobe -v zr36067 zr36067_debug=5 ?
> I guess it's supposed to be just debug=5 instead of zr36067_debug=5.
> However, it probably wouldn't really have had any effect anyway because
> the zoran module already fails in quite an early initialization phase.
You are right about name of the option. I did not specify the debug=5 
option when I started the kernel for testing.

Please check the log file it is again the output from dmesg.
I was not able to check if xawtv or lavrec works now. That has to wait 
for a week. Till I'm home again, and infront a computer that has a zoran 
based card built in.

I hope that I can test your new lavrec version than too, but that might 
take a few days longer.

>> Do you think that it would help disabling the onboard graphic card and
>> installing a extra graphic card ? I have a ATI Radeon HD2600 card around
>> from my MAC I could use for testing.
> No, I don't think it has any relationship with your graphics card.
Again right. Without waiting for an answer I did test the ATI Card. And 
it did not change anything.

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

Re: [Mjpeg-developer] [Mjpeg-users] mjpegtools 2.0.0 RC1

[Scott C. F. <sf...@co...>]

On Sun, 2011-05-15 at 08:12 +0200, Bernhard Praschinger wrote:
> Hallo
> 
> I know some things take really long here.
> 
> I did update the ChangeLog and BUGS file with things I knew. Please 
> check the changes. I'd guess that I missed some things. If you, or 
> anybody else tell me I will add those things.
> 
> If you want to fix a problem mentioned in the BUGS, please send a mail 
> or post in in the patches tracker.

Thanks Berni,
scott

Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Klaus S. <Kla...@as...>]

Hi Bernhard,

Bernhard Praschinger wrote:
> >> Do you need to load any modules manual ?
> > No. On Debian squeeze I didn't have to load anything manually. It just
> > works out of the box.
> Are the driver for the additional IC's like advc7175, or saa7110 also 
> loaded ?

Yes. The reason why those aren't loaded on your machine is because the
autodetection of those depends on the proper initialization of the
i2c-bus on the zoran card. If that doesn't work, the zoran driver won't
issue a request to load those drivers.

> > You could try to add a short delay immediately after the call to
> > zr36057_restart in zoran_card.c (around line 1353) by inserting the
> > following line:
> > mdelay(1);
> I did and recompiled it but it did not change anything.
> 
> I did load the kernel with the option i2c_debug=3
> And I have attached the log from dmesg.

Ok, thanks. After having a closer look on the ic2-algo-bit driver again,
I think found the culprit (at least I can reproduce it now). I noticed
that the bus testing that fails on your machine is supposed to be
disabled by default; At least on my machine it doesn't even try it in
the first place, and if I explicitly enable it, I get the same error you
reported ;-)

So, could you try to execute "rgrep bit_test /etc/ 2>/dev/null" and see
if bit_test is set to 1 in one of your module configuration files? Does
it work if you set it to zero instead, or reload the i2c-algo-bit module
with bit_test=0 as parameter? Note that you may have to rebuild your
initramfs for your kernel after changing the module configuration.

I also found some recommendation in the Linux documentation to enable
the bit_test for bttv cards, in case the driver needs a very long time
to start. Maybe you enabled that when testing with a bttv, or the
default on the SuSE distributions is just different for some reason.

> > Additionally, you should try to get more debug output for both the
> > i2c_algo_bit and zr36067 modules. You can try to remove both modules and
> > load them again with modprobe and the parameters i2c_debug=3 for
> > i2c_algo_bit and debug=5 for zr36067.
> Is the proper command for loading the module with that option:
> modprobe -v zr36067 zr36067_debug=5 ?

I guess it's supposed to be just debug=5 instead of zr36067_debug=5.
However, it probably wouldn't really have had any effect anyway because
the zoran module already fails in quite an early initialization phase.

> Do you think that it would help disabling the onboard graphic card and 
> installing a extra graphic card ? I have a ATI Radeon HD2600 card around 
> from my MAC I could use for testing.

No, I don't think it has any relationship with your graphics card. 

Regards,
Klaus

Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Bernhard P. <sha...@ut...>]

Hallo

> Bernhard Praschinger wrote:
>>>> But I have problems getting the driver working. I do not get a
>>>> /dev/video0 device. The DC-30 is detected in some way but refuses to
>>>> work. I hope that you can give me a hint how to accomplish that.
>> Do you need to load any modules manual ?
> No. On Debian squeeze I didn't have to load anything manually. It just
> works out of the box.
Are the driver for the additional IC's like advc7175, or saa7110 also 
loaded ?

>> On my machine there is only the zr36067 loaded an no other modules
>> needed for the cards.
>
> I think this is because the i2c setup is done very early in the
> initialization process. If I remember correctly, the other chips on the
> board aren't directly connected to the PCI bus, but they can be accessed
> via the i2c bus on the zr360xx. The i2c on the card is exposed by
> special registers in PCI configuration space that allow the host PC to
> send and receive commands on that bus. For some reason the commands put
> into to those configuration registers don't seem to do what they're
> supposed to do on your machine. The error message you see actually comes
> from the i2c_algo_bit module and not from the zoran driver itself.
I did recompile the kernel with the options
I2C Core debugging messages
I2C Algorithm debugging messages
I2C Bus debugging messages

Now dmesg gives me ever second a message like that:
[  747.330036] i2c i2c-0: NAK from device addr 0x50 msg #0
[  747.330106] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
[  747.330111] i2c i2c-1: master_xfer[1] R, addr=0x50, len=1
[  747.331912] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
[  747.331917] i2c i2c-1: master_xfer[1] R, addr=0x50, len=1
[  747.333689] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
[  747.333694] i2c i2c-1: master_xfer[1] R, addr=0x50, len=128
[  757.408035] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1
[  757.408044] i2c i2c-0: master_xfer[1] R, addr=0x50, len=1

> In some cases the access to that bus is somewhat time critical and the
> driver immediately performed a reset before trying to test the i2c bus
> access. Maybe the capture card just hadn't enough time to settle, so
> that there are unexpected disruptions from the reset procedure while the
> i2c_algo_bit module tries to test if the bus functions properly.

> You could try to add a short delay immediately after the call to
> zr36057_restart in zoran_card.c (around line 1353) by inserting the
> following line:
> mdelay(1);
I did and recompiled it but it did not change anything.

I did load the kernel with the option i2c_debug=3
And I have attached the log from dmesg.

> Additionally, you should try to get more debug output for both the
> i2c_algo_bit and zr36067 modules. You can try to remove both modules and
> load them again with modprobe and the parameters i2c_debug=3 for
> i2c_algo_bit and debug=5 for zr36067.
Is the proper command for loading the module with that option:
modprobe -v zr36067 zr36067_debug=5 ?

4655.837807] Zoran MJPEG board driver version 0.10.0
4655.838071] MJPEG[0]: Zoran ZR36067 (rev 2), irq: 22, memory: 0xfdbfe000
4655.838079] MJPEG[0]: Subsystem vendor=0x13ca id=0x4231
4655.838084] MJPEG[0]: zoran_probe() - card Buz detected
4655.840419] Buz[0]: Initializing i2c bus...
4655.840437] Buz[0]: SCL unexpected low while pulling SDA low!
4655.840465] Buz[0]: zoran_probe - can't initialize i2c bus

Do you think that it would help disabling the onboard graphic card and 
installing a extra graphic card ? I have a ATI Radeon HD2600 card around 
from my MAC I could use for testing.

>> I didn't test it with a 2.6.32 kernel, I can try to do that tomorrow. I
>> did upgrade my system to opensuse 10.4 x64 2-3 months ago. I haven't
>> done any test with a zoran based card since that upgrade.
> But you already had the card working on that hardware configuration
> before, right?
That is right. But I did use before a 32Bit Linux.

>> I did check with the original 2.6.37 Kernel used by Suse there the zoran
>> card isn't detected, and there is also no /dev/video0 device.
> Ok, so at least it's certainly not a problem introduced by my patch.
Your last patch didn't introduce a problem. Why should the new one 
introduce problems ? ;)

>> I have the same problem with the Buz.
>> I have attached the output from dmesg. I hope that it tells you more
>> than it tells me. You can see in the log that the onboard radeon card
>> has also a problem with i2c.
>> Could that be the cause of the problem ?
>> What I don't understand is that the module i2c_piix4 is loaded. I have
>> also attached the output of lsmod.
> The i2c_piix4 seems to be used as a system management bus on your
> motherboard, which is something entirely different. Also the i2c bus on
> your graphics card is completely separated from the bus on the zoran
> chip. The drivers usually share some generic infrastructure for
> enumerating available buses and attached devices, but for the zoran
> cards the real work is done by the i2c_algo_bit module only.
Ok, I don't get it why i2c causes the problems.

> With the attached version of liblavrec I already managed to capture
> hardware-encoded MJPEG video, using the V4L2 interface only, on 2.6.38
> with my patch and 64-bits. It's still a lot of work, because I had to
> disable signal auto-detection as well as the whole software encoding and
> it doesn't properly support any decimation.
I'd really like to test it.
I think that software encoding did only work if you did record from a 
bttv based card. So that should not matter that much.



auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

[Mjpeg-developer] Unnecessary check for mmap/trigger in audiolib.c

[Martin S. <sa...@ho...>]

Hi, developers!

Today, I decided to try setting up some tools for a project of mine. It would involve three lavplays in parallel, and require use of the padsp wrapper for the sound, as I don't have OSS on this computer, and only one hardware channel, anyway.

I was rewarded with a curious message: "Soundcard cant do mmap or trigger"

Fair enough, the PA OSS emulation can't do mmap, but that's what lavplay's -U flag is for. Still no cake when using that, though; still the message about no mmap support (which I already knew, and tried to avoid...).

It turned out that audiolib.c, as far as I can tell, doesn't honor the mmap_io, nor the use_read_write flag, and look for mmap/trigger support even when it shouldn't. My proposed patch takes care of that, skipping the check when read/write is requested instead of mmap.

This let me play the audio through padsp, but lavplay will often hang
with the message "Buffer overflow writing audio". I haven't yet tried
to improve that situation, but I have observed the hang occur in either one of the
audio_errno = AUDIO_ERR_BOVFL lines.

Regards,
/Sam

Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Klaus S. <Kla...@as...>]

Hi Bernhard,

Bernhard Praschinger wrote:
> >> But I have problems getting the driver working. I do not get a
> >> /dev/video0 device. The DC-30 is detected in some way but refuses to
> >> work. I hope that you can give me a hint how to accomplish that.
> Do you need to load any modules manual ?

No. On Debian squeeze I didn't have to load anything manually. It just
works out of the box.

> On my machine there is only the zr36067 loaded an no other modules 
> needed for the cards.

I think this is because the i2c setup is done very early in the
initialization process. If I remember correctly, the other chips on the
board aren't directly connected to the PCI bus, but they can be accessed
via the i2c bus on the zr360xx. The i2c on the card is exposed by
special registers in PCI configuration space that allow the host PC to
send and receive commands on that bus. For some reason the commands put
into to those configuration registers don't seem to do what they're
supposed to do on your machine. The error message you see actually comes
from the i2c_algo_bit module and not from the zoran driver itself.

In some cases the access to that bus is somewhat time critical and the
driver immediately performed a reset before trying to test the i2c bus
access. Maybe the capture card just hadn't enough time to settle, so
that there are unexpected disruptions from the reset procedure while the
i2c_algo_bit module tries to test if the bus functions properly.

You could try to add a short delay immediately after the call to
zr36057_restart in zoran_card.c (around line 1353) by inserting the
following line:

mdelay(1);

Additionally, you should try to get more debug output for both the
i2c_algo_bit and zr36067 modules. You can try to remove both modules and
load them again with modprobe and the parameters i2c_debug=3 for
i2c_algo_bit and debug=5 for zr36067.

> I didn't test it with a 2.6.32 kernel, I can try to do that tomorrow. I 
> did upgrade my system to opensuse 10.4 x64 2-3 months ago. I haven't 
> done any test with a zoran based card since that upgrade.

But you already had the card working on that hardware configuration
before, right?

> I did check with the original 2.6.37 Kernel used by Suse there the zoran 
> card isn't detected, and there is also no /dev/video0 device.

Ok, so at least it's certainly not a problem introduced by my patch.

> I have the same problem with the Buz.
> I have attached the output from dmesg. I hope that it tells you more 
> than it tells me. You can see in the log that the onboard radeon card 
> has also a problem with i2c.
> Could that be the cause of the problem ?
> What I don't understand is that the module i2c_piix4 is loaded. I have 
> also attached the output of lsmod.

The i2c_piix4 seems to be used as a system management bus on your
motherboard, which is something entirely different. Also the i2c bus on
your graphics card is completely separated from the bus on the zoran
chip. The drivers usually share some generic infrastructure for
enumerating available buses and attached devices, but for the zoran
cards the real work is done by the i2c_algo_bit module only.

> >> I don't know of any other tool to record from a zoran based car. A patch
> >> for lavrec would be really great.
> > Ok, I'm currently hacking something together just to make it capture
> > with a mostly fixed set of parameters. Trying to translate the existing
> > lavrec data structures to V4L2 syscalls isn't that easy, because there
> > is no one-to-one correspondence for the whole decimation settings and
> > many parameters for input and norm selection also look quite different.
> Maybe Ronald can give you any hints for that task.

With the attached version of liblavrec I already managed to capture
hardware-encoded MJPEG video, using the V4L2 interface only, on 2.6.38
with my patch and 64-bits. It's still a lot of work, because I had to
disable signal auto-detection as well as the whole software encoding and
it doesn't properly support any decimation.

It seems that there is also a problem with signal detection in the
driver with the V4L2 interface, because it always had the NO SIGNAL flag
set, no matter if the attached source actually produced any output or
not. The color detection seemed to work though, because the bit toggled
sometimes when I used an entirely grey picture for testing.

Regards,
Klaus

Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Bernhard P. <sha...@ut...>]

Hallo

>>> finally I managed to come up with a patch for 64-bit support current
>>> Linux kernel versions.
>> So is that more or less a updated patch for the problem you fixed 2
>> years ago ? At that time for kernel 2.6.24
> Yes, that's basically the same, but adapted to work together with the
> restructuring of the buffer management in recent kernels and contains
> some minor improvements.
Thanks for the explanation.

>> But I have problems getting the driver working. I do not get a
>> /dev/video0 device. The DC-30 is detected in some way but refuses to
>> work. I hope that you can give me a hint how to accomplish that.
>>
>> [ 2650.928071] MJPEG[0]: Zoran ZR36067 (rev 2), irq: 21, memory: 0xfdcfe000
>> [ 2650.928079] MJPEG[0]: Subsystem vendor=0x1031 id=0xd801
>> [ 2650.930238] DC30plus[0]: SCL unexpected low while pulling SDA low!
>> [ 2650.930267] DC30plus[0]: zoran_probe - can't initialize i2c bus
>
> Hmm, that's interesting. Did you also try without the patch, or with a
> 2.6.32 kernel? At least the hardware detection should work, no matter
> which kernel or whether my patch was applied or not. With my DC10+ I
Do you need to load any modules manual ?
On my machine there is only the zr36067 loaded an no other modules 
needed for the cards.

> think I always got at least a proper device entry. Only if I tried to
> watch the video on screen or actually tried to capture some video, the
> driver and/or machine would crash. So either the DC30 tries to allocate
> some additional buffers with the wrong APIs or, as indicated by the
> error message, something else with the I2C interface is broken.
I didn't test it with a 2.6.32 kernel, I can try to do that tomorrow. I 
did upgrade my system to opensuse 10.4 x64 2-3 months ago. I haven't 
done any test with a zoran based card since that upgrade.

I did check with the original 2.6.37 Kernel used by Suse there the zoran 
card isn't detected, and there is also no /dev/video0 device.

>> Do you have any idea what kind of problem I run into ?
>> I can also put the Iomega Buz into the computer and to a test run.
> That would certainly help to narrow down the problem in case it's
> something specific to the DC30 chipset drivers.
I have the same problem with the Buz.
I have attached the output from dmesg. I hope that it tells you more 
than it tells me. You can see in the log that the onboard radeon card 
has also a problem with i2c.
Could that be the cause of the problem ?

What I don't understand is that the module i2c_piix4 is loaded. I have 
also attached the output of lsmod.

>> I don't know of any other tool to record from a zoran based car. A patch
>> for lavrec would be really great.
> Ok, I'm currently hacking something together just to make it capture
> with a mostly fixed set of parameters. Trying to translate the existing
> lavrec data structures to V4L2 syscalls isn't that easy, because there
> is no one-to-one correspondence for the whole decimation settings and
> many parameters for input and norm selection also look quite different.
Maybe Ronald can give you any hints for that task.

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Klaus S. <Kla...@as...>]

Hi Bernhard,

Bernhard Praschinger wrote:
> Klaus Stengel wrote:
> > finally I managed to come up with a patch for 64-bit support current
> > Linux kernel versions. 
> So is that more or less a updated patch for the problem you fixed 2 
> years ago ? At that time for kernel 2.6.24

Yes, that's basically the same, but adapted to work together with the
restructuring of the buffer management in recent kernels and contains
some minor improvements.

> > The attached patches enable 64-bit support and fix the issue for kernels
> > 2.6.32 and 2.6.38+ (tested on Debian Linux but should apply for most
> I did download the 2.6.38.7 linux kernel from kernel.org and built it.
> The patch did apply without any problems.
> 
> But I have problems getting the driver working. I do not get a 
> /dev/video0 device. The DC-30 is detected in some way but refuses to 
> work. I hope that you can give me a hint how to accomplish that.
>
> [ 2650.928071] MJPEG[0]: Zoran ZR36067 (rev 2), irq: 21, memory: 0xfdcfe000
> [ 2650.928079] MJPEG[0]: Subsystem vendor=0x1031 id=0xd801
> [ 2650.930238] DC30plus[0]: SCL unexpected low while pulling SDA low!
> [ 2650.930267] DC30plus[0]: zoran_probe - can't initialize i2c bus

Hmm, that's interesting. Did you also try without the patch, or with a
2.6.32 kernel? At least the hardware detection should work, no matter
which kernel or whether my patch was applied or not. With my DC10+ I
think I always got at least a proper device entry. Only if I tried to
watch the video on screen or actually tried to capture some video, the
driver and/or machine would crash. So either the DC30 tries to allocate
some additional buffers with the wrong APIs or, as indicated by the
error message, something else with the I2C interface is broken.

> Do you have any idea what kind of problem I run into ?
> I can also put the Iomega Buz into the computer and to a test run.

That would certainly help to narrow down the problem in case it's
something specific to the DC30 chipset drivers.

> I don't know of any other tool to record from a zoran based car. A patch 
> for lavrec would be really great.

Ok, I'm currently hacking something together just to make it capture
with a mostly fixed set of parameters. Trying to translate the existing
lavrec data structures to V4L2 syscalls isn't that easy, because there
is no one-to-one correspondence for the whole decimation settings and
many parameters for input and norm selection also look quite different.

Regards,
Klaus

Re: [Mjpeg-developer] Zoran Linux driver 64-bit support

[Bernhard P. <sha...@ut...>]

Hallo

> finally I managed to come up with a patch for 64-bit support current
> Linux kernel versions. In order to implement the PCI bus APIs I had to
> rewrite the most of the JPEG buffer allocation. While doing that I
> noticed a potential security issue in the handler for the mmap syscall,
> which might allow an attacker with access to the v4l device to get
> access to protected memory areas.
So is that more or less a updated patch for the problem you fixed 2 
years ago ? At that time for kernel 2.6.24

> The attached patches enable 64-bit support and fix the issue for kernels
> 2.6.32 and 2.6.38+ (tested on Debian Linux but should apply for most
I did download the 2.6.38.7 linux kernel from kernel.org and built it.
The patch did apply without any problems.

But I have problems getting the driver working. I do not get a 
/dev/video0 device. The DC-30 is detected in some way but refuses to 
work. I hope that you can give me a hint how to accomplish that.

I did load the modules manually:
zr36067                76446  0
zr36050                 8055  0
zr36016                 4775  0
videocodec              6286  3 zr36067,zr36050,zr36016
adv7175                 4573  0
vpx3220                 7271  0
v4l2_common            11391  3 zr36067,adv7175,vpx3220
videodev               75998  4 zr36067,adv7175,vpx3220,v4l2_common
i2c_dev                 7823  0
i2c_algo_bit            5641  2 zr36067,radeon

But when loading the zr36067 modules I find that in /var/log/messages
[ 2576.120748] Linux video capture interface: v2.00
[ 2635.218934] Linux video codec intermediate layer: v0.2
[ 2650.926927] Zoran MJPEG board driver version 0.10.0
[ 2650.928071] MJPEG[0]: Zoran ZR36067 (rev 2), irq: 21, memory: 0xfdcfe000
[ 2650.928079] MJPEG[0]: Subsystem vendor=0x1031 id=0xd801
[ 2650.930238] DC30plus[0]: SCL unexpected low while pulling SDA low!
[ 2650.930267] DC30plus[0]: zoran_probe - can't initialize i2c bus

xawtv fail afterwards as expected:
 > xawtv
This is xawtv-3.95, running on Linux/x86_64 (2.6.38.7-0.5-desktop)
xinerama 0: 1600x1200+0+0
can't open /dev/video0: No such file or directory
v4l-conf had some trouble, trying to continue anyway
v4l2: open /dev/video0: No such file or directory
v4l: open /dev/video0: No such file or directory
no video grabber device available


Do you have any idea what kind of problem I run into ?
I can also put the Iomega Buz into the computer and to a test run.

> other kernel flavors as well). We should try to get that in mainline if
> possible.
That is right.

> The next task is now to update the lavrec tool to use the V4L2
> interface for setting up the card, because I couldn't test on 2.6.38
> yet. Or does anyone know an alternative tool to capture the JPEG frames
> on Linux?
I don't know of any other tool to record from a zoran based car. A patch 
for lavrec would be really great.

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

[Mjpeg-developer] mjpegtools 2.0.0 released

[Bernhard P. <sha...@ut...>]

Hallo

I have put the mjpegtools 2.0.0 Release online. You can donwlod it in 
the file area on Sourceforge:
http://sourceforge.net/projects/mjpeg/files/mjpegtools/

Since the release of the RC-1 a lot of small patches and fixes were 
included.

I did just put the compressed source RPM online, and the tar.gz from 
CVS. Most people download only the tar.gz file.

If someone wants to provide compiled binary for a specific distribution 
or architecture please drop me a note I will put them online.

I will provide binary for opensuse 11.4 i586 the next few days.

If you have feedback please write it. If you still find bugs, please 
tell them too, patched are also appreciated :)

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

[Mjpeg-developer] Zoran Linux driver 64-bit support

[Klaus S. <Kla...@as...>]

Hi,

finally I managed to come up with a patch for 64-bit support current
Linux kernel versions. In order to implement the PCI bus APIs I had to
rewrite the most of the JPEG buffer allocation. While doing that I
noticed a potential security issue in the handler for the mmap syscall,
which might allow an attacker with access to the v4l device to get
access to protected memory areas.

The attached patches enable 64-bit support and fix the issue for kernels
2.6.32 and 2.6.38+ (tested on Debian Linux but should apply for most
other kernel flavors as well). We should try to get that in mainline if
possible. The next task is now to update the lavrec tool to use the V4L2
interface for setting up the card, because I couldn't test on 2.6.38
yet. Or does anyone know an alternative tool to capture the JPEG frames
on Linux?

Regards,
Klaus

Re: [Mjpeg-developer] [Mjpeg-users] mjpegtools 2.0.0 RC1

[Bernhard P. <sha...@ut...>]

Hallo

I know some things take really long here.

[...]
> Hi Berni,
> I was trying to find a summation of the changes that have been made, but
> had a bit of difficulty finding a README.  Can you give us a summary of
> what is different in the new version?
I did update the ChangeLog and BUGS file with things I knew. Please 
check the changes. I'd guess that I missed some things. If you, or 
anybody else tell me I will add those things.

If you want to fix a problem mentioned in the BUGS, please send a mail 
or post in in the patches tracker.

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

Re: [Mjpeg-developer] v1.9.0 compilation fails due to X11 dependency on Linux with V4L

[Bernhard P. <sha...@ut...>]

Hallo

> I do still have a (virtual machine) Gentoo installation that doesn't
> include X11 and I've downloaded the current CVS version and built it
> successfully. In particular, the png2yuv tool builds and links without
> error, whereas it didn't before.
Thanks for testing. I haven't seen a X-less Linux machine for a very 
long time.

> So, it looks like the effort has paid off. There must be some kind of
> competition for blasts from the past bugs such as this that we can enter
> this commit for...
You can still get the bounty for a 3 year open bug.

> I've added a pointer to this update to the Gentoo bug I raised (if
> anyone's still looking at it...)
There is another Gentoo bug that led me to the problem, in combination 
with the entry in the bug tracker and some spare time here, I can try to 
fix the problem. And succeed from time to time.

> Thanks again,
> Stuart
Thanks for waiting so long of a solution,
auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

Re: [Mjpeg-developer] v1.9.0 compilation fails due to X11 dependency on Linux with V4L

[Bernhard P. <sha...@ut...>]

Hallo

Martin Samuelsson wrote:
> On Tue, 03 May 2011 19:59:37 +0200 Bernhard
> Praschinger<sha...@ut...>  wrote:
>
>> Hallo
>>
>> Martin Samuelsson wrote:
>>> On Mon, 23 Feb 2009 20:28:40 +0100
>> Ok, I hope you don't break down laughing when you read the answer
>> from a mail you sent to me more than 2 years ago. ;)
> Ah, this old gem! I applaud your hard work stomping it to death!
Well there is one compile problem that will turn 3 year open next 
monday. Anybody wants to fix that one ? ;)

> Unfortunately, I don't have any X-less machine nearby to test the
> patch, and a waiting-to-happen expansion of the family practically
> guarantees that I won't be able to test it in the foreseeable
> future.
That sound like a good reason to spend time not infront the computer :)

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

Re: [Mjpeg-developer] v1.9.0 compilation fails due to X11 dependency on Linux with V4L

[Stuart H. <st...@hi...>]

On Wed, 2011-05-04 at 22:43 +0200, Martin Samuelsson wrote:
> On Tue, 03 May 2011 19:59:37 +0200
> Bernhard Praschinger <sha...@ut...> wrote:
> 
> > Hallo
> > 
> > Martin Samuelsson wrote:
> > > On Mon, 23 Feb 2009 20:28:40 +0100
> > Ok, I hope you don't break down laughing when you read the answer from a
> > mail you sent to me more than 2 years ago. ;)
> 
> Ah, this old gem! I applaud your hard work stomping it to death!
> 
> Unfortunately, I don't have any X-less machine nearby to test the patch, and a waiting-to-happen expansion of the family practically guarantees that I won't be able to test it in the foreseeable future.
> 
> Regards,
> /Martin
> 

I do still have a (virtual machine) Gentoo installation that doesn't
include X11 and I've downloaded the current CVS version and built it
successfully. In particular, the png2yuv tool builds and links without
error, whereas it didn't before.

So, it looks like the effort has paid off. There must be some kind of
competition for blasts from the past bugs such as this that we can enter
this commit for...

I've added a pointer to this update to the Gentoo bug I raised (if
anyone's still looking at it...)

Thanks again,
Stuart

> > 
> > I try to make my open problems list smaller. I really want to make a 
> > release in may this year.
> > 
> > >> Stuart Hickinbottom wrote:
> > >>> I'm reporting this in response to a Gentoo Linux bug I've filed
> > >>> (http://bugs.gentoo.org/show_bug.cgi?id=217427#c11).
> > >> [...]
> > >>> On a headless (no X11) Linux server that has V4L, the compilation
> > >>> of 1.9.0 fails as follows:
> > >> I haven't seen a X11 less Linux for quite some time. All my
> > >> machines (regular an virtual have X11)
> > > They do exist. The last time I encountered this, I had the disk space
> > > to spare for a set of X devel files, but at other times, I've removed
> > > the offending flag manually.
> > I have now added a fix to the CVS that seems to work for me. Things 
> > still compile on my computer where X11 is installed. I hope one of you 
> > (and any other person is invited too !) has still a machine without X11 
> > installed and trys to compile the mjpegtools (latest CVS, because I 
> > committed the patch just a few minutes ago.
> > 
> > >> Can you compile the mjpegtools when you remove the -lX11 from the
> > >> lavtools/Makefile.am on the machine you have without X11 ? And do
> > >> the work ?
> > > That usually does the trick.
> > I hope that I have done it right. The -lX11 is now only added if you had 
> > SDL installed, and available.
> > 
> > >>> I've searched the SourceForge bug tracker and this list but
> > >>> couldn't find a similar report - apologies if this is a dupe.
> > >> No problem, I don't remember that this has been discussed some time
> > >> ago.
> > >
> > > You just don't remember it. :)
> > > http://osdir.com/ml/video.mjpeg.devel/2004-03/msg00012.html
> > That was very long ago, even at the time you wrote the mail.
> > 
> > > That flag has a tendency to creep back in at every release. :) I'm
> > > pretty sure I've reported it at som time, too, but Google doesn't
> > > tell.
> > And I didn't search.
> > 
> > auf hoffentlich bald,
> > 
> > Berni the Chaos of Woodquarter
> > 
> > Email: sha...@ut...
> > www: http://www.lysator.liu.se/~gz/bernhard
> 

Re: [Mjpeg-developer] v1.9.0 compilation fails due to X11 dependency on Linux with V4L

[Martin S. <sa...@ho...>]

On Tue, 03 May 2011 19:59:37 +0200
Bernhard Praschinger <sha...@ut...> wrote:

> Hallo
> 
> Martin Samuelsson wrote:
> > On Mon, 23 Feb 2009 20:28:40 +0100
> Ok, I hope you don't break down laughing when you read the answer from a
> mail you sent to me more than 2 years ago. ;)

Ah, this old gem! I applaud your hard work stomping it to death!

Unfortunately, I don't have any X-less machine nearby to test the patch, and a waiting-to-happen expansion of the family practically guarantees that I won't be able to test it in the foreseeable future.

Regards,
/Martin

> 
> I try to make my open problems list smaller. I really want to make a 
> release in may this year.
> 
> >> Stuart Hickinbottom wrote:
> >>> I'm reporting this in response to a Gentoo Linux bug I've filed
> >>> (http://bugs.gentoo.org/show_bug.cgi?id=217427#c11).
> >> [...]
> >>> On a headless (no X11) Linux server that has V4L, the compilation
> >>> of 1.9.0 fails as follows:
> >> I haven't seen a X11 less Linux for quite some time. All my
> >> machines (regular an virtual have X11)
> > They do exist. The last time I encountered this, I had the disk space
> > to spare for a set of X devel files, but at other times, I've removed
> > the offending flag manually.
> I have now added a fix to the CVS that seems to work for me. Things 
> still compile on my computer where X11 is installed. I hope one of you 
> (and any other person is invited too !) has still a machine without X11 
> installed and trys to compile the mjpegtools (latest CVS, because I 
> committed the patch just a few minutes ago.
> 
> >> Can you compile the mjpegtools when you remove the -lX11 from the
> >> lavtools/Makefile.am on the machine you have without X11 ? And do
> >> the work ?
> > That usually does the trick.
> I hope that I have done it right. The -lX11 is now only added if you had 
> SDL installed, and available.
> 
> >>> I've searched the SourceForge bug tracker and this list but
> >>> couldn't find a similar report - apologies if this is a dupe.
> >> No problem, I don't remember that this has been discussed some time
> >> ago.
> >
> > You just don't remember it. :)
> > http://osdir.com/ml/video.mjpeg.devel/2004-03/msg00012.html
> That was very long ago, even at the time you wrote the mail.
> 
> > That flag has a tendency to creep back in at every release. :) I'm
> > pretty sure I've reported it at som time, too, but Google doesn't
> > tell.
> And I didn't search.
> 
> auf hoffentlich bald,
> 
> Berni the Chaos of Woodquarter
> 
> Email: sha...@ut...
> www: http://www.lysator.liu.se/~gz/bernhard

Re: [Mjpeg-developer] v1.9.0 compilation fails due to X11 dependency on Linux with V4L

[Bernhard P. <sha...@ut...>]

Hallo

Martin Samuelsson wrote:
> On Mon, 23 Feb 2009 20:28:40 +0100
Ok, I hope you don't break down laughing when you read the answer from a
mail you sent to me more than 2 years ago. ;)

I try to make my open problems list smaller. I really want to make a 
release in may this year.

>> Stuart Hickinbottom wrote:
>>> I'm reporting this in response to a Gentoo Linux bug I've filed
>>> (http://bugs.gentoo.org/show_bug.cgi?id=217427#c11).
>> [...]
>>> On a headless (no X11) Linux server that has V4L, the compilation
>>> of 1.9.0 fails as follows:
>> I haven't seen a X11 less Linux for quite some time. All my
>> machines (regular an virtual have X11)
> They do exist. The last time I encountered this, I had the disk space
> to spare for a set of X devel files, but at other times, I've removed
> the offending flag manually.
I have now added a fix to the CVS that seems to work for me. Things 
still compile on my computer where X11 is installed. I hope one of you 
(and any other person is invited too !) has still a machine without X11 
installed and trys to compile the mjpegtools (latest CVS, because I 
committed the patch just a few minutes ago.

>> Can you compile the mjpegtools when you remove the -lX11 from the
>> lavtools/Makefile.am on the machine you have without X11 ? And do
>> the work ?
> That usually does the trick.
I hope that I have done it right. The -lX11 is now only added if you had 
SDL installed, and available.

>>> I've searched the SourceForge bug tracker and this list but
>>> couldn't find a similar report - apologies if this is a dupe.
>> No problem, I don't remember that this has been discussed some time
>> ago.
>
> You just don't remember it. :)
> http://osdir.com/ml/video.mjpeg.devel/2004-03/msg00012.html
That was very long ago, even at the time you wrote the mail.

> That flag has a tendency to creep back in at every release. :) I'm
> pretty sure I've reported it at som time, too, but Google doesn't
> tell.
And I didn't search.

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

Re: [Mjpeg-developer] V4L not in Linux kernel 2.6

[Bernhard P. <sha...@ut...>]

Hallo

John Vogel wrote:
> While trying to build mjpegtools-2.0.0rc1, configure choked on check for
> linux/videodev.h. This is v4l specific. Recent kernels have v4l2 only.
> Small patch attached.

Some time ago there was a entry to the tracker about the same problem 
but a different solution on Gento:
http://sourceforge.net/tracker/?func=detail&atid=105776&aid=3272052&group_id=5776

Original Bug on Gento:
https://bugs.gentoo.org/show_bug.cgi?id=359491#c5

So we have 2 Solutions for one problem. :)
I'm still unsoure if any of the mjpegtools uses still V4L (1)
I think someone wrote a not about V4L2 and the mjpegtools but I can't 
find that right now.

The only 2 programms I remeber using V4L are lavrec and lavplay (H and C 
Option). After all Zoran cards do work now only under very specific 
conditions any more (>2 year old kernel, only 2GB Ram ....)

So I merged both patches into one. And put them into CVS.
That problem will be worked around correct ;)

auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: sha...@ut...
www: http://www.lysator.liu.se/~gz/bernhard

[Mjpeg-developer] V4L not in Linux kernel 2.6

[John V. <jv...@st...>]

While trying to build mjpegtools-2.0.0rc1, configure choked on check for 
linux/videodev.h. This is v4l specific. Recent kernels have v4l2 only. 
Small patch attached.

Re: [Mjpeg-developer] AVI, padding

[Burkhard P. <pl...@ip...>]

Hi,

Am 10.03.2011 17:13, schrieb Torsten Mohr:
> Hello,
>
>> As far as I know, there is at most one padding byte in AVIs
>> such that all chunks (header chunks and data chunks) start at even
>> file offsets.
>
> thanks for your answer.
>
> This is not what i experience when decoding an AVI that contains single JPEGs.
>
> The JPEGs themselves contain correct start- and end-markers and after the end-
> markers there is a variable amount of padding.
> The padding is always 0x00 and the number is variable from 0 to 24 (can be
> more, i did not look further).
>
>
> Best regards,
> Torsten.

If the total size (including padding) of the JPEG-frame is the AVI chunk size, this
isn't a AVI issue but a JPEG issue. I guess every sane JPEG-decoder will ignore
all data after the end-marker, but the JPEG-Standard might tell more about this.

Burkhard

Re: [Mjpeg-developer] AVI, padding

[Torsten M. <tmohr@s.netic.de>]

Hello,

> As far as I know, there is at most one padding byte in AVIs
> such that all chunks (header chunks and data chunks) start at even
> file offsets.

thanks for your answer.

This is not what i experience when decoding an AVI that contains single JPEGs.

The JPEGs themselves contain correct start- and end-markers and after the end-
markers there is a variable amount of padding.
The padding is always 0x00 and the number is variable from 0 to 24 (can be 
more, i did not look further).


Best regards,
Torsten.

Re: [Mjpeg-developer] AVI, padding

[Burkhard P. <pl...@ip...>]

Hi,

Torsten Mohr wrote
> Hello,
>
> i hope my question is not off topic here.
>
> I wrote a python script to read an AVI and interpret its content.  The AVI
> contains JPEG images and i can extract them.  But the AVI also contains
> pading
> 0x00 and i'm not sure about the number of padding bytes that is used.
> For decoding this is not that important but i'd also like to create an AVI
> and
> i think for this i may need to keep the correct number of padding 0x00.
>
> Can anybody give me a hint on how the padding in AVI works?
>
> I wonder about things like:
> - how many padding bytes do i need to add when creating an AVI?
> - when extracting sound streams, how many padding bytes do i need to skip?

As far as I know, there is at most one padding byte in AVIs
such that all chunks (header chunks and data chunks) start at even
file offsets.

Burkhard

[Mjpeg-developer] AVI, padding

[Torsten M. <tmohr@s.netic.de>]

Hello,

i hope my question is not off topic here.

I wrote a python script to read an AVI and interpret its content.  The AVI 
contains JPEG images and i can extract them.  But the AVI also contains pading 
0x00 and i'm not sure about the number of padding bytes that is used.
For decoding this is not that important but i'd also like to create an AVI and 
i think for this i may need to keep the correct number of padding 0x00.

Can anybody give me a hint on how the padding in AVI works?

I wonder about things like:
- how many padding bytes do i need to add when creating an AVI?
- when extracting sound streams, how many padding bytes do i need to skip?


Best regards,
Torsten.