Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCampbell Barton <ideasman42@gmail.com>2018-06-01 19:19:39 +0300
committerCampbell Barton <ideasman42@gmail.com>2018-06-01 19:19:39 +0300
commit75fc1c35070e0cf247f2d2e4cffe8a6e711522ff (patch)
tree508760dfe37e2fa864b2ee74914a979516a344fc /source/blender/blenkernel/intern/writeffmpeg.c
parent051e186d5c61dccfc776b8da9b83c598421be4e7 (diff)
Cleanup: trailing whitespace (comment blocks)
Strip unindented comment blocks - mainly headers to avoid conflicts.
Diffstat (limited to 'source/blender/blenkernel/intern/writeffmpeg.c')
-rw-r--r--source/blender/blenkernel/intern/writeffmpeg.c14
1 files changed, 7 insertions, 7 deletions
diff --git a/source/blender/blenkernel/intern/writeffmpeg.c b/source/blender/blenkernel/intern/writeffmpeg.c
index fc719634ff5..eb7ad38c456 100644
--- a/source/blender/blenkernel/intern/writeffmpeg.c
+++ b/source/blender/blenkernel/intern/writeffmpeg.c
@@ -1053,19 +1053,19 @@ fail:
}
/**
- * Writes any delayed frames in the encoder. This function is called before
+ * Writes any delayed frames in the encoder. This function is called before
* closing the encoder.
*
* <p>
- * Since an encoder may use both past and future frames to predict
- * inter-frames (H.264 B-frames, for example), it can output the frames
+ * Since an encoder may use both past and future frames to predict
+ * inter-frames (H.264 B-frames, for example), it can output the frames
* in a different order from the one it was given.
* For example, when sending frames 1, 2, 3, 4 to the encoder, it may write
* them in the order 1, 4, 2, 3 - first the two frames used for prediction,
- * and then the bidirectionally-predicted frames. What this means in practice
- * is that the encoder may not immediately produce one output frame for each
- * input frame. These delayed frames must be flushed before we close the
- * stream. We do this by calling avcodec_encode_video with NULL for the last
+ * and then the bidirectionally-predicted frames. What this means in practice
+ * is that the encoder may not immediately produce one output frame for each
+ * input frame. These delayed frames must be flushed before we close the
+ * stream. We do this by calling avcodec_encode_video with NULL for the last
* parameter.
* </p>
*/