The mux is easy because it can be dynamic by analysing the input tagged streams. A demux needs logic to figure out how to demux a stream. An example is the header_payload_demux, which has a massive amount of logic (and still relies on outside blocks).
M On 04/23/2016 01:05 AM, Merlin Chlosta wrote: > On 21.04.2016 13:34, Andrej Rode wrote: >>> Is that a bug in stream_mux? It means that the streams cannot be demuxed by >>> looking at the tags. >> There is no special processing for stream tags in stream_mux. It simply >> takes >> the input streams and copies them input-wise into the output buffer. Stream >> tags are propagated according to their initial offset at the input. And >> there >> you get behaviour you described. >> >> Did you have a look at tagged_stream_mux ? Maybe it will serve your needs? > > The tagged_stream_mux uses the packet_len tags to determine the input > lengths. It outputs a new packet_len that is the sum of the input > packet_lens. So here you also loose information about the streams that were > muxed. > > What sense would the standard tag propagation make in this case? > > The context is that I was looking for a demux-block to separate data that > comes out of my custom block. I did not find any demux-block -- and then > investigated how the muxer works to understand why there's no demuxer. In > this case the only way a demuxer could work is to have the muxer scheme > constant and share it to muxer and demuxer. > > --Merlin Chlosta > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
