Multiple Recordings Extension #99
Conversation
This commit includes changes to the primary specification necessary for support multiple recordings, implements the first draft of the multirecordings extension, adds support for multiple recordings to the antenna extension, and also makes some formatting changes to the primary spec.
|
This must be addressed for v0.0.2 for long-term support & usage |
|
Just thinking out loud here of usage scenarios to come back later and identify how they might be handled by this.
Does this change at all with the json-ld proposal in #108 and would there be any relation to linked recordings if one of them drops samples such as in #89? |
|
@jacobagilbert - Per our discussion yesterday, I know you've put a lot of thought into this particular PR. Do you mind outlining a list of the improvements you'd like this PR to cover for us to iterate / come to agreement on, and then drive updating the code in this PR as needed? If so, I will assign to you 🙂 |
| | -------------- | -------- | --------- | ------------ | | ||
| | `streams` | false | object | List of SigMF recordings that represent multiple streams.| | ||
|
|
||
| The `multirecordings:streams` field in a capture segment object is a JSON array |
There was a problem hiding this comment.
How does this work if there are multiple segments at nonzero offsets? What does that imply for channels other than 'this' channel?
There was a problem hiding this comment.
@jacobagilbert - I don't think I understand the gap you're pointing out. Can you explain it in a bit more detail for me?
There was a problem hiding this comment.
Sure - I think my question here has to do with this streams object being part of a captures segment, which starts at a user-defined sample (not necessarily 0) and extends until the next segment or EOF. That seems like something that might be a challenge. It also might be well thought out, so this is not to say 'this is a bad idea' -- rather 'is this what was intended'? Or perhaps this should be in global?
There was a problem hiding this comment.
I removed this from my re-write of the extension, and then realized why it was there 😅
This is needed to point from the primary recording down to children. That said, I agree with your comment about it being in captures. The new PR moves this to global.
|
@bhilburn in terms of additions, i think adding an int-type |
I like this idea, and agreed. |
|
This PR is replaced by #151 |
This is a first draft of the multiple recordings functionality that we have been discussing in #55 and #69, and that we discussed heavily in the SigMF workshop at GRCon18.
I renamed the
volatilecanonical extension that we had been discussing tomultirecordings, which supports linking multiple recordings for both multi-signal captures and multi-channel receivers. The primary mechanism by which this works is simply a new datatype and one new name/value pair in captures.Support for the new datatype,
recording, in other extensions effectively provides the capability to link recordings for that particular field. As a first draft of this, I modified theantennaextension to show how this might work.Because I changing the file structure of the primary specification, I also made the changes for compression discussed in #68. Additionally, I made some formatting changes in the markdown to prettify the tables and update the ToC. I apologize for cluttering this PR with those changes, but at this point I just as soon leave them in, here.
Please review and provide input / feedback / suggestions. This is a significant change that we have been discussing for nearly a year at this point.
Tagging the folks that were actively involved in the discussion at GRCon: @n-west @storborg @pwicks86