[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] stream_mux tag propagation
From: |
Merlin Chlosta |
Subject: |
Re: [Discuss-gnuradio] stream_mux tag propagation |
Date: |
Sat, 23 Apr 2016 10:05:56 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
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