Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Chicken

>
> Furthermore: If it is technically possible to send and receive, demux
> and multiplex, play and record complete contents of a transponder (i. e.
> multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line
> parameter), then I myself do not see the necessity to extend the
> capabilities of one physical device dvr0 or demux0 into a multiplicity
> of devices dvr0 or demux0.
> The what and especially the why will remain Andreas Oberritters' secret.

I can only say my 2 words regarding Andreas' patch:

At least one big DVB application is using it - enigma (originally
inside tuxbox project, later enhanced by Dream Multimedia
for theirs well-known linux based set-top-boxes Dreambox).
Those boxes are selling worlwide, so userbase is wide enough
(note: I'm not in any way connected with Dream Multimedia,
so it is only my personal feeling and/or investigation).

Of course using full TS and remuxing only in user land
is not possible way for embedded application. And if you count
that there can be more then one TS input, things are getting even worst.

And as Andy wrote:
>> But sending multiple PIDs out in a TS to the open demux0 device instance
>> is just an awkward way to essentially dynamically create a dvrN device
>> associated with filter(s) set on an open demux0 instance.
>>
>> It would be better, in my opinion, to figure out a way to properly
>> create and/or associate a dvrN device node with a collection of demuxN
>> filters.
>>
>> Maybe just allow creation of a logical demux1 device and dvr1 device and
>> the use the DVB API calls as is on the new logical devices.
>>
>> I'm not a DVB apps programmer, so I don't know all the userspace needs
>> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
>> ioctl()s.
>>
>>

Well, it is also possible way. But it expands
dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so.

We definitelly need such feature.

I, personally, like DMX_OUT_TSDEMUX_TAP approach.

Rgds

/Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux