Re: gstreamer and v4l2

[Ran Shalit]

On Tue, Mar 15, 2016 at 9:18 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> On 03/15/2016 08:10 AM, Ran Shalit wrote:
>> Hello,
>>
>> This is a bit offtopic, so I will understand if you rather not discuss 
>> that...
>>
>> I am trying to use gstreamer with v4l2 vivi device,
>> I first check the capabilities with
>>
>> gst-launch-1.0 --gst-debug=v4l2src:5 v4l2src device="/dev/video0" !
>> fakesink 2>&1
>>
>> and it gives many capabilities such as the following:
>>
>> video/x-raw-yuv, format=(string)YUY2, framerate=(fraction)[1/1000,
>> 1000/1], width=(int) 640, height=(int)180, interlaced=(boolean)true
>>
>> So I tried to run as following:
>>
>> gst-launch-0.10 v4l2src device="/dev/video0" !
>> video/x-raw,width=640,height=180,framerate=30 ! autovideosink
>>
>> But it keeps giving me auto negotiation error -4.
>> Trying to give other values did not help neither.
>>
>> It is probaby more a gstreamer issue, but if someone is familiar and
>> can shed some light on this will will help.
>
> Actually, I suspect that vivi is the culprit. It had some non-standard
> behavior that might mess up gstreamer. One of the (many) reasons it was
> replaced with vivid.
>
> Regards,
>
> Hans

Hi Hans,

Thanks for the quick response.
Well... a minue after posting...
I made another try and just added videoconvert  (or ffmpegcolorspace)
before  autovideosink, and now it works just fine !
probably the unique size (640x180) from vivi is not supported in
autovideosink, without conversion in between.

So this how it works in my case , if it helps anyone with similar issue:

 gst-launch-0.10 v4l2src device="/dev/video0" !
video/x-raw,width=640,height=180,framerate=30 ! ffmpegcolorspace !
autovideosink

Thank you very much,
Ran
--
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

gstreamer and v4l2

[Ran Shalit]

Hello,

This is a bit offtopic, so I will understand if you rather not discuss that...

I am trying to use gstreamer with v4l2 vivi device,
I first check the capabilities with

gst-launch-1.0 --gst-debug=v4l2src:5 v4l2src device="/dev/video0" !
fakesink 2>&1

and it gives many capabilities such as the following:

video/x-raw-yuv, format=(string)YUY2, framerate=(fraction)[1/1000,
1000/1], width=(int) 640, height=(int)180, interlaced=(boolean)true

So I tried to run as following:

gst-launch-0.10 v4l2src device="/dev/video0" !
video/x-raw,width=640,height=180,framerate=30 ! autovideosink

But it keeps giving me auto negotiation error -4.
Trying to give other values did not help neither.

It is probaby more a gstreamer issue, but if someone is familiar and
can shed some light on this will will help.

Linux version is 3.10.0.

Regards,
Ran
--
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

Multiple open and read of vivi device

[Ran Shalit]

Hello,

Does anyone knows why vivi is limited to one open ?
Is there some way to patch it for multiple opens and reading ?

Regards,
Ran
--
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: CMA usage in driver

[Ran Shalit]

On Sat, Jan 2, 2016 at 11:23 PM, Ran Shalit <ransha...@gmail.com> wrote:
> Hello,
>
> I made some reading on CMA usage with device driver, nut not quite sure yet.
> Do we need to call dma_declare_contiguous or does it get called from
> within videobuf2 ?
>
> Is there any example how to use CMA memory in v4l2 driver ?
>

Hi,

just to make the above question simpler:
from a v4l2 driver perspective, when need large contigious dma
allocations are required,
what should matter, and do we need to use CMA and how ?

Thank you for the time,
Ran
--
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

CMA usage in driver

[Ran Shalit]

Hello,

I made some reading on CMA usage with device driver, nut not quite sure yet.
Do we need to call dma_declare_contiguous or does it get called from
within videobuf2 ?

Is there any example how to use CMA memory in v4l2 driver ?

Best Regards,
Ran
--
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

PCIe sg dma device used as dma-contig

[Ran Shalit]

Hello,

The following question is not totally in the scope of v4l2, but more
about your advise concering dma alternatives for non-expreciened v4l2
device writer.
We intend to use the fpga for concurrent 3xHD and 3xSD.

