I was looking through the streaming logs and (after initially being quite intimidated by the lack of line breaks) was thinking of asking if the metrics meant what I thought they meant.
It turns out that asking about that is 80% (edit: 47%) of the way to making a beginner's guide - so here's a draft which may be useful.

Please comment if I have anything wrong, or if you have suggestions on information to add.

If you're after some quick information on performance or potential fixes have a look at the following pages (in fact look at them anyway, because they're very useful):

• The Steam Remote Play support page.
  
• A nice write up on how to read the in-game streaming graph by Davew_uk
  I believe that slouken's ^^ translates to "Please read above, this is good information".

As mentioned in the pages above there's an easily accessible streaming performance display available while playing (by pressing GUIDE+Y or F6).

In addition there are logs stored on the host machine which give an overview of performance at the end of a streaming session.

These logs relate to the "Display" latency shown in the on-screen streaming statistics and network latency (in streaming_log.txt) along with some information on game latency (in the *Trace.txt files).

Looking at the steaming logs lets you:

• see session overview stats
  
• drill down to see how each step the game video takes towards rendering on the remote machine is performing.
  
• compare performance of different settings (by comparing the overviews of different sessions)
  
• possibly identify specific performance bottlenecks during the beta

If you're streaming from a Windows host you can find your general Remote Play logs in the folders below (without the x86 bit if your machine is running a 32bit windows).
If using a Linux host (which I haven't yet) it should be trivial to find the streaming logs folder with a trusty find command:
For SteamOS hosts the logs are found under

For MacOS:

โพสต์ดั้งเดิมโดย ♥♥♥♥matic2000:

OS 10.6.8 Mac users should find their logs in

[user name]/Library/Application Support/Steam/logs

The two *Trace.txt files hold massive detail about audio and video at the frame by frame level. They are kept until cleared manually but only collect data while the streaming graph is displayed. A much more concise versions of them can be taken with the screenshot capture.

If you end up capturing a screenshot and detailed video/audio stats for part of a session they end up as zips in:

Looking inside one of the zips we can see they have a cut down chunk of the *Trace.txt files and a nice screenshot.

For the moment I'm just looking at the overview stats from the gaming session, which are found in the much lighter streaming_log.txt

For an example I'm going to have a look at DiRT 3, which runs pretty well on my system.

Note: The streaming_log.txt file uses UNIX style line breaks, which Notepad doesn't handle well. If viewing it on a Windows system use Wordpad/write (maybe even Word) to preserve line breaks


The header shows some basic details about the capture methods being used.
It should be mostly the same for every streaming session, but what does look interesting is the Capture method:

In this case D3 (aka annoyingly mixed-case DiRT 3) is using a newer DirectX 11 "asynchronous" capture method, meaning that it can do some extra steps in parallel.

Now we get to the performance information - the session statistics.

In this case, I'm running in 720p (ResolutionY) as my (recently upgraded) host machine has a CPU circa 2009 (an AMD Phenom II x4 945 - newer than I thought).
My SteamOS client is using VDPAU hardware decoding (DecoderName). According to wikipedia this is open source and courtesy of Nvidia - thanks Nvidia!

I've manually limited bandwidth to 10Mbps, and left framerate as Automatic - Remote Play has decided that a cap of 50 frames per second would be best.

The next chunk of SessionStats shows obvious problems that are causing poor performance:
The Slow* chunks are pretty self exlanatory.
SlowGame - caused by the game itself running slow
SlowCapture - caused by copying the displayed frame into memory taking too long
SlowConvert - Erm... TO BE COMPLETED...
SlowEncode - caused by the CPU (or hardware encoder) taking a long time to encode a frame in to x264.
SlowNetwork - caused by network connection problems, or a lot of competing traffic on the network.
SlowDecode - caused by the client machine taking a long time to decode the frames.

Next we get onto the standard format for the performance statistcs, average (Avg) and standard deviation (StdDev) statistics for the streaming performance metrics.

From the Wikipedia Page on Standard deviation[en.wikipedia.org] (give them a donation or help fix a page - they love that):
In statistics and probability theory, the standard deviation ... shows how much variation or dispersion from the average exists. A low standard deviation indicates that the data points tend to be very close to the [average] a high standard deviation indicates that the data points are spread out over a large range of values.

For our purposes if the StdDev is small compared to Avg it means that there's generally consistent performance for this metric. If it's large it means that that metric could be causing spikey delays.

If the stat measures time it'll be in milliseconds.

ServerBitrate - the video+audo bitrate that the x264 encoder streaming to the client in Kbit/s.
ClientBitrate - bitrate the client is sending data (input and data confirmation) back to the server in Kbit/s

LinkBandwidth - An estimation of available network bandwidth in Kbit/s
PingMS - Network round-trip time between the host and remote client
CaptureMS - How long it takes to make a copy of the current frame for encoding
ConvertMS - TO BE COMPLETED
EncodeMS - Time taken to compress the frame for transmission to the client. This is one of the most expensive steps and is very CPU intensive (until hardware encoding is supported).
NetworkMS - Time taken transferring the encoded frame to the client over the network. In a good setup this should be negligible.
DecodeMS - Time taken by the client to decompress the video frame
DisplayMS - Time taken to display the frame on the TV/Monitor
FrameMS - Total time taken to stream the frame.
FPS - Frames per second

As mentioned, SteamVideoTrace.txt in the logs folder is a massive file. The better way to go about looking at the frame by frame detail is to capture a screenshot zips (stored in the Steam/streaming directory). The capture of the data and screenshot is triggered in game with pressing F8 (keyboard) or GUIDE+X (controller) and can only be done while the performance graph is displayed.

It gives the same sort of detail as the performance log above, but with detail going down to individual frame by frame timings.

The below chunk is from streaming Tomb Raider (2013)
From this we can see exactly what's happening for individual frames.
Delta is math slang for change in value, so we can see that there's a 20.17ms gap between start of the frame and the start of encoding (where I guess the game is rendering the frame before it can be captured).

The StreamAudioTrace.txt has similar details for the sound data.

Some games, in this case Dark Souls (which uses Direct3D 9 and performs poorly for me over streaming), have an additional chunk between frames.
I think this is covering an additional step required for frame capture under Direct3D 9 (if anyone comments, I'll add the details in here). It also shows the Input (I), Game (G) and Display (D) latency. Given the frame rate I was initially getting in Dark Souls I'd believe that the game sometimes took 57ms to render.

Host performance
SlowGamePercent, SlowEncodePercent, CaptureMS, EncodeMS : These generally means your host CPU is struggling (or, for SlowGame, the game is just be a badly written, or use a display method Steam can't stream efficiently). I know you may hate the idea, but dropping back to 720p (or even 480p) inside the game is probably the easiest way to improve performance. Reducing resolution decreases what the machine has to render and reduces the data to capture and encode.
Hopefully hardware encoding will be supported soon (although hardware encode is reportedly not as flexible as software, so we'll have to see) and if that works out hopefully Slow Encode will become a thing of the past (on supported GPUs).

Network performance
SlowNetworkPercent, NetworkMS, PingMS: If these are high it's indicative of a poor network connection. This could be a a lot of competing traffic (data or, on wi-fi, interference) or a bad piece of network equipment (including flakey ethernet cables). If using wi-fi try moving closer to the wi-fi router and see if it helps. If on ethernet, try swapping cables/switch if you can (and if in a complex setup plug them into the same switch for a test).
Also check what the ServerBitrate is compared to LinkBandwidth. It may be that the bitrate in the Remote Play settings needs to be manually set to a lower value.

Client performance
You're probably hard pressed to see problems at the client end (unless you're experimenting to see what the bare minimum specs for Streaming are), so unless something's gone seriously awry you probably don't need to worry about the client too much.
DecoderName: If this isn't some sort of hardware decoder your client is using CPU decoding (which isn't bad, but would restrict you to lower resolutions with a slow CPU. If your GPU/CPU has a hardware h264 decoder it may just be that it's not yet supported by the beta.
SlowDecodePercent, DecodeMS: This could mean a CPU bottleneck (if software decoding). In this case, it may be worthwhile experimenting with a lower bitrate (pushing more compression back to the host, and degrading video quality), reducing host resolution, or decreasing framerate. All of these should reduce the data being decoded. Note that decreasing the framerate if you've nailed the bitrate to a set value may actually increase latency (bigger individual frames) so experiment and see what helps.
DisplayMS: Bad video bandwidth/drivers (Any suggestions??)