[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] stream_mux tag propagation
From: |
Merlin Chlosta |
Subject: |
[Discuss-gnuradio] stream_mux tag propagation |
Date: |
Thu, 21 Apr 2016 12:50:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
Hi all,
I stumbled across the stream_mux tag propagation. In my understanding, tags are
associated with one item and should be associated with the same item after
processing, if possible. The stream_mux block however does not propagate tags
like that:
Say we mux two tagged streams A and B, while A has packet_len_a=2 and B
packet_len_b=3.
A: a1 a2 a1 a2 a1 …
---^-----^-----^--- Tag packet_len_a=2
B: b1 b2 b3 b1 b2 …
---^--------^------ Tag packet_len_b=3
packet_len tags are associated with a1 / b1 (denoted with ^).
When muxed with the scheme (2, 3), the muxed stream looks like that:
a1 a2 b1 b2 b3 a1 a2 b1 …
^-----^-----^-----^------ Tag packet_len_a=2
^--------^--------^------ Tag packet_len_b=3
The tags got associated to different items! "packet_len=2" is associated with
every second item, "packet_len=3" with every third item, instead of a1 / b1.
I would assume a correct tag propagation to look like this:
a1 a2 b1 b2 b3 a1 a2 b1 …
^--------------^--------- Tag packet_len_a=2
------^--------------^--- Tag packet_len_b=3
Is that a bug in stream_mux? It means that the streams cannot be demuxed by
looking at the tags.
A basic python flowgraph is attached, it prints tags and their offsets after
stream_mux processing.
test.py
Description: Text Data
- [Discuss-gnuradio] stream_mux tag propagation,
Merlin Chlosta <=