We have some dillema regadring the fpga to choose from:
ALTERA fpga which use contiguous dma memory, or Xilinx fpga which is
using scatter-gather architecture.

With xilinx, it seems that the sg architecture can also be used as
contiguous according to the following:
"... While these descriptors are not required to be contiguous, they
should be contained within an 8 megabyte region which corresponds to
the width of the AXI_PCIe_SG port"
it seems according to the above description that sg-list can be used
as single contiguous descriptor (with dma-cotig), though the 8MBytes
seems like a problematic constrain. This constrain make it difficult
to be used with dma-contig solution in v4l2.

Our current direction is try to imeplement it as simple as possible.
Therefore we prefer the dma contiguous solution (I think that together
with CMA and a strong cpu like 64-bit i7 it can handle contigious
memory for 3xHD and 3xSD allocation).

Any feedback is appreciated,
Ran
--
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: dt3155 as a reference

[Ran Shalit]

On Wed, Dec 23, 2015 at 3:09 PM, hverkuil <hverk...@xs4all.nl> wrote:
> On 2015-12-23 13:55, Ran Shalit wrote:
>>
>> Hello,
>>
>> I think to use dt3155 as a reference for new pci express driver ,
>> becuase it is highly simple as a starting point, and contains only
>> single file :)
>> The driver I'll develop will eventually be used for multiple video
>> capture and single video output.
>>
>> I just wanted to ask if you recommend it as a starting point.
>
>
> Yeah, that would work.
>
> Regards,
>
> Hans
>

Hi,

Is there a chance anyone have the HW reference for dt3155 ?
I can't  find it anywhere.

Thanks,
Ran
--
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

dt3155 as a reference

[Ran Shalit]

Hello,

I think to use dt3155 as a reference for new pci express driver ,
becuase it is highly simple as a starting point, and contains only
single file :)
The driver I'll develop will eventually be used for multiple video
capture and single video output.

I just wanted to ask if you recommend it as a starting point.

Best Regards,
Ran
--
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: v4l2 kernel module debugging methods

[Ran Shalit]

