Brad Campbell wrote:
It would be possible if you tolerate a increased syncronisation latency and a more complex detection state machine, but it's probably much easier to add a frontend notifier to the demux which announces the actual stream format. In this case change the notifier semantic so that the passed argument is an enum (LOCKED/UNLOCKED/STREAM_FMT_188BYTES/STREAM_FMT_204BYTES/STREAM_FMT_130BYTES) instead of fe_status. Thenafter you need to export the dvb_call_frontend_notifiers() function symbol so that it's accessible from the lowlevel frontend driver.Nico wrote:can you please test that stream with mplayer-cvs? It should decode it. Thanks.
Umm.. how do I get that stream out of the dvb kernel driver then?
The entire driver seems written around 188 byte packets, and therein lies the problem.
I thought the easy way to do it would be to add a second
dvb_dmx_swfilter() designed around 204 byte packets..
I can't see an *easy* and reliable way to autodetect the incoming stream, particularly one that is not succeptible to trying to switch formats when a corrupt packet is recieved.