Re: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Dear Kuninori,
Am Donnerstag, den 15.07.2010, 14:37 +0900 schrieb Kuninori Morimoto:
Dear hermann
Is there any documentation and how can a user know about it?
Ecovec board which I and Guennadi were talking about is an evaluation board.
If you buy this board, you can find DVD including manual in its box.
Please check
${DVD}/hardware/user's_manual/eng/rej10j2027-0101_R0P7724LC001121RL_um_1.03.pdf
on that stage it is now, you can't call me to crawl the web or buy any
evaluation board, likely high priced, still not even providing a link.
If you use GNU/Linux, free of charge, you have to provide acceptable
documentation too.
dip-switch settings is wrote in
3.4 Switch Specification
If you don't have this board,
but have kernel source code,
you can watch explain comment on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Best regards
--
Kuninori Morimoto
This is lame. I do want to know what is out in the markets already and
no fall back on initial dip-switch comments. Comparable sensors ship
from China directly for some 5 Euros and less here.
This is a change (chance?) in culture too, and was already discussed in
1976 by some, but was at least public for all those a little bit more
interested since, let's say, 1982.
This is going on for a long time now, it did not hit the linuxtv.org
wiki at all until today, but introduces most relevant API changes. To
stop to provide support for older devices, in favor of the like of such
stuff, was mentioned several times already to get quicker to the
bonanza.
All major hardware manufacturers, and/or those claiming to be codec
possessors, have hired linux devel teams around the globe to move this
forward.
What it means, that everyone likely can film his life soon with two HD
cameras on mobile devices at once, let's say with 1080p for now, one
following his view to the outside world, the other one pointing to
him/her at the same time, about that, there is no word on this list.
It is not about missing some dip switch settings on an evaluation board.
It is about missing documentation, but much more about missing
reflection, if GNU/Linux should give the vehicle for such.
And it obviously does, even without any further comments.
Cheers,
Hermann
--
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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Dear hermann
Is there any documentation and how can a user know about it?
Ecovec board which I and Guennadi were talking about is an evaluation board.
If you buy this board, you can find DVD including manual in its box.
Please check
${DVD}/hardware/user's_manual/eng/rej10j2027-0101_R0P7724LC001121RL_um_1.03.pdf
dip-switch settings is wrote in
3.4 Switch Specification
If you don't have this board,
but have kernel source code,
you can watch explain comment on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Best regards
--
Kuninori Morimoto
--
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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
On Tue, 13 Jul 2010, Kuninori Morimoto wrote:
Dear Guennadi
I've got a question to you, regarding your interlaced support
implementation for the CEU: do I understand it right, that the kind of
support you actually have implemented is, that if an interlaced format is
now requested from the CEU, it will interpret incoming data as interlaced
and deinterlace it internally?
It is correct excluding interlaced format is now requested from the CEU.
Now, the device which request interlace format is video device.
If you use Ecovec, it is tw9910.
That's one part of the equation, yes.
If this is really the case, then, I think,
it is a wrong way to implement this functionality. If a user requests
interlaced data, it means, (s)he wants it interlaced in memory. Whereas
deinterlacing should happen transparently - if the user requested
progressive data and your source provides interlaced, you can decide to
deinterlace it internally. Or am I misunderstanding your implementation?
Hmm...
Now only CEU + tw9910 pair use interlace mode in CEU.
But it doesn't support interlace mode from user space.
(I don't know how to request it from user space)
The S_FMT ioctl() has a field fmt.pix.field, which carries exactly this
information. So, by executing this ioctl() with different field values you
request progressive or one of interlaced formats. And returning
interlaced, when you actually supply progressive data to the user is not
a good idea, and this is what's currently happening, I think. It's just
our luck, that mplayer (and gstreamer?) ignore returned field value. But
we'll have to fix this in sh_mobile_ceu_camera.
Now interlace mode is used internally.
This mean, it seems as progressive mode from user space.
Exactly, we return progressive data, but give interlaced back in reply
to S_FMT. Or at least we do not differentiate between user field setting
and driver field setting, which we really should.
Regardless of theoretical correctness - does your patch still work? Have
you been able back then to get CEU to deinterlace data, and when have you
last tested it?
I tested CEU interlace mode by using Ecovec board.
I can watch correct video image on at least v2.6.34.
I used this command.
VIDIX=-vo fbdev:vidix:sh_veu
SIZE=-tv width=1280:height=720
NTSC=-tv norm=NTSC
OUT=tv:// -tv outfmt=nv12
DEVICE=-tv device=/dev/video0
mplayer ${VIDIX} ${SIZE} ${NTSC} ${OUT} ${DEVICE}
Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works
on migor for me, but not on ecovec, although the chip can be detected. Are
there any modifications necessary to the kernel or to the board to get it
to work? Maybe a jumper or something? I plug in a video signal source in
the video in connector, next to the viceo out one, using the same
cable, so, cabling should work too. But I'm only getting select timeouts
and no interrupts on the CEU.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Dear Guennadi
our luck, that mplayer (and gstreamer?) ignore returned field value. But
we'll have to fix this in sh_mobile_ceu_camera.
Hmm I understand.
I guess, at first, we need test program for it.
Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works
on migor for me, but not on ecovec, although the chip can be detected. Are
there any modifications necessary to the kernel or to the board to get it
to work? Maybe a jumper or something? I plug in a video signal source in
the video in connector, next to the viceo out one, using the same
cable, so, cabling should work too. But I'm only getting select timeouts
and no interrupts on the CEU.
Hmm.. strange...
No kernel patch is needed to use tw9910 on Ecovec.
Ahh...
Maybe the criminal is dip-switch.
We can not use tw9910 and 2nd camera in same time.
Please check DS2[3] on Ecovec.
It should OFF when you use tw9910.
I wrote dip-switch info on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Please check it too.
Best regards
--
Kuninori Morimoto
--
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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Am Mittwoch, den 14.07.2010, 09:12 +0900 schrieb Kuninori Morimoto:
Dear Guennadi
our luck, that mplayer (and gstreamer?) ignore returned field value. But
we'll have to fix this in sh_mobile_ceu_camera.
Hmm I understand.
I guess, at first, we need test program for it.
Well, I think, 720p is a little too optimistic for tw9910;) tw9910 works
on migor for me, but not on ecovec, although the chip can be detected. Are
there any modifications necessary to the kernel or to the board to get it
to work? Maybe a jumper or something? I plug in a video signal source in
the video in connector, next to the viceo out one, using the same
cable, so, cabling should work too. But I'm only getting select timeouts
and no interrupts on the CEU.
Hmm.. strange...
No kernel patch is needed to use tw9910 on Ecovec.
Ahh...
Maybe the criminal is dip-switch.
We can not use tw9910 and 2nd camera in same time.
Please check DS2[3] on Ecovec.
It should OFF when you use tw9910.
I wrote dip-switch info on top of
${LINUX}/arch/sh/boards/mach-ecovec24/setup.c
Please check it too.
Best regards
--
Kuninori Morimoto
Kuninori,
you are well treated and highly honored by all staying in development
with you. For me it is just some glitch on the edges, but very well
noted.
For now, a dip-switch, you must have been abroad somewhere, can't be a
criminal. Or?
http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ
Could you eventually agree with that about what a dip-switch is or do I
miss what you mean?
Do you really tell there are still unclear dip-switches in 2010?
If so, please let's know, but then you can't do anything against such in
software, of course.
Cheers,
Hermann
--
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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Dear hermann For now, a dip-switch, you must have been abroad somewhere, can't be a criminal. Or? http://www.dip-switch.com/?gclid=COjg9Mn86aICFYSdzAodNEcLkQ Could you eventually agree with that about what a dip-switch is or do I miss what you mean? Do you really tell there are still unclear dip-switches in 2010? If so, please let's know, but then you can't do anything against such in software, of course. I'm so sorry about my stupid English. I should not use the words of criminal. I should say The reason that there are no video output on Ecovec might dip-switch setting issue. DS2[3] should be OFF when you use video Best regards -- Kuninori Morimoto -- 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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Hello Morimoto-san I've got a question to you, regarding your interlaced support implementation for the CEU: do I understand it right, that the kind of support you actually have implemented is, that if an interlaced format is now requested from the CEU, it will interpret incoming data as interlaced and deinterlace it internally? If this is really the case, then, I think, it is a wrong way to implement this functionality. If a user requests interlaced data, it means, (s)he wants it interlaced in memory. Whereas deinterlacing should happen transparently - if the user requested progressive data and your source provides interlaced, you can decide to deinterlace it internally. Or am I misunderstanding your implementation? Regardless of theoretical correctness - does your patch still work? Have you been able back then to get CEU to deinterlace data, and when have you last tested it? Thanks Guennadi --- Guennadi Liakhovetski -- 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: [PATCH] Add interlace support to sh_mobile_ceu_camera.c
Dear Guennadi
I've got a question to you, regarding your interlaced support
implementation for the CEU: do I understand it right, that the kind of
support you actually have implemented is, that if an interlaced format is
now requested from the CEU, it will interpret incoming data as interlaced
and deinterlace it internally?
It is correct excluding interlaced format is now requested from the CEU.
Now, the device which request interlace format is video device.
If you use Ecovec, it is tw9910.
If this is really the case, then, I think,
it is a wrong way to implement this functionality. If a user requests
interlaced data, it means, (s)he wants it interlaced in memory. Whereas
deinterlacing should happen transparently - if the user requested
progressive data and your source provides interlaced, you can decide to
deinterlace it internally. Or am I misunderstanding your implementation?
Hmm...
Now only CEU + tw9910 pair use interlace mode in CEU.
But it doesn't support interlace mode from user space.
(I don't know how to request it from user space)
Now interlace mode is used internally.
This mean, it seems as progressive mode from user space.
Regardless of theoretical correctness - does your patch still work? Have
you been able back then to get CEU to deinterlace data, and when have you
last tested it?
I tested CEU interlace mode by using Ecovec board.
I can watch correct video image on at least v2.6.34.
I used this command.
VIDIX=-vo fbdev:vidix:sh_veu
SIZE=-tv width=1280:height=720
NTSC=-tv norm=NTSC
OUT=tv:// -tv outfmt=nv12
DEVICE=-tv device=/dev/video0
mplayer ${VIDIX} ${SIZE} ${NTSC} ${OUT} ${DEVICE}
Best regards
--
Kuninori Morimoto
--
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
