Holger Waechtler wrote:
Brad Campbell wrote:
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.
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.
There are no 204 byte TS packets, the extra bytes are read solomon
error correction data (which are useless for us). See EN 300 429.
Yes, it's not a standardized format, but it is commonly used as stream
format between frontends and demuxes/decoders, even mplayer and ffmpeg
accept it directly as input source.