On Fri, Dec 11, 2015 at 10:50 AM, Fabien DESSENNE
<fabien.desse...@st.com> wrote:
> Hi Ran,
>
> On 12/10/2015 10:46 PM, Ran Shalit wrote:
>> On Sun, Dec 6, 2015 at 2:23 AM, Nicolas Dufresne
>> <nicolas.dufre...@collabora.com> wrote:
>>> Le dimanche 06 décembre 2015 à 00:00 +0200, Ran Shalit a écrit :
>>>> Hello,
>>>>
>>>> I would like to ask a general question regarding methods to debug a
>>>> v4l2 device driver.
>>>> Since I assume that the kernel driver will probably won't work in
>>>> first try after coding everything inside the device driver...
>>>>
>>>> 1. Do you think qemu/kgdb debugger is a good method for the device
>>>> driver debugging , or is it plain printing ?
>>>>
>>>> 2. Is there a simple way to display the image of a YUV-like buffer in
>>>> memory ?
>>>
>>> Most Linux distribution ships GStreamer. You can with GStreamer read
>>> and display a raw YUV images (you need to know the specific format)
>>> using videoparse element.
>>>
>>>gst-launch-1.0 filesrc location=my.yuv ! videoparse format=yuy2 
>>> width=320 height=240 ! imagefreeze ! videoconvert ! autovideosink
>>>
>>> You could also encode and store to various formats, replacing the
>>> imagefreeze ... section with an encoder and a filesink. Note that
>>> videoparse unfortunatly does not allow passing strides array or
>>> offsets. So it will work only if you set the width/height to padded
>>> width/height.
>>>
>>> regards,
>>> Nicolas
>>
>> Hi Nicolas,
>>
>> Thank you for the comment.
>> As someone expreinced with v4l2 device driver, do you recommened using
>> debugging technique such as qemu (or kgdb) or do you rather use plain
>> printing ?
>>
>> Thank you very much,
>> Ran
>
>
> You can get several level of logs.
> First, you can enable v4l2 core debug logs. Example:
>   echo 3 > /sys/class/video4linux/video0/debug
> More details:
> https://www.kernel.org/doc/Documentation/video4linux/v4l2-framework.txt
>
> If the tested driver uses the v4l2_mem2mem framework you can get M2M
> logs with:
>   echo Y > /sys/module/v4l2_mem2mem/parameters/debug
>
> Get also internal vb2 logs with:
>   echo 3 > /sys/module/videobuf2_core/parameters/debug
>
> And optionally more logs using the dynamic debug feature:
> (https://www.kernel.org/doc/Documentation/dynamic-debug-howto.txt). Example:
>   echo "module my_driver +p" > /sys/kernel/debug/dynamic_debug/control
>
> Fabien

Thank you very much for the helpful ideas.

Regards,
Ran
--
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: v4l2 kernel module debugging methods

[Ran Shalit]

On Sun, Dec 6, 2015 at 2:23 AM, Nicolas Dufresne
<nicolas.dufre...@collabora.com> wrote:
> Le dimanche 06 décembre 2015 à 00:00 +0200, Ran Shalit a écrit :
>> Hello,
>>
>> I would like to ask a general question regarding methods to debug a
>> v4l2 device driver.
>> Since I assume that the kernel driver will probably won't work in
>> first try after coding everything inside the device driver...
>>
>> 1. Do you think qemu/kgdb debugger is a good method for the device
>> driver debugging , or is it plain printing ?
>>
>> 2. Is there a simple way to display the image of a YUV-like buffer in
>> memory ?
>
> Most Linux distribution ships GStreamer. You can with GStreamer read
> and display a raw YUV images (you need to know the specific format)
> using videoparse element.
>
>   gst-launch-1.0 filesrc location=my.yuv ! videoparse format=yuy2 width=320 
> height=240 ! imagefreeze ! videoconvert ! autovideosink
>
> You could also encode and store to various formats, replacing the
> imagefreeze ... section with an encoder and a filesink. Note that
> videoparse unfortunatly does not allow passing strides array or
> offsets. So it will work only if you set the width/height to padded
> width/height.
>
> regards,
> Nicolas

Hi Nicolas,

Thank you for the comment.
As someone expreinced with v4l2 device driver, do you recommened using
debugging technique such as qemu (or kgdb) or do you rather use plain
printing ?

Thank you very much,
Ran
--
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

fbdev - wipe screen (dd) with ioctl ?

[Ran Shalit]

Hello,

I use the following to wipe a screen:
dd if=/dev/zero of=/dev/fb0 code

Is there a way to do the same thing in code (using ioctl I suppose) ?

Regards,
Ran
--
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

v4l2 kernel module debugging methods

[Ran Shalit]

Hello,

I would like to ask a general question regarding methods to debug a
v4l2 device driver.
Since I assume that the kernel driver will probably won't work in
first try after coding everything inside the device driver...

1. Do you think qemu/kgdb debugger is a good method for the device
driver debugging , or is it plain printing ?

2. Is there a simple way to display the image of a YUV-like buffer in memory ?

Any other methods, tips, about validation, testing and developing a
v4l2 device is appreciated.

Best Regards,
Ran
--
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

Interrupt handler responsibility

[Ran Shalit]

Hello,

I am trying to understand the interrupt handler responsibility in
v4l2, also with respect to dma usage. I see that it is not defined as
part of the videobuf2 API.

This is what I understand this far:
1. start_streaming is responsible for getting into "streaming" state.
dma start should be trigggered at this point.
2. interrupt handler: is responsible for passing back the buffer to
user using vb2_buffer_done() call.

But what is the exact reponsibility of interrupt handler with respect
to dma usage  ?
In some of the drivers I see that the interrupt start/stop dma, but in
 v4l2-pci-skeleton.c I don't see any usage of dma in the interrupt
handler, so I'm not sure.

Best Regards,
Ran
--
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: cobalt & dma

[Ran Shalit]

Hello,



>
> No. All video capture/output devices all use DMA since it would be 
> prohibitively
> expensive for the CPU to do otherwise. So just dig in and implement it.

I am trying to better understand how read() operation actually use the
dma, but I can't yet understand it from code.

>
> No. The vmalloc variant is typically used for USB devices. For PCI(e) you'll
> use videobuf2-dma-contig if the DMA engine requires physically contiguous DMA,
> or videobuf2-dma-sg if the DMA engine supports scatter-gather DMA. You can
> start with dma-contig since the DMA code tends to be simpler, but it is
> harder to get the required physically contiguous memory if memory 
> fragmentation
> takes place. So you may not be able to allocate the buffers. dma-sg works much
> better with virtual memory.
>
>


1. I tried to understand the code implementation of videobuf2 with
regards to read():
read() ->
vb2_read() ->
  __vb2_perform_fileio()->
 vb2_internal_dqbuf() &  copy_to_user()

Where is the actual allocation of dma contiguous memory ? Is done with
the userspace calloc() call in userspace (as shown in the v4l2 API
example) ? As I understand the calloc/malloc are not guaranteed to be
contiguous.
 How do I know if the try to allocate contigious memory has failed or not ?


2. Is the call to copy_to_user results is performance degredation of
read() in compare to mmap() method ?

Best Regards,
Ran
--
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: cobalt & dma

[Ran Shalit]

>>
>> 1. I tried to understand the code implementation of videobuf2 with
>> regards to read():
>> read() ->
>> vb2_read() ->
>>   __vb2_perform_fileio()->
>>  vb2_internal_dqbuf() &  copy_to_user()
>>
>> Where is the actual allocation of dma contiguous memory ? Is done with
>> the userspace calloc() call in userspace (as shown in the v4l2 API
>> example) ? As I understand the calloc/malloc are not guaranteed to be
>> contiguous.
>>  How do I know if the try to allocate contigious memory has failed or 
>> not ?
>
> The actual allocation happens in videobuf2-vmalloc/dma-contig/dma-sg depending
> on the flavor of buffers you want (virtual memory, DMA into physically 
> contiguous
> memory or DMA into scatter-gather memory). The alloc operation is the one that
> allocates the memory.


Thank you very much for the time.

Just to be sure I understand the general mechanism of DMA with regards
to the read() operation and in the case of using contiguous memory,
I try to draw the general sequence as I understand it from the code
and reading on this issue:

read() into user memory buffer ->
  vb2_read() ->
__vb2_perform_fileio() ->
deaque buffer with:  vb2_internal_dqbuf() into
contiguous DMA memory (kernel)  ->
   copy_to_user() will actually copy from
the contigious dma memory(kernel)  into user buffer (userspace)

1. Is the above sequence  correct ?
2. When talking about contiguous dma memory (or scatter-gatther) we
actually always refer to memory allocated in kernel, right ?

Best Regards,

Ran
--
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: cobalt & dma

[Ran Shalit]

On Tue, Nov 17, 2015 at 9:53 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> On 11/17/2015 08:39 AM, Ran Shalit wrote:
>> Hello,
>>
>> I intend to use cobalt driver as a refence for new pci v4l2 driver,
>> which is required to use several input simultaneously. for this cobalt
>> seems like a best starting point.
>> read/write streaming will probably be suffecient (at least for the
>> dirst debugging).
>> The configuration in my cast is i7 core <-- pci ---> fpga.
>> I see that the dma implementation is quite complex, and would like to
>> ask for some tips regarding the following points related to dma issue:
>>
>> 1. Is it possible to do the read/write without dma (for debug as start) ?
>
> No. All video capture/output devices all use DMA since it would be 
> prohibitively
> expensive for the CPU to do otherwise. So just dig in and implement it.
>

Hi,

Is the cobalt or other pci v4l device have the chip datasheet
available so that we can do a reverse engineering and gain more
understanding about the register read/write for the dma transactions ?
I made a search but it seems that the PCIe chip datasheet for these
devices is not available anywhere.

Best Regards,
Ran
--
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: cobalt & dma

[Ran Shalit]

On Tue, Nov 17, 2015 at 3:54 PM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> On 11/17/15 14:15, Ran Shalit wrote:
>> On Tue, Nov 17, 2015 at 9:53 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>>> On 11/17/2015 08:39 AM, Ran Shalit wrote:
>>>> Hello,
>>>>
>>>> I intend to use cobalt driver as a refence for new pci v4l2 driver,
>>>> which is required to use several input simultaneously. for this cobalt
>>>> seems like a best starting point.
>>>> read/write streaming will probably be suffecient (at least for the
>>>> dirst debugging).
>>>> The configuration in my cast is i7 core <-- pci ---> fpga.
>>>> I see that the dma implementation is quite complex, and would like to
>>>> ask for some tips regarding the following points related to dma issue:
>>>>
>>>> 1. Is it possible to do the read/write without dma (for debug as start) ?
>>>
>>> No. All video capture/output devices all use DMA since it would be 
>>> prohibitively
>>> expensive for the CPU to do otherwise. So just dig in and implement it.
>>>
>>
>> Hi,
>>
>> Is the cobalt or other pci v4l device have the chip datasheet
>> available so that we can do a reverse engineering and gain more
>> understanding about the register read/write for the dma transactions ?
>> I made a search but it seems that the PCIe chip datasheet for these
>> devices is not available anywhere.
>
> Sorry, no, it's not publicly available.
>
> But they all work along the same lines: each DMA descriptor has a
> PCI DMA address (where the data should be written to in memory), the length
> (bytes) of the DMA transfer and the pointer to the next DMA descriptor 
> (chaining
> descriptors together). Finally there is some bit to trigger and interrupt when
> the full frame has been transferred.
>


Thank you all very much for all these valuable information !
I must admit that when I observe the source examples,
it seems quite complex, (at least much more complex than the driver I
am familiar with, which most of them time is taking a functional
example and understanding what to change and how, or writing simple
drivers )

If there are any other tips and ideas about debug/testing/development
steps when doing pci v4l device driver please tell me.

Thank you all very much,
Ran
--
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

cobalt & dma

[Ran Shalit]

Hello,

I intend to use cobalt driver as a refence for new pci v4l2 driver,
which is required to use several input simultaneously. for this cobalt
seems like a best starting point.
read/write streaming will probably be suffecient (at least for the
dirst debugging).
The configuration in my cast is i7 core <-- pci ---> fpga.
I see that the dma implementation is quite complex, and would like to
ask for some tips regarding the following points related to dma issue:

1. Is it possible to do the read/write without dma (for debug as start) ?
What changes are required for read without dma (I assume dma is used
by default in read/write) ?
Is it done by using  #include  instead of
#include  ?

2. I find it difficult to unerstand  cobalt_dma_start_streaming()
implementation, which has many specific cobalt memory writing
iowrite32().
How can I understand how/what to implement dma in my specific platform/device ?


Best Regards,
Ran
--
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

ivtv: PVR family datasheet ?

[Ran Shalit]

Hello,

I was seaching for datasheet of Hauppauge PVR-150 (or other), but can't find it.
Does anyone know where it can be found ?

Best Regards,
Ran
--
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: ivtv: PVR family datasheet ?

[Ran Shalit]

On Sun, Nov 15, 2015 at 4:29 PM, Ran Shalit <ransha...@gmail.com> wrote:
> Hello,
>
> I was seaching for datasheet of Hauppauge PVR-150 (or other), but can't find 
> it.
> Does anyone know where it can be found ?

Hi,

I actually refer to CX23418 chip, which I don't find its datasheet (I
saw in code that cx18 can work in YUV raw capture, so I wanted to
verify that CX23418 can capture YUV raw format).

Regards,
Ran
--
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

v4l vs. dpdk

[Ran Shalit]

Hello,

I hope you can assist me on the following debate.

I need to develop a driver/application which capture and output video
frames from PCIe device , and is using Intel cpu (i7), and Intel's
media sdk server framework for the video compression.

I am not sure what will be a better choice between the following 2 options:
1. application which use dpdk for capture and output to the PCIe device
2. v4l driver for the PCIe device

Intel advocate the usage of dpdk (framework for packet processing).
dpdk is supposed to be able to read/write from PCIe device too.
I tried to see the prons/cons of dpdk compared to v4l.

prons of dpdk, as I understand them:
1. userspace application (easier debugging compared to kernel
debugging of v4l device driver)
2. supposed better performance

cons of dpdk compared to v4l:
1. I could not find examples for PCIe device usage , or samples for
showing how application (such as media sdk) use dpdk video frames.


Thank you for any feedback on the matter,

Regards,
Ran
--
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: PCIe capture driver

[Ran Shalit]

On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>
>
> On 10/27/2015 22:56, Ran Shalit wrote:
>> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>>>
>>>
>>> On 10/27/2015 02:04, Ran Shalit wrote:
>>>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <st...@kernellabs.com> wrote:
>>>>>> No, use V4L2. What you do with the frame after it has been captured
>>>>>> into memory has no relevance to the API you use to capture into memory.
>>>>>
>>>>> Ran, I've built many open and closed source Linux drivers over the
>>>>> last 10 years - so I can speak with authority on this.
>>>>>
>>>>> Hans is absolutely correct, don't make the mistake of going
>>>>> proprietary with your API. Take advantage of the massive amount of
>>>>> video related frameworks the kernel has to offer. It will get you to
>>>>> market faster, assuming your goal is to build a driver that is open
>>>>> source. If your licensing prohibits an open source driver solution,
>>>>> you'll have no choice but to build your own proprietary API.
>>>>>
>>>>> --
>>>>> Steven Toth - Kernel Labs
>>>>> http://www.kernellabs.com
>>>>
>>>> Hi,
>>>>
>>>> Thank you very much for these valuable comments.
>>>> If I may ask one more on this issue:
>>>> Is there an example in linux tree, for a pci device which is used both
>>>> as a capture and a display device ? (I've made a search but did not
>>>> find any)
>>>> The PCIe device we are using will be both a capture device and output
>>>> video device (for display).
>>>
>>> The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple 
>>> HDMI inputs and an optional HDMI output (through a daughterboard).
>>>
>>> Please note: using V4L2 for an output only makes sense if you will be 
>>> outputting video, if the goal is to output a graphical desktop then the 
>>> drm/kms API is much more suitable.
>>>
>>> Regards,
>>>
>>> Hans
>>
>> Hi Hans,
>>
>> Thank you very much for the reference.
>> I see that the cobalt card is not for sale ?  If it was it could help
>> us in our development.
>
> No, sorry. It's a Cisco-internal card only.
>
>> In our case it is more custom design which is based on FPGA:
>>
>> Cpu ---PCIe FPGA <<<-->>> 3xHD+3xSD inputs & 1xHD(or SD) output
>>
>> As I understand there is no product chip which can do the above
>> (3xHD+3xSD inputs & 1xHD(or SD) output), that's why the use of FPGA in
>> the board design.
>
> The ivtv driver (drivers/media/pci/ivtv) has SD input and output, so that can 
> be a
> useful reference for that as well. The Hauppauge PVR-350 board is no longer
> sold, but you might be able to pick one up on ebay.
>


