On Sat, Jun 19, 2010 at 4:21 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > 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. Good point - this would be for handling new frontend types that demodulate digital media in formats OTHER THAN transport stream. I agree that it should be made known to the application that transport stream should not be expected to be read from the device. What I had in mind would be for the frontend itself to report this. Frontends of type FE_ATSC or FE_OFDM or FE_QAM would be expected to provide transport stream that can be handled by the kernel demux. Newer frontend types might not deliver transport stream, such as CMMB or ATSC-MH and other mobile media broadcast systems. I thought it would be more appropriate to discuss the new frontend types in detail when it came to adding the new DVB APIv5 commands to handle the new delivery systems. Since this change doesnt change any existing APIs, while allowing for debug and development, I decided to push it before any new frontend api code. Regards, Mike -- 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
