[RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c

[RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c

[Ali Nasrolahi]

Hi everyone,

I'm working on a project involving high density video processing on a
single server using a large number of v4l2 loopback devices to route
virtual video streams to tenants.

While doing so, I ran into the hard limit imposed by `VIDEO_NUM_DEVICES`
(currently 256) in `drivers/media/v4l2-core/v4l2-dev.c`. Looking through
the code and git history, this limit has been there for quite a long time.
However, after searching the mailing list archives, I couldn't find any
previous discussion regarding this limitation.

May I ask:

1. Is there any internal design constraint that requires limiting the
   number of V4L2 devices to 256 on modern kernels?

2. Has this limit been discussed previously, or is there any relevant
   discussion that I may have missed?

If the current limit is no longer intentional and there's no historical
context that I might've missed, I'd be happy to work on a patch series to
address it, and I would appreciate any guidance on the preferred direction.

Cheers,
-Ali

Re: [RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c

[Mauro Carvalho Chehab]

On Sun, 2 Aug 2026 08:24:29 +0330
Ali Nasrolahi <a.nasrolahi01@gmail.com> wrote:

> Hi everyone,
> 
> I'm working on a project involving high density video processing on a
> single server using a large number of v4l2 loopback devices to route
> virtual video streams to tenants.
> 
> While doing so, I ran into the hard limit imposed by `VIDEO_NUM_DEVICES`
> (currently 256) in `drivers/media/v4l2-core/v4l2-dev.c`. Looking through
> the code and git history, this limit has been there for quite a long time.
> However, after searching the mailing list archives, I couldn't find any
> previous discussion regarding this limitation.
> 
> May I ask:
> 
> 1. Is there any internal design constraint that requires limiting the
>    number of V4L2 devices to 256 on modern kernels?

There was a constraint at the very beginning due to the way minors
were generated. If I'm not mistaken, this was long gone.

Still, having a maximum limit is desirable as there is a hard limit
in terms of the memory.

> 2. Has this limit been discussed previously, or is there any relevant
>    discussion that I may have missed?

Probably, but likely very years ago. I can't recall last time we
discussed this particular limit.

> If the current limit is no longer intentional and there's no historical
> context that I might've missed, I'd be happy to work on a patch series to
> address it, and I would appreciate any guidance on the preferred direction.

What is the maximum limit your hardware has? Can you provide some
documentation related to it?

Thanks,
Mauro

Re: [RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c

[Ali Nasrolahi]

On 26/08/02 12:57PM, Mauro Carvalho Chehab wrote:
> On Sun, 2 Aug 2026 08:24:29 +0330
> Ali Nasrolahi <a.nasrolahi01@gmail.com> wrote:
> > I'm working on a project involving high density video processing on a
> > single server using a large number of v4l2 loopback devices to route
> > virtual video streams to tenants.
> > 
> > While doing so, I ran into the hard limit imposed by `VIDEO_NUM_DEVICES`
> > (currently 256) in `drivers/media/v4l2-core/v4l2-dev.c`. Looking through
> > the code and git history, this limit has been there for quite a long time.
> > However, after searching the mailing list archives, I couldn't find any
> > previous discussion regarding this limitation.
> > 
> > May I ask:
> > 
> > 1. Is there any internal design constraint that requires limiting the
> >    number of V4L2 devices to 256 on modern kernels?
> 
> There was a constraint at the very beginning due to the way minors
> were generated. If I'm not mistaken, this was long gone.
> 
> Still, having a maximum limit is desirable as there is a hard limit
> in terms of the memory.
> 
> > 2. Has this limit been discussed previously, or is there any relevant
> >    discussion that I may have missed?
> 
> Probably, but likely very years ago. I can't recall last time we
> discussed this particular limit.
> 
> > If the current limit is no longer intentional and there's no historical
> > context that I might've missed, I'd be happy to work on a patch series to
> > address it, and I would appreciate any guidance on the preferred direction.
> 
> What is the maximum limit your hardware has? Can you provide some
> documentation related to it?

Assuming I understood your question correctly, because the workloads run
on a server, theoretically, there is no fixed limit on the number of
virtual video devices that could be used. As long as there is enough cpu
power, memory, and i/o bandwidth available, it is beneficial to be able
to add devices and, consequently, run more workloads.

That being said, to give some rough numbers, I think supporting at least
1000 to 2000 devices would likely cover most practical cases.

This is why I was wondering whether making this limit dynamically
allocated or at least configurable might be beneficial, so, for example,
mahcines with limited memory would not have to reserve an unnecessarily
large array, while systems with more resources could scale accordingly.

For some additional context, the video streams are received over the
network from various sources such as cameras and WebRTC. These streams
are then routed to v4l2loopback devices, which are used by the workloads
for processing.

Regards,
-Ali

Re: [RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c

[Hans Verkuil]

On 02/08/2026 20:25, Ali Nasrolahi wrote:
> On 26/08/02 12:57PM, Mauro Carvalho Chehab wrote:
>> On Sun, 2 Aug 2026 08:24:29 +0330
>> Ali Nasrolahi <a.nasrolahi01@gmail.com> wrote:
>>> I'm working on a project involving high density video processing on a
>>> single server using a large number of v4l2 loopback devices to route
>>> virtual video streams to tenants.
>>>
>>> While doing so, I ran into the hard limit imposed by `VIDEO_NUM_DEVICES`
>>> (currently 256) in `drivers/media/v4l2-core/v4l2-dev.c`. Looking through
>>> the code and git history, this limit has been there for quite a long time.
>>> However, after searching the mailing list archives, I couldn't find any
>>> previous discussion regarding this limitation.
>>>
>>> May I ask:
>>>
>>> 1. Is there any internal design constraint that requires limiting the
>>>    number of V4L2 devices to 256 on modern kernels?
>>
>> There was a constraint at the very beginning due to the way minors
>> were generated. If I'm not mistaken, this was long gone.
>>
>> Still, having a maximum limit is desirable as there is a hard limit
>> in terms of the memory.
>>
>>> 2. Has this limit been discussed previously, or is there any relevant
>>>    discussion that I may have missed?
>>
>> Probably, but likely very years ago. I can't recall last time we
>> discussed this particular limit.
>>
>>> If the current limit is no longer intentional and there's no historical
>>> context that I might've missed, I'd be happy to work on a patch series to
>>> address it, and I would appreciate any guidance on the preferred direction.
>>
>> What is the maximum limit your hardware has? Can you provide some
>> documentation related to it?
> 
> Assuming I understood your question correctly, because the workloads run
> on a server, theoretically, there is no fixed limit on the number of
> virtual video devices that could be used. As long as there is enough cpu
> power, memory, and i/o bandwidth available, it is beneficial to be able
> to add devices and, consequently, run more workloads.
> 
> That being said, to give some rough numbers, I think supporting at least
> 1000 to 2000 devices would likely cover most practical cases.
> 
> This is why I was wondering whether making this limit dynamically
> allocated or at least configurable might be beneficial, so, for example,
> mahcines with limited memory would not have to reserve an unnecessarily
> large array, while systems with more resources could scale accordingly.

It shouldn't be too hard to add a module option to set the max number of
devices. Minimum and default value would be 256, max 4096 (it can go higher: the
minor number has 20 bits, but I'd cap it to 4096 for now).

This module option is only available if CONFIG_VIDEO_FIXED_MINOR_RANGES is
not set, as that would cause problems (and perhaps it is time to retire
CONFIG_VIDEO_FIXED_MINOR_RANGES).

You're the first in my 20+ years of V4L experience who needed more than 256
devices, so this is not a common request :-)

Regards,

	Hans

> 
> For some additional context, the video streams are received over the
> network from various sources such as cameras and WebRTC. These streams
> are then routed to v4l2loopback devices, which are used by the workloads
> for processing.
> 
> Regards,
> -Ali
> 

Re: [RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c

[Ali Nasrolahi]

On 26/08/03 09:04AM, Hans Verkuil wrote:
> On 02/08/2026 20:25, Ali Nasrolahi wrote:
> > On 26/08/02 12:57PM, Mauro Carvalho Chehab wrote:
> >> On Sun, 2 Aug 2026 08:24:29 +0330
> >> Ali Nasrolahi <a.nasrolahi01@gmail.com> wrote:
> >>> I'm working on a project involving high density video processing on a
> >>> single server using a large number of v4l2 loopback devices to route
> >>> virtual video streams to tenants.
> >>>
> >>> While doing so, I ran into the hard limit imposed by `VIDEO_NUM_DEVICES`
> >>> (currently 256) in `drivers/media/v4l2-core/v4l2-dev.c`. Looking through
> >>> the code and git history, this limit has been there for quite a long time.
> >>> However, after searching the mailing list archives, I couldn't find any
> >>> previous discussion regarding this limitation.
> >>>
> >>> May I ask:
> >>>
> >>> 1. Is there any internal design constraint that requires limiting the
> >>>    number of V4L2 devices to 256 on modern kernels?
> >>
> >> There was a constraint at the very beginning due to the way minors
> >> were generated. If I'm not mistaken, this was long gone.
> >>
> >> Still, having a maximum limit is desirable as there is a hard limit
> >> in terms of the memory.
> >>
> >>> 2. Has this limit been discussed previously, or is there any relevant
> >>>    discussion that I may have missed?
> >>
> >> Probably, but likely very years ago. I can't recall last time we
> >> discussed this particular limit.
> >>
> >>> If the current limit is no longer intentional and there's no historical
> >>> context that I might've missed, I'd be happy to work on a patch series to
> >>> address it, and I would appreciate any guidance on the preferred direction.
> >>
> >> What is the maximum limit your hardware has? Can you provide some
> >> documentation related to it?
> > 
> > Assuming I understood your question correctly, because the workloads run
> > on a server, theoretically, there is no fixed limit on the number of
> > virtual video devices that could be used. As long as there is enough cpu
> > power, memory, and i/o bandwidth available, it is beneficial to be able
> > to add devices and, consequently, run more workloads.
> > 
> > That being said, to give some rough numbers, I think supporting at least
> > 1000 to 2000 devices would likely cover most practical cases.
> > 
> > This is why I was wondering whether making this limit dynamically
> > allocated or at least configurable might be beneficial, so, for example,
> > mahcines with limited memory would not have to reserve an unnecessarily
> > large array, while systems with more resources could scale accordingly.
> 
> It shouldn't be too hard to add a module option to set the max number of
> devices. Minimum and default value would be 256, max 4096 (it can go higher: the
> minor number has 20 bits, but I'd cap it to 4096 for now).
>
> This module option is only available if CONFIG_VIDEO_FIXED_MINOR_RANGES is
> not set, as that would cause problems (and perhaps it is time to retire
> CONFIG_VIDEO_FIXED_MINOR_RANGES).

That makes sense.
If that's okay with you, I'd be happy to work on this change and send a
corresponding patch series. Before that though, I'd just like to make
sure my understanding of the implementation is aligned with what you
have in mind.

That is:

- Add a new module parameter (e.g. `max_nr_devices`) with a default of
    256, and within the range of 256 to 4096.

- Convert the static allocations that currently depend on
    `VIDEO_NUM_DEVICES` so they honor the `max_nr_devices` parameter.
    This would apply to `video_devices`, the associated bitmaps,
    character device region registration, etc.

- Make this parameter available only when VIDEO_FIXED_MINOR_RANGES is
    disabled. Otherwise, the current limit of 256 devices should remain
    unchanged.

This is my understanding based on your comments. Please let me know if I
have misunderstood anything or if there are any implementation-specific
considerations that should be kept in mind while working on this.

> You're the first in my 20+ years of V4L experience who needed more than 256
> devices, so this is not a common request :-)

Well, v4l2 devices are so well-tested and well-supported by userspace
applications such as ffmpeg, gstreamer, and many others that they become
a natural choice for many video processing workloads :)

Thanks,
-Ali