On Sat, Jun 19, 2010 at 10:17 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > On Sat, Jun 19, 2010 at 10:12 PM, Michael Krufky <mkrufky@xxxxxxxxxxxxxx> wrote: >> On Sat, Jun 19, 2010 at 4:00 PM, Markus Rechberger >> <mrechberger@xxxxxxxxx> wrote: >>> On Sat, Jun 19, 2010 at 8:09 PM, Michael Krufky <mkrufky@xxxxxxxxxxxxxx> wrote: >>>> Mauro, >>>> >>>> This adds the ability for drivers to send the received raw payload to >>>> the dvr device, in cases of newer delivery systems that do not deliver >>>> transport stream and do not require usage of the kernel demux. In >>>> these cases, the data can be fully decoded by a userspace application >>>> / library. >>>> >>>> For a driver to deliver the raw payload, simply use the function >>>> "dvb_dmx_swfilter_raw" instead of "dvb_dmx_swfilter" or >>> >>> RAW without an additional identifier doesn't make much sense, >>> how should an application figure out what a RAW stream is? >>> Is it network data? is /dev/urandom data? how should that be handle by >>> an application. >>> There should be another 'hint' somewhere about the fileformat. >>> This somewhat influences the internal/external DVB API, without proper >>> identification it shouldn't be added as it is. >> >> Markus, >> >> "raw" as in, untouched, directly received from the device. Another >> word can be used to describe it- "pass-thru" ... I think "raw" >> suffices, however. It's not specific to any format. > > then it should take a raw driver and not use the DVB API for this. > Applications might not handle any kind of RAW if you don't tell them > what format it is. > eg. what will happen when kaffeine requests some data? I hardly doubt that it will be able to handle a raw format. You just have to be more specific with your proposed API changes. RAW + identifier somewhere about what data it is might help the applications to get along with it. And if possible don't try to break existing applications. Markus -- 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
