Johannes Stezenbach wrote:
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.
maybe it makes sense to distinguish in the demux between packet_length
(the actual number of valid data bytes) and packet_stride (the offset
between sync bytes/packet start boundaries).