On Tue Mar 17 14:24:54 CET 2015, Vittorio Giovara gmail.com> wrote:
looks good, although I have to adjust authorship and commit log a little
libx264: Allow full-range yuv422 and yuv444 pixel formats
thanks for the contribution
No worries, everything looks appropriate to me. Glad it's useful.
B
On 18/03/15 19:16, Martin Storsjö wrote:
On Mon, 16 Mar 2015, Luca Barbato wrote:
On 16/03/15 14:44, Martin Storsjö wrote:
Even if this is a guess, it is way better than writing a zero duration
of the last sample in a fragment (because if the duration is zero,
the first sample of the next frag
On 16/03/15 14:44, Martin Storsjö wrote:
This matches what we write in tfra and tfrf since 9cbf70fa0e.
---
libavformat/movenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b9e75f4..bc5370e 100644
--- a/libavformat/move
On 16/03/15 14:44, Martin Storsjö wrote:
Adjusting it is only necessary when a sidx/tfrf/tfxd atom already has
been written for the previous fragment (since the sidx/tfrf/tfxd atoms
include the duration between the first pts of the previous fragment, to
the first pts of the new fragment).
---
l
On 16/03/15 14:44, Martin Storsjö wrote:
When reading these values from track->frag_info, the same adjustment
has already been done.
---
libavformat/movenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Ok.
___
libav-devel mailing
On 16/03/15 14:44, Martin Storsjö wrote:
For strict CFR, they should be pretty much equal, but if the stream
is VFR, there can be a sometimes significant difference.
Calculate the pts duration separately, used in sidx atoms and for
tfrf/tfxd boxes in smooth streaming ismv files.
Probably Ok.
On 16/03/15 14:44, Martin Storsjö wrote:
Since the duration is compared to the tfra durations/intervals which
are expressed in pts, calculate that here as well.
---
tools/ismindex.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
Looks fine to me.
On Mon, 16 Mar 2015, Luca Barbato wrote:
On 16/03/15 14:44, Martin Storsjö wrote:
Even if this is a guess, it is way better than writing a zero duration
of the last sample in a fragment (because if the duration is zero,
the first sample of the next fragment will have the same timestamp
as the l
It drops everything that cannot be used for re-encoding and/or
streamcopy.
---
cmdutils.c | 19 +++
doc/avtools-common-opts.texi | 3 +++
2 files changed, 22 insertions(+)
diff --git a/cmdutils.c b/cmdutils.c
index e01ad24..2b0a833 100644
--- a/cmdutils.c
+++ b/
On 18/03/15 12:10, Vittorio Giovara wrote:
---
libavutil/pixfmt.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 18/03/15 12:10, Vittorio Giovara wrote:
---
libavutil/pixdesc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index bd72c04..f991370 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1462,7 +1462,8 @@ cons
---
libavutil/pixdesc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index bd72c04..f991370 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1462,7 +1462,8 @@ const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV
---
libavutil/pixfmt.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 4763583..d1bf367 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -34,17 +34,17 @@
* Pixel format.
*
* @note
- * PIX_FMT_RGB32
13 matches
Mail list logo