Add support for parsing the VLA header extension. #412
Conversation
|
@algesten would you consider SmallVec? https://docs.rs/smallvec/latest/smallvec/ |
|
Is there a theoretical max? In the VP9-parser we just merged, we had fixed layer counts and thus could use arrays: https://github.com/algesten/str0m/pull/407/files#diff-b1299bad20a1ca94d8534b9fe54f6a3005f5e374c91b7f10c098836077733e74R271 |
|
I don't think it's sent often enough to worry about perf at this point. I'd like to err on the side of correct and readable. About theoretical maxes: they aren't realistic. You could theoretically have 5 simulcast streams and 4 spatial layers each, which is 20 spatial layers. But realistically you'd have 1 simulcast stream with 3 spatial layers or 3 simulcast streams with 1 spatial layer each, which is 3 spatial layers. If you went with u64s for each temporal layer, then that would be 40 bytes per spatial layer, or 800 bytes total. You could cut that in half by limiting bitrates to reasonable values, so 400 bytes. Plus the optional resolution and framerate, which are bytes, which would be another 60 bytes (860 or 460 total, depending if you use u64 or u32 for bitrates). Maybe that's not too big, but it feels somewhat large. I still feel like this isn't something to worry about unless it shows up on a perf profile with real traffic, which I doubt it every will be. |
|
I got rid of one VecDeque by using an Iterator. The other two could be theoretically be replaced with an array that has a maximum size. Those only exist in the parse function and would affect the size of the value returned. |
|
Sounds good! Let cargo fmt and merge! |
|
OK, I did cargo fmt and I added some comments about max sizes for a future developer that wants to use arrays instead of Vec/VecDeque. |
No description provided.