Hello Hans,

Is it possible to use the PVR-350 which is a PCI device connected to
PCI express in mothrboard ? (I think it will required an adapter )
Does the ivtv driver function correctly if an adapter to PCIe is connected ?

Best Regards,
Ran
--
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

videobuf & read/write operation

[Ran Shalit]

Hello,

I'm trying to understand how to imeplement v4l driver using videobuf.
The videobuf documentation if very helpful.
When the documentation refers to " I/O stream" , does it also include
the read/write operation or only streaming I/O method ?

In case I am using only read/write, do I need to implement all these 4  APIs:

struct videobuf_queue_ops {
 int (*buf_setup)(struct videobuf_queue *q,
 unsigned int *count, unsigned int *size);
 int (*buf_prepare)(struct videobuf_queue *q,
 struct videobuf_buffer *vb,
enum v4l2_field field);
 void (*buf_queue)(struct videobuf_queue *q,
 struct videobuf_buffer *vb);
 void (*buf_release)(struct videobuf_queue *q,
 struct videobuf_buffer *vb);
};

Are these APIs relevant for both read/write and streaminf I/O ?

Best Regards,
Ran
--
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: videobuf & read/write operation

[Ran Shalit]

> Don't use videobuf! Use videobuf2, just like the skeleton driver.
>
> The old videobuf framework is deprecated and you shouldn't use it as it is
> horrible.
>
> Why on earth are you trying to use videobuf if the skeleton driver clearly
> uses vb2?
>

