Seeking fix from Robert Nagy. This needs testing!

[casparcg] / CHANGES.txt

diff --git a/CHANGES.txt b/CHANGES.txt
index 889c6c7af9c7150327b77632e16816695f546667..4145caa11914d4a38d1a01207a4329734d05d56e 100644 (file)
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -5,8 +5,26 @@ CasparCG 2.0.6 Stable (as compared to 2.0.4 Stable)
 \r
 General\r
 -------\r
-  o Allow for the server to work without Processing.AirSend.x86.dll to prevent a\r
-    possible GPL violation.\r
+  o iVGA: Allow for the server to work without Processing.AirSend.x86.dll to\r
+    prevent a possible GPL violation. It is available as a separate optional\r
+    download.\r
+  o iVGA: Only provide sync to channel while connected, to prevent channel\r
+    ticking too fast.\r
+  o FFmpeg: Fixed bug during deinterlace-bob-reinterlace where output fields\r
+    were offset by one field in relation to input fields.\r
+  o FFmpeg: Fixed bug in ffmpeg_consumer where an access violation occurred\r
+    during destruction.\r
+  o Frontend: Only writes elements to casparcg.config which overrides a default\r
+    value to keep the file as compact as possible.\r
+  o System audio: Patched sfml-audio to work better with oal-consumer and\r
+    therefore removed portaudio as the system audio implementation and went back\r
+    to oal.\r
+  o Flash: Changed so that the initial buffer fill of frames is rendered at a\r
+    frame-duration pace instead of as fast as possible. Otherwise time based\r
+    animations render incorrectly. During buffer recovery, a higher paced\r
+    rendering takes place, but still not as fast as possible, which can cause\r
+    animations to be somewhat incorrectly rendered. This is the only way though\r
+    if we want the buffer to be able to recover after depletion.\r
   o Version bump to keep up with CasparCG Client version.\r
 \r
 \r