Tweak and move multimedia buffering information to architecture

Update the information regarding the progress of the changes upstream and
into Apertis. Move to architecture.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

content/docs/multimedia-buffering.md → content/architecture/multimedia-buffering.md

@@ -9,11 +9,9 @@ aliases = [
 ]
 +++
 
-The content below assumes the usage of clutter-gst 3.0 as integrated in
-the 2013Q4 release. Various improvements to both Gstreamer and
-clutter-gst have been incorperated in 2013Q4 and upstream. Specifically
-improved download buffering support is being upstreamed at the time of
-this writing on <https://bugzilla.gnome.org/show_bug.cgi?id=705482>
+Various improvements to both Gstreamer and clutter-gst 3.0 have been
+incorporated in Apertis and
+[upstream](https://bugzilla.gnome.org/show_bug.cgi?id=705482).
 
 # Multimedia buffering strategies
 
@@ -63,14 +61,14 @@ implementation of download buffering uses this remaining time estimate
 to decides its policy. In case expected bandwidth can be determined from
 other sources (e.g. the navigation system knows the bandwidth estimates
 along the planned route), it's possible for either an application or an
-specialized subclass of ClutterGstPlayback to override this behaviour.
+specialized subclass of `ClutterGstPlayback` to override this behaviour.
 
 For overriding the default policy an application can either use a
-subclass which overrides the should_buffer class method from
-ClutterGstPlayback or the application can listen to the should-buffer
+subclass which overrides the `should_buffer` class method from
+`ClutterGstPlayback` or the application can listen to the `should-buffer`
 signal and return whether buffering should continue or not. To do so the
 application should first connect to the signal (playbing being a
-ClutterGstPlayback):
+`ClutterGstPlayback`):
 
     g_signal_connect (player, "should-buffer", G_CALLBACK (player_should_buffer), app);