Re: [Discuss-gnuradio] stream_mux tag propagation

[Martin Braun]

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>