- doc/muxers.texi: "set as as wallclock time" -> "set as wallclock time"
(user-facing manpage docs)
- libavfilter/vf_colorspace.c: "psuedo-restricted" -> "pseudo-restricted"
- libavformat/rtmppkt.c: "system-independant" -> "system-independent"
---
doc/muxers.texi | 2 +-
libavfilter/vf_colorspace.c | 2 +-
libavformat/rtmppkt.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d9e475d..ae4bc00 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -639,7 +639,7 @@ Specify @code{on} to force writing a timecode track,
@code{off} to disable it
and @code{auto} to write a timecode track only for mov and mp4 output
(default).
Setting value to @samp{pts} is applicable only for a live encoding use case,
-where PTS values are set as as wallclock time at the source. For example, an
+where PTS values are set as wallclock time at the source. For example, an
encoding use case with decklink capture source where @option{video_pts} and
@option{audio_pts} are set to @samp{abs_wallclock}.
@end table
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 5e78868..f1b079b 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -350,7 +350,7 @@ static int convert(AVFilterContext *ctx, void *data, int
job_nr, int n_jobs)
* General design:
* - yuv2rgb converts from whatever range the input was ([16-235/240]
or
* [0,255] or the 10/12bpp equivalents thereof) to an integer version
- * of RGB in psuedo-restricted 15+sign bits. That means that the
float
+ * of RGB in pseudo-restricted 15+sign bits. That means that the
float
* range [0.0,1.0] is in [0,28762], and the remainder of the int16_t
* range is used for overflow/underflow outside the representable
* range of this RGB type. rgb2yuv is the exact opposite.
diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
index 9cf3763..9635caa 100644
--- a/libavformat/rtmppkt.c
+++ b/libavformat/rtmppkt.c
@@ -382,7 +382,7 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
// FIXME:
// Writing packets is currently not optimized to minimize system calls.
- // Since system calls flush on exit which we cannot change in a
system-independant way.
+ // Since system calls flush on exit which we cannot change in a
system-independent way.
// We should fix this behavior and by writing packets in a single or in as
few as possible system calls.
// Protocols like TCP and RTMP should benefit from this when enabling
TCP_NODELAY.
--
2.49.0
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
