top | item 16802079

Salsify – A New Architecture for Real-time Internet Video

74 points| keithwinstein | 8 years ago |snr.stanford.edu | reply

14 comments

order
[+] jremmons|8 years ago|reply
Hi everyone! I am one of the authors of Salsify. Ask me anything!
[+] aidenn0|8 years ago|reply
A practical issue I've seen with high-bandwith non-TCP transports (including video over RTP) is how they behave in the presence of multiple other streams on the line; when bandwidth becomes limited often you get one winner and a bunch of loser streams. Does salsify address this at all?
[+] bassman9000|8 years ago|reply
How does this differ from SIP/SDP?
[+] adam_gyroscope|8 years ago|reply
This is great. I used to work on on both the traffic/network side of YT and the encoding side, and could see the value of this approach handled by distribution nodes at the edge of a network.
[+] drewm1980|8 years ago|reply
It's implemented in C++, so I guess the authors are referring to pure functional style. I suppose they take and return encoder state as function arguments, rather than hiding it in a class and mutating it.
[+] Scaevolus|8 years ago|reply
Yes.

> Salsify uses a purely functional video codec to achieve this. Our video codec is 100% conformant with the Google VP8 format, but has one major trick: the encode and decode functions are purely functional, with no side effects, and represent the inter-frame “state” of the decoder explicitly. This allows Salsify to make the encoder compress a frame relative to an arbitrary decoder state, allowing the application to safely skip frames on output from the encoder, not just on input.

[+] krn94|8 years ago|reply
interesting idea, this is a topic i'm well acquainted with. curious if the authors have any thoughts on how this would extend to multiple encoding sources behind the same network interface
[+] bitrazor123|8 years ago|reply
We don;t have enough CATs . We need to make them breed fast for unique contents