Right,
I now see that I was examining code which is quite old (2.6.37 from
SDK I'm using).

In case we only need read/write operation, do we still need to
implement all videobuf2 APIs ?


Regards,
Ran


>
>> When the documentation refers to " I/O stream" , does it also include
>> the read/write operation or only streaming I/O method ?
>>
>> In case I am using only read/write, do I need to implement all these 4  APIs:
>>
>> struct videobuf_queue_ops {
>>  int (*buf_setup)(struct videobuf_queue *q,
>>  unsigned int *count, unsigned int *size);
>>  int (*buf_prepare)(struct videobuf_queue *q,
>>  struct videobuf_buffer *vb,
>> enum v4l2_field field);
>>  void (*buf_queue)(struct videobuf_queue *q,
>>  struct videobuf_buffer *vb);
>>  void (*buf_release)(struct videobuf_queue *q,
>>  struct videobuf_buffer *vb);
>> };
>>
>> Are these APIs relevant for both read/write and streaminf I/O ?
>>
>> Best Regards,
>> Ran
>> --
>> 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: PCIe capture driver

[Ran Shalit]

On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>
>
> On 10/27/2015 22:56, Ran Shalit wrote:
>> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>>>
>>>
>>> On 10/27/2015 02:04, Ran Shalit wrote:
>>>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <st...@kernellabs.com> wrote:
>>>>>> No, use V4L2. What you do with the frame after it has been captured
>>>>>> into memory has no relevance to the API you use to capture into memory.
>>>>>
>>>>> Ran, I've built many open and closed source Linux drivers over the
>>>>> last 10 years - so I can speak with authority on this.
>>>>>
>>>>> Hans is absolutely correct, don't make the mistake of going
>>>>> proprietary with your API. Take advantage of the massive amount of
>>>>> video related frameworks the kernel has to offer. It will get you to
>>>>> market faster, assuming your goal is to build a driver that is open
>>>>> source. If your licensing prohibits an open source driver solution,
>>>>> you'll have no choice but to build your own proprietary API.
>>>>>
>>>>> --
>>>>> Steven Toth - Kernel Labs
>>>>> http://www.kernellabs.com
>>>>
>>>> Hi,
>>>>
>>>> Thank you very much for these valuable comments.
>>>> If I may ask one more on this issue:
>>>> Is there an example in linux tree, for a pci device which is used both
>>>> as a capture and a display device ? (I've made a search but did not
>>>> find any)
>>>> The PCIe device we are using will be both a capture device and output
>>>> video device (for display).
>>>
>>> The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple 
>>> HDMI inputs and an optional HDMI output (through a daughterboard).
>>>
>>> Please note: using V4L2 for an output only makes sense if you will be 
>>> outputting video, if the goal is to output a graphical desktop then the 
>>> drm/kms API is much more suitable.
>>>
>>> Regards,
>>>
>>> Hans
>>
>> Hi Hans,
>>
>> Thank you very much for the reference.
>> I see that the cobalt card is not for sale ?  If it was it could help
>> us in our development.
>
> No, sorry. It's a Cisco-internal card only.
>
>> In our case it is more custom design which is based on FPGA:
>>
>> Cpu ---PCIe FPGA <<<-->>> 3xHD+3xSD inputs & 1xHD(or SD) output
>>
>> As I understand there is no product chip which can do the above
>> (3xHD+3xSD inputs & 1xHD(or SD) output), that's why the use of FPGA in
>> the board design.
>
> The ivtv driver (drivers/media/pci/ivtv) has SD input and output, so that can 
> be a
> useful reference for that as well. The Hauppauge PVR-350 board is no longer
> sold, but you might be able to pick one up on ebay.
>
> Regards,
>
> Hans

I've been delving in V4l Wikis,  API,   and the PCI driver examples code.

I think a good starting point for the development will be
v4l2-pci-skeleton.c , becuase it is much simpler than the more
production examples,
do you recommend it as a starting point ?

I am just not sure that the pci skeleton supports the HD & SD channels
at the same time:
I think it will open only one device (for example /dev/video0) , so
that the application will need to select which input is used (not
both) ?

Best Regards,
Ran
--
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: PCIe capture driver

[Ran Shalit]

On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth  wrote:
>> No, use V4L2. What you do with the frame after it has been captured
>> into memory has no relevance to the API you use to capture into memory.
>
> Ran, I've built many open and closed source Linux drivers over the
> last 10 years - so I can speak with authority on this.
>
> Hans is absolutely correct, don't make the mistake of going
> proprietary with your API. Take advantage of the massive amount of
> video related frameworks the kernel has to offer. It will get you to
> market faster, assuming your goal is to build a driver that is open
> source. If your licensing prohibits an open source driver solution,
> you'll have no choice but to build your own proprietary API.
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com

Hi,

Thank you very much for these valuable comments.
If I may ask one more on this issue:
Is there an example in linux tree, for a pci device which is used both
as a capture and a display device ? (I've made a search but did not
find any)
The PCIe device we are using will be both a capture device and output
video device (for display).

Many Thanks,
Ran
--
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: PCIe capture driver

[Ran Shalit]

On Sat, Oct 24, 2015 at 11:38 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>
>
> On 10/23/2015 23:57, Ran Shalit wrote:
>> On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>>> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>>>> Hello,
>>>>
>>>> When writing a device driver for  capturing video coming from PCIe,
>>>> does it need to be used as v4l device (video for linux) , ?
>>>
>>> Yes. If you don't then 1) you will never be able to upstream the driver,
>>> 2) any application that wants to use your driver will need custom code to
>>> talk to your driver, 3) it will be a lot more work to write the driver
>>> since you can't use the V4L2 kernel frameworks it provides or ask for
>>> help.
>>>
>>> Basically, by deciding to reinvent the wheel you're screwing over your
>>> customers and yourself.
>>>
>>> Here is a nice PCI(e) template driver that you can use as your starting
>>> point: Documentation/video4linux/v4l2-pci-skeleton.c
>>>
>>> Regards,
>>>
>>> Hans
>>
>> Hi Hans,
>>
>> I now understand, that I will be using media sdk (Intel) which is
>> based on DRM framework, and does not use v4l.
>
> DRM is for video output, not video capture. So this seems irrelevant.
>
>> So I probably need to do some custom driver for delivering video with PCIe.
>
> There is only one linux API for video capture: V4L2. What PCIe card are we
> talking about here? What are you trying to achieve?
>

