-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
executable file
·697 lines (597 loc) · 31.7 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
<!doctype html>
<html lang="en">
<!--
Page : index / MobApp
Version : 1.0
Author : Colorlib
URI : https://colorlib.com
-->
<head>
<title>Salsify — A New Architecture for Real-time Internet Video</title>
<!-- Required meta tags -->
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<meta name="description" content="Salsify - A New Architecture for Real-time Internet Video">
<meta name="keywords" content="video conferencing,real-time,video,skype">
<!-- Font -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link href="https://fonts.googleapis.com/css?family=Lobster|Rubik:300,400,500" rel="stylesheet">
<!-- Bootstrap CSS -->
<link rel="stylesheet" href="css/bootstrap.min.css">
<!-- Themify Icons -->
<link rel="stylesheet" href="css/themify-icons.css">
<!-- Owl carousel -->
<link rel="stylesheet" href="css/owl.carousel.min.css">
<!-- Main css -->
<link href="css/style.css?1525981455" rel="stylesheet">
</head>
<body data-spy="scroll" data-target="#navbar" data-offset="30">
<!-- Nav Menu -->
<div class="nav-menu fixed-top">
<div class="container">
<div class="row">
<div class="col-md-12">
<nav class="navbar navbar-dark navbar-expand-lg">
<a class="navbar-brand" href="index.html">
Salsify
</a>
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbar" aria-controls="navbar" aria-expanded="false" aria-label="Toggle navigation"> <span class="navbar-toggler-icon"></span> </button>
<div class="collapse navbar-collapse" id="navbar">
<ul class="navbar-nav ml-auto">
<li class="nav-item"> <a class="nav-link active" href="#home">Home <span class="sr-only">(current)</span></a> </li>
<li class="nav-item"> <a class="nav-link" href="#in-action">Demo Video</a></li>
<li class="nav-item"> <a class="nav-link" href="#paper">Paper</a></li>
<li class="nav-item"> <a class="nav-link" href="#tech-video">Tech Video</a></li>
<li class="nav-item"> <a class="nav-link" href="#faq">FAQ</a></li>
<li class="nav-item"><a href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf" class="btn btn-outline-light my-3 my-sm-0 ml-lg-3">Paper</a></li>
<li class="nav-item"><a href="https://github.com/excamera/alfalfa" class="btn btn-outline-light my-3 my-sm-0 ml-lg-3">Code</a></li>
</ul>
</div>
</nav>
</div>
</div>
</div>
</div>
<header class="bg-gradient" id="home">
<div class="container mt-5 pb-5">
<div class="row">
<div class="col-lg-12 text-left mb-3">
<h1 class="display-4">Video is better when the codec and transport work together.</h1>
</div>
</div>
<div class="row align-items-top">
<div class="col-lg-6">
<p class="tagline pb-4">
Salsify is a new design for real-time Internet video
that <strong>jointly controls</strong>
a video codec and a network transport protocol.
Current systems (Skype, Facetime, WebRTC)
run these components independently,
which produces more glitches and stalls when the network is unpredictable.
</p>
<p class="tagline pb-4">
In testing, Salsify consistently outperformed today’s
real-time video systems
in both quality and delay.
</p>
<p class="tagline">
Salsify is a research project at Stanford
University. The
<a href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf">
research paper</a> and <a href="https://github.com/excamera/salsify-results">raw data</a> are open-access, and the <a href="https://github.com/excamera/alfalfa">implementation</a> is open-source.
</p>
<p class="pt-4 pb-1">
<a href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf" class="btn btn-primary">Research paper</a>
<a href="https://github.com/excamera/alfalfa" class="btn btn-light">Code</a>
<a href="https://engineering.stanford.edu/magazine/article/can-computer-science-take-glitch-and-stall-out-real-time-video" class="btn btn-light">News release</a>
</p>
</div>
<div class="col-lg-6 text-center">
<div class="results-plot-container">
<img src="images/att-results.svg" class="results-plot" />
<p class="caption mt-2">
Results on an emulated AT&T LTE connection.
</p>
</div>
</div>
</div>
</div>
</header>
<div class="section light-bg" id="in-action">
<div class="container text-center">
<h2 class="pb-3">Salsify in Action</h2>
<div class="row mb-2 align-items-center">
<div class="col-lg-6 mb-2">
<div class="video-wrapper" style="width:100%;">
<iframe src="https://www.youtube-nocookie.com/embed/jaDelb4JnP4?rel=0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen style="margin:0 auto;"></iframe>
</div>
</div>
<div class="col-lg-6 text-left">
<p class="video-description">
Salsify (left side) is compared with WebRTC in Google Chrome 65
(right side) over a network path whose data rate varies with time,
then over a network that experiences occasional one-second
outages. Both Salsify and WebRTC experience glitches when the
network is degraded, but Salsify's joint control of the video
codec and transport protocol allows it to recover more quickly,
matching the compressed video output to the network's varying
capacity.
</p>
</div>
</div>
</div>
<div class="container">
</div>
</div>
<!-- // end .section -->
<!--<div class="section light-bg" id="features">
<div class="container">
<div class="section-title">
<small>HIGHLIGHTS</small>
<h3>Features you love</h3>
</div>
<div class="row">
<div class="col-12 col-lg-4">
<div class="card features">
<div class="card-body">
<div class="media">
<span class="ti-face-smile gradient-fill ti-3x mr-3"></span>
<div class="media-body">
<h4 class="card-title">Simple</h4>
<p class="card-text">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer rutrum, urna eu pellentesque </p>
</div>
</div>
</div>
</div>
</div>
<div class="col-12 col-lg-4">
<div class="card features">
<div class="card-body">
<div class="media">
<span class="ti-settings gradient-fill ti-3x mr-3"></span>
<div class="media-body">
<h4 class="card-title">Customize</h4>
<p class="card-text">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer rutrum, urna eu pellentesque </p>
</div>
</div>
</div>
</div>
</div>
<div class="col-12 col-lg-4">
<div class="card features">
<div class="card-body">
<div class="media">
<span class="ti-lock gradient-fill ti-3x mr-3"></span>
<div class="media-body">
<h4 class="card-title">Secure</h4>
<p class="card-text">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer rutrum, urna eu pellentesque </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
-->
<div class="section" id="paper">
<div class="container">
<div class="row mb-2 align-items-center">
<div class="col-lg-6">
<div class="box-icon"><a class="ti-write gradient-fill ti-3x" href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf"></a></div>
<h3>Research Paper</h3>
<p>
Sadjad Fouladi, John Emmons, Emre Orbay, Catherine Wu,
Riad S. Wahby, and Keith Winstein. “<a
href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf">Salsify:
Low-Latency Network Video through Tighter Integration
between a Video Codec and a Transport Protocol.</a>” In
15th USENIX Symposium on Networked Systems Design and
Implementation (NSDI ’18), pp. 267–282. USENIX
Association, 2018.
</p>
</div>
<div class="col-lg-6">
<div class="paper-wrapper">
<a class="nsdi-paper" href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf"></a>
</div>
</div>
</div>
</div>
</div>
<!-- // end .section -->
<div class="section pt-5 light-bg" id="tech-video">
<div class="container">
<div class="row mb-2 align-items-center">
<div class="col-lg-6">
<div class="box-icon"><a class="ti-microphone gradient-fill ti-3x" href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf"></a></div>
<h3>Tech Video</h3>
<p>
Salsify was presented at <a
href="https://www.usenix.org/conference/nsdi18">15th USENIX
Symposium on Networked Systems Design and Implementation</a>. The talk
was given April 10, 2018.
</p>
<p>
<a href="https://www.youtube.com/watch?v=LPj2ffe7Isk" class="btn btn-light btn-lighter">Watch</a>
<a href="https://www.usenix.org/sites/default/files/conference/protected-files/nsdi18_slides_fouladi.pdf" class="btn btn-light btn-lighter">View The Slides</a>
</p>
</div>
<div class="col-lg-6">
<div class="video-wrapper">
<iframe src="https://www.youtube-nocookie.com/embed/LPj2ffe7Isk?rel=0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen style="margin:0 auto;"></iframe>
</div>
</div>
</div>
</div>
</div>
<div class="section pt-5" id="faq">
<div class="container">
<div class="section-title">
<h3>Frequently Asked Questions</h3>
</div>
<div class="row">
<div class="col-md-12">
<h4 class="mb-3">Is this a startup company?</h4>
<p class="mb-5">No.</p>
<h4 class="mb-3">Are you sure? Your website looks like a startup company’s.</h4>
<p class="mb-5">It's just the HTML template! They all look like this. We promise, this is an academic research project at a university. The code is open-source, and the paper and raw data are open-access. The hope is that these ideas will influence the industry and lead to better real-time video for everybody.</p>
<h4 class="mb-3">What is the main idea of Salsify?</h4>
<p class="mb-3">Today's real-time video apps are
built out of two separate components: a “video codec” that compresses
video, and a “transport protocol” that transmits packets of data and
estimates how many can be sent without overloading the network. These
components are designed and built separately, often by different
companies, then combined into an overall program such as Skype or
FaceTime.</p>
<p class="mb-3">Each component has its own control loop. The transport protocol has a “congestion-control” that tries to figure out how
fast the network is, and the codec has its own “rate-control” algorithm
that tries to make the compressed video match what the transport
protocol is telling it. We found that these dueling control loops—which are
found in Skype, FaceTime, Hangouts, and the WebRTC reference implementation—can yield
suboptimal results over unpredictable networks.</p>
<p class="mb-5">
Salsify’s main contribution is in <strong>jointly controlling</strong> the frame-by-frame
control of compression and the packet-by-packet control of
transmission in a single control loop. This lets the video stream track
the network’s varying capacity, avoiding stalls <a href="#in-action">(see the video above)</a>.
<h4 class="mb-3">How big is Salsify’s improvement, overall?</h4>
<p class="mb-5">
The results
are <a href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf">in
the paper</a>, and
the <a href="https://github.com/excamera/salsify-results">raw data</a>
are available on GitHub, but bottom line, on average across our
network tests, compared with Skype, FaceTime, Hangouts, and Chrome's
WebRTC with and without VP9-SVC, <strong>Salsify reduced delay (at the 95th
percentile) by 4.6×, while also improving SSIM by about 60% (2.1
dB)</strong>.
</p>
<h4 class="mb-3">Can I use Salsify to talk to my parents?</h4>
<p class="mb-5">
You probably don’t want to, at least not
yet. The <a href="https://github.com/excamera/alfalfa">implementation</a>
is only for Linux and doesn't have audio. The value is mostly in
demonstrating the benefit of Salsify’s design and in allowing
other researchers (and industry) to replicate our results, with the
intent that Salsify’s ideas will be incorporated by others
and improve the quality of real-time video in many applications.
</p>
<h4 class="mb-3">How did you evaluate Salsify?</h4>
<p class="mb-5">
We played the same video through Salsify’s sender, and the
sender programs for Skype, FaceTime (on a Mac), Google Hangouts, and
WebRTC in Google Chrome. We allowed the sender to transmit over an
emulated network to its receiver, captured the receiver’s video,
and calculated the delay and quality of each frame. We tested different
kinds of emulated networks: LTE, slower cellular links, and long-distance Wi-Fi.
</p>
<h4 class="mb-3">In detail, how did you evaluate Salsify?</h4>
<div class="row measurement-sys align-items-center pt-3 mb-4">
<div class="col-md-6 mb-4">
<a href="images/testbed.jpeg" target="_blank"><img src="images/testbed.jpeg"></a>
</div>
<div class="col-md-6 pl-5">
<a href="images/measurement.svg" target="_blank"><img src="images/measurement.svg"></a>
</div>
</div>
<p class="mb-5">
We built a <a href="https://github.com/excamera/alfalfa">prototype
implementation</a> of Salsify, including a video-aware transport
protocol, a VP8 video codec with the ability to save/restore internal
state, and a unified control loop. We then compared it end-to-end with
Skype, FaceTime, Hangouts, and WebRTC (as implemented in Google
Chrome, with and without scalable/layered video coding). We emulated a
hardware webcam and played a reproducible 720p60 test video through
each program, with each frame tagged with a 2D barcode. We timestamped
each frame on exit, using the hardware clock on a Blackmagic Decklink
card. The unmodified sender transmitted over an emulated time-varying
network connection (using <a href="https://github.com/keithw/multisend">cellsim</a>/<a href="http://mahimahi.mit.edu">mahimahi</a>), to an unmodified
receiver. We ran the receiver program fullscreen on an HDMI output,
which we captured and timestamped using the same Blackmagic hardware
clock that timestamped the frame when emitted. We recognized the 2D
barcode (which was still recognizable even after lossy video
compression), and computed the delay and quality (structural
similarity, or SSIM) of each frame. To the best of our knowledge,
this is the first <a href="https://github.com/excamera/salsify-results">dataset</a>
giving an end-to-end frame-by-frame measurement of the quality and delay of a diverse array of
commercial and research codebases for real-time Internet video.
</p>
<h4 class="mb-3">Don't current systems have some pretty sophisticated mechanisms for recovering from packet loss?</h4>
<p class="mb-3">
They certainly have
<a href="https://www.callstats.io/2015/10/30/error-resilience-mechanisms-webrtc-video/">sophisticated
mechanisms at their disposal</a>; video transmission over a lossy
channel is a very well-studied problem. However, when we did the
measurement carefully, we found that these mechanisms don't always work
that well in practice, and Salsify's (much simpler, functional) approach
works as well or better <a href="#in-action">(see the video above)</a>,
or Figure 6(d) of the paper.
</p>
<p class="mb-5">
There may not be an academically interesting reason for
this—perhaps commercial systems just have a large toolbox of
loss-recovery strategies but aren't well-tuned about when to use each
one, at least not for the network conditions that we
evaluated. Salsify’s main innovation is in jointly controlling
codec rate-control with transport congestion-control, not in inventing
a better mechanism for loss recovery, so we don't want to overstress
this point. However, we do think that our evaluation may be the first
end-to-end measurement of frame-by-frame video quality and delay
across a variety of current commercial and research codebases, and to
the extent the findings show surprising weaknesses in the commercial
status quo, the lesson may be that more such measurements are in order.
</p>
<h4 class="mb-3">Why do you need your video codec to be implemented
in a purely functional style?</h4>
<p class="mb-3">
Current video codecs, including ours, cannot reliably predict the
compressed size of an individual video frame in advance. Instead,
codecs generally try to control the “bitrate” over several
frames (e.g. through a VBV constraint). If the encoder makes a frame that's too big compared with
what the transport protocol thinks the network can accommodate, the
application will generally send it anyway, and then, knowing
that it has probably just caused congestion, the application might
then pause <em>input</em> to the video encoder for a little bit to allow
the congestion that it just caused to clear.
</p>
<p class="mb-3">
This is not a great strategy, because the network still gets
congested. A better plan, if the encoder makes a compressed frame
that's too big, would be to tell the encoder to try again—either
by re-encoding the same frame with lower quality settings, or by
plucking a new frame off the camera and encoding that more-recent
frame—with quality settings more likely to produce a compressed
frame that won't congest the network. In effect, rather than having a
fixed frame rate, it would be better to send frames only at times when
they won't provoke packet loss and queueing delay.
</p>
<p class="mb-3">
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 <em>output</em> from
the encoder, not just on input.
</p>
<p class="mb-5">
Salsify's codec allows the sender to send frames when it's pretty sure
they won't congest the network (discarding already-encoded frames if
necessary) rather than sticking to a fixed frame rate. It also allows
the codec to produce frames that more closely match the available
network capacity, by simply producing two versions of each frame:
one with slightly higher quality than the previous successful option,
and one with slightly lower quality. The application chooses from
among these options (or no option) after seeing the actual compressed size
of each option.
</p>
<h4 class="mb-3">Okay, but if you didn't have a purely functional video codec,
could you still achieve Salsify’s performance?</h4>
<p class="mb-5">
Maybe! <strong>If</strong> mainstream video encoders could allow the
application to discard already-encoded frames, and <strong>if</strong>
they could accurately hit a frame-size target, then Salsify's purely
functional video codec would probably not be necessary. The first
<em>may</em> be achievable with smart use of reference invalidation
(although not clear—what about ancillary inter-frame state
stored in probability tables?). The second <em>may</em> be achievable
with more work (and more cycles) put into intra-frame rate control.
So, it's possible. But it was a heck of a lot easier to do when
the codec exposes a way to save and restore its internal state.
</p>
<h4 class="mb-3">When you say “purely functional video codec,” does it mean anything more than being able to dump and restore the internal state of the encoder and decoder between frames?</h4>
<p class="mb-5">
No, that’s pretty much all we mean by it. If you have that, then
the decoder can be described as a function that takes in a state and a
compressed frame, and produces a modified state and an image for
display. The encoder can be described as a function that takes in a
state, an image, and some sort of quality settings, and produces a
modified state and a compressed frame.
</p>
<h4 class="mb-3">Does this require a software codec?</h4>
<p class="mb-5">
Not really—it requires a codec that can export and import its
internal state, or can otherwise accurately hit a target size for an
individual compressed frame and can “cancel” an
already-encoded frame (including its effect on references and
probability tables). Whether the codec is implemented in software
or hardware isn’t important to Salsify.
</p>
<h4 class="mb-3">How is it possible that a VP8 encoder written by one graduate student in a few months can outperform production-grade VP9 and H.264 encoders?</h4>
<p class="mb-5">
Because it’s not a fair fight between codecs—Salsify is a different way
of putting the pieces (compression and transmission) together, not a
new compression format. To the extent these results persuade you of
anything, they should make you think that in the domain of Internet
videoconferencing, further innovation in video <em>codecs</em> may
have reached the point of diminishing returns, but
video <em>systems</em> still have lots of low-hanging fruit.
</p>
<h4 class="mb-3">Is Salsify a “cross-layer” approach?</h4>
<p class="mb-5">
Not exactly, at least not in the way the term is typically used to
apply to systems
like <a href="http://pages.cs.wisc.edu/~suman/pubs/apex.pdf">Apex</a>
or <a href="http://people.csail.mit.edu/szym/softcast/tr2.pdf">SoftCast</a>.
These systems reach into the physical layer and jointly handle
“source coding” (video compression) and “channel
coding” (error correction coding and modulation). By contrast,
Salsify is a conventional Internet application that sends UDP
datagrams point-to-point over the Internet, just like Skype, FaceTime,
and WebRTC (and almost like Hangouts, which sends UDP datagrams
through a nearby Google CDN node).
</p>
<h4 class="mb-3">What part of Salsify is new?</h4>
<p class="mb-3">
Really just the overall architecture. The compressed video format is
Google’s <a href="https://en.wikipedia.org/wiki/VP8">VP8</a>,
finalized in 2008 and largely superseded
by <a href="https://en.wikipedia.org/wiki/VP9">VP9</a> and
H.265. Salsify’s purely functional VP8 encoder/decoder is a
lightly modified version of the one we used last year
for <a href="http://ex.camera">ExCamera</a>, when the benefit was in
allowing us to subdivide video encoding into tiny threads (smaller
than the interval between key frames) and parallelize across thousands
of threads on AWS Lambda. This year, the benefit is in allowing
Salsify to explore an execution path of the video codec without
committing to it. Salsify's congestion-control scheme is based
on <a href="http://alfalfa.mit.edu">Sprout-EWMA</a>, which in turn
is based on earlier work in <a href="http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/95/pp.pdf">packet-pair</a> and packet-train estimation
of available bandwidth. Salsify's loss-recovery strategy is related
to <a href="https://mosh.org">Mosh’s</a> “p-retransmissions.”
</p>
<p class="mb-5">
What’s new, then, is the way the pieces are put together: the
joint control of codec rate-control and transport congestion-control,
and the use of a functional video codec to send encoded frames only at
moments when the network can accomodate them.
</p>
<h4 class="mb-3">Can industry incorporate Salsify?</h4>
<p class="mb-5">
Legally, sure, we'd love that, and we’re eager to
help. Technically, it may not be so easy. It would be a lot simpler if
Salsify were just a better video codec, or a better transport
protocol. Because Salsify is instead a better way of putting the
pieces together, we expect it will be harder to retrofit into an
existing application without significant refactoring. In our
conversations with industry, we’ve found that the burden of
proof will be high to demonstrate (1) that Salsify’s gains are
real, and (2) that they can’t be achieved with less-intrusive
surgery to existing applications.
</p>
<h4 class="mb-3">What would you say to tomorrow’s codec implementers?</h4>
<p class="mb-5">
Standardize an interface to export and import the encoder’s and
decoder’s internal state between frames! Even if the format of that state is
opaque and unstandardized across codecs, that’s okay. Last
year, we demonstrated how doing so can
allow <a href="http://ex.camera">fine-grained parallelization of
video encoding</a>. This year, it’s letting Salsify explore
execution paths of the video codec without committing to them (to
match each frame’s compressed size to the network capacity, and
skip already-encoded frames without penalty). We can’t prove
that a save/restore interface is strictly necessary to achieve this
performance, but it makes things a heck of a lot easier and
simpler. This should be a requirement for all codecs going forward: exposing
the encoder and decoder only as stream operators with inaccessible, mutable,
internal state is terribly limiting and inconvenient.
</p>
<h4 class="mb-3">Why the name “Salsify”?</h4>
<p class="mb-5">
It's not a very interesting reason. Salsify comes from an older
project called “ALFalfa,” for the use
of <a href="https://en.wikipedia.org/wiki/Application-layer_framing">Application
Layer Framing</a> in video. Alfalfa gave way
to <a href="https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/winstein">Sprout</a>,
a congestion-control scheme intended for real-time applications, and
now Salsify, a new design where congestion-control (in the transport
protocol) and rate control (in the video codec) are jointly controlled.
Alfalfa, Sprout, and Salsify are all plantish foods.
</p>
<h4 class="mb-3">Who’s responsible for Salsify?</h4>
<p class="mb-3">
Salsify is led by <a href="https://github.com/sadjad">Sadjad
Fouladi</a>, a doctoral student in computer science at Stanford
University, along with fellow Stanford students John Emmons, Emre
Orbay, and Riad S. Wahby, as well as Catherine Wu, a junior at
Saratoga High School in Saratoga, California. The project is advised
by <a href="https://cs.stanford.edu/~keithw">Keith Winstein</a>, an
assistant professor of computer science.
</p>
<p class="mb-5">
Salsify was funded by the National Science Foundation and the Defense
Advanced Research Projects Agency (DARPA). Salsify has also received
support from Google, Huawei, VMware, Dropbox, Facebook, and
the <a href="https://platformlab.stanford.edu">Stanford Platform
Lab</a>.
</p>
</div>
</div>
</div>
</div>
<!-- // end .section -->
<!--<div class="section bg-gradient">
<div class="container">
<div class="call-to-action">
<div class="box-icon"><span class="ti-mobile gradient-fill ti-3x"></span></div>
<h2>Download Anywhere</h2>
<p class="tagline">Available for all major mobile and desktop platforms. Rapidiously visualize optimal ROI rather than enterprise-wide methods of empowerment. </p>
<div class="my-4">
<a href="#" class="btn btn-light"><img src="images/appleicon.png" alt="icon"> App Store</a>
<a href="#" class="btn btn-light"><img src="images/playicon.png" alt="icon"> Google play</a>
</div>
<p class="text-primary"><small><i>*Works on iOS 10.0.5+, Android Kitkat and above. </i></small></p>
</div>
</div>
</div>-->
<!-- // end .section -->
<div class="light-bg py-5" id="contact">
<div class="container">
<div class="row">
<div class="col-lg-6 text-center text-lg-left">
<p class="mb-2"> <span class="ti-location-pin mr-2"></span>Stanford Computer Science, 353 Serra Mall, Stanford, CA</p>
<div class=" d-block d-sm-inline-block">
<p class="mb-2">
<span class="ti-email mr-2"></span> <a class="mr-4" href="mailto:[email protected]">[email protected]</a>
</p>
</div>
</div>
<!--<div class="col-lg-6">
<div class="social-icons">
<a href="#"><span class="ti-facebook"></span></a>
<a href="#"><span class="ti-twitter-alt"></span></a>
<a href="#"><span class="ti-instagram"></span></a>
</div>
</div>-->
</div>
</div>
</div>
<!-- // end .section -->
<footer class="my-5 text-center">
<!-- Copyright removal is not prohibited! -->
<p class="mb-2"><small>TEMPLATE BY <a href="https://colorlib.com">COLORLIB</a></small></p>
<!--<small>
<a href="#" class="m-2">PRESS</a>
<a href="#" class="m-2">TERMS</a>
<a href="#" class="m-2">PRIVACY</a>
</small>-->
</footer>
<!-- jQuery and Bootstrap -->
<script src="js/jquery-3.2.1.min.js"></script>
<script src="js/bootstrap.bundle.min.js"></script>
<!-- Plugins JS -->
<script src="js/owl.carousel.min.js"></script>
<!-- Custom JS -->
<script src="js/script.js"></script>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-96350853-2"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-96350853-2');
</script>
</body>
</html>