I need to capture video from PCIe . The video stream will be delivered
from PC through PCIe to a custom board with Intel cpu using media sdk.
The purpose is to encode the raw video and save the encoded stream to
a file.
I guess I can build some custom driver which waits for frames and
deliver the received frames to the media sdk encoder.
Since media sdk does not use v4l anyway, so I guess such custom driver
is the best under this conditions, Right ?
Regards,
Ran
--
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: PCIe capture driver

[Ran Shalit]

On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>> Hello,
>>
>> When writing a device driver for  capturing video coming from PCIe,
>> does it need to be used as v4l device (video for linux) , ?
>
> Yes. If you don't then 1) you will never be able to upstream the driver,
> 2) any application that wants to use your driver will need custom code to
> talk to your driver, 3) it will be a lot more work to write the driver
> since you can't use the V4L2 kernel frameworks it provides or ask for
> help.
>
> Basically, by deciding to reinvent the wheel you're screwing over your
> customers and yourself.
>
> Here is a nice PCI(e) template driver that you can use as your starting
> point: Documentation/video4linux/v4l2-pci-skeleton.c
>
> Regards,
>
> Hans

Hi Hans,

I now understand, that I will be using media sdk (Intel) which is
based on DRM framework, and does not use v4l.
So I probably need to do some custom driver for delivering video with PCIe.

Regards,
Ran
--
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: PCIe capture driver

[Ran Shalit]

On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>> Hello,
>>
>> When writing a device driver for  capturing video coming from PCIe,
>> does it need to be used as v4l device (video for linux) , ?
>
> Yes. If you don't then 1) you will never be able to upstream the driver,
> 2) any application that wants to use your driver will need custom code to
> talk to your driver, 3) it will be a lot more work to write the driver
> since you can't use the V4L2 kernel frameworks it provides or ask for
> help.
>
> Basically, by deciding to reinvent the wheel you're screwing over your
> customers and yourself.
>
> Here is a nice PCI(e) template driver that you can use as your starting
> point: Documentation/video4linux/v4l2-pci-skeleton.c
>
> Regards,
>
> Hans

Hans,

Many thanks for the detailed answer and the example !

Regards,
Ran
--
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

PCIe capture driver

[Ran Shalit]

Hello,

When writing a device driver for  capturing video coming from PCIe,
does it need to be used as v4l device (video for linux) , ?

Regards,
Ran
--
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

OpenCaster

[Ran Shalit]

Hello,

I would like to ask if OpenCaster is still active ?
Is it still recommended to be used with new design which requires
mpeg-ts streaming ?
How it is comarted to ffmpeg  ? it seems much more simpler to use :)

Thank you,
Ran
--
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

muxing ES to mpeg-ts

[Ran Shalit]

Hello,

I would please like to ask what is a good choice for muxing ES to mpeg
transport stream. It is required to do this in application (muxing the
encoder output into mpeg-ts which is transffered in ethernet udp).

I know that both ffmpeg and opencaster can support this.

What do you think will be a good choice for this ? (simplicity to
integrate in code, latency, debug, etc)

Regards,
Ran
--
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