On Mon, Mar 16, 2015 at 4:19 PM, Sean McGovern gsean...@gmail.com wrote:
I definitely have no intention to support old ( 2 years) trees. If someone
wants to step up to the plate, go ahead.
I am all for dropping 0.8, but there might still be need of additional
point releases. Just drop the
On Mon, Mar 16, 2015 at 1:09 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
---
tests/fate/screen.mak | 3 +++
tests/fate/video.mak | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
Move *to* the appropriate...
--
Vittorio
___
This is a leftover from the static to dynamic vlc table conversion.
---
libavcodec/hqxvlc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/hqxvlc.c b/libavcodec/hqxvlc.c
index 9bb8adb..d185e86 100644
--- a/libavcodec/hqxvlc.c
+++ b/libavcodec/hqxvlc.c
@@ -2138,10 +2138,6 @@
---
tests/fate/screen.mak| 3 +++
tests/ref/fate/tscc2-mov | 16
2 files changed, 19 insertions(+)
create mode 100644 tests/ref/fate/tscc2-mov
diff --git a/tests/fate/screen.mak b/tests/fate/screen.mak
index 12f8326..7706916 100644
--- a/tests/fate/screen.mak
+++
On 16/03/15 14:22, Vittorio Giovara wrote:
On Mon, Mar 16, 2015 at 1:19 PM, Luca Barbato lu_z...@gentoo.org wrote:
As produced by Camtasia 4.
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index cd532aa..92b743e 100644
---
On 16/03/15 14:22, Vittorio Giovara wrote:
---
tests/fate/screen.mak| 3 +++
tests/ref/fate/tscc2-mov | 16
2 files changed, 19 insertions(+)
create mode 100644 tests/ref/fate/tscc2-mov
diff --git a/tests/fate/screen.mak b/tests/fate/screen.mak
index 12f8326..7706916
On Wed, Mar 11, 2015 at 7:25 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
Prevents unsigned overflow and variable truncation.
Bug-Id: CID 603186
---
libavcodec/aacsbr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
ping
--
Vittorio
On Mon, Mar 16, 2015 at 9:19 AM, Diego Biurrun di...@biurrun.de wrote:
---
This one appears to add little signal, but a lot of noise.
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
ok
--
Vittorio
___
libav-devel mailing list
On 16/03/15 10:42, Vittorio Giovara wrote:
On Mon, Mar 16, 2015 at 9:40 AM, Luca Barbato lu_z...@gentoo.org wrote:
On 16/03/15 07:28, Vittorio Giovara wrote:
On Sun, Mar 15, 2015 at 10:51 PM, Luca Barbato lu_z...@gentoo.org wrote:
Bug-Id: 833
---
libavformat/matroska.c | 1 +
1 file
On 16/03/15 11:42, Vittorio Giovara wrote:
From: Paul B Mahol one...@gmail.com
Signed-off-by: Paul B Mahol one...@gmail.com
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 68ddd32..fcd696a 100644
---
On 16/03/15 12:58, Vittorio Giovara wrote:
From: Carl Eugen Hoyos ceho...@ag.or.at
Instead check for all mov code-points when demuxing avi
and print a warning if a video codec is found like this.
Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
---
libavformat/Makefile | 2 +-
---
tests/fate/screen.mak | 3 +++
tests/fate/video.mak | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/fate/screen.mak b/tests/fate/screen.mak
index bd6ace6..12f8326 100644
--- a/tests/fate/screen.mak
+++ b/tests/fate/screen.mak
@@ -29,6 +29,9 @@ fate-fraps-v5: CMD
On 16/03/15 14:02, Vittorio Giovara wrote:
From: Michael Niedermayer michae...@gmx.at
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 053038b..99fee62 100644
---
On Mon, Mar 9, 2015 at 1:33 AM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
Useful to understand where and in what execution state a certain message
is generated. It is enabled only when optimizations are disabled, since
function names are not print otherwise. It is possible to disable
When automatically flushing fragments based on set conditions
(fragmentation on keyframes, after some interval or byte size),
we already have the next packet for one stream - use this for setting
the duration of the last packet in the flushed fragment correctly.
This avoids having to adjust the
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/movenc.c
+++ b/libavformat/movenc.c
@@ -2542,7
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(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 85d865e..b6dd456 100644
--- a/libavformat/movenc.c
+++
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(-)
diff --git a/tools/ismindex.c b/tools/ismindex.c
index 387b185..f3bfec0 100644
---
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 last sample in the previous one).
Since we
On Mon, Mar 16, 2015 at 1:19 PM, Luca Barbato lu_z...@gentoo.org wrote:
As produced by Camtasia 4.
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index cd532aa..92b743e 100644
--- a/libavformat/isom.c
+++
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).
---
libavformat/movenc.c | 6 --
1 file
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 last sample in the previous one).
Since we normally don't require libavformat muxer
This avoids that the mp4 muxer does a similar heuristic, adjusting
the timestamps in a way that the dash muxer doesn't know the actual
timestamps written to the file in the end. By making sure that the
mp4 muxer internal heuristic isn't applied, we know the exact
timestamps written to file, so
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.
Also make sure to reduce the duration of sidx entries
On Mon, 16 Mar 2015, Vittorio Giovara wrote:
This is a leftover from the static to dynamic vlc table conversion.
---
libavcodec/hqxvlc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/hqxvlc.c b/libavcodec/hqxvlc.c
index 9bb8adb..d185e86 100644
--- a/libavcodec/hqxvlc.c
+++
On 11/03/15 20:25, Vittorio Giovara wrote:
Prevents unsigned overflow and variable truncation.
Bug-Id: CID 603186
---
libavcodec/aacsbr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index 3da8a5b..b389e10 100644
---
On 16/03/15 11:34, Vittorio Giovara wrote:
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index db91749..02588bc 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -39,6 +39,7 @@ const AVCodecTag ff_codec_bmp_tags[]
From: Michael Niedermayer michae...@gmx.at
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 053038b..99fee62 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@
On Mon, Mar 16, 2015 at 11:47:11AM +0100, Luca Barbato wrote:
On 16/03/15 11:42, Vittorio Giovara wrote:
From: Paul B Mahol one...@gmail.com
Signed-off-by: Paul B Mahol one...@gmail.com
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c
TSCC2 seems to put esds atom despite not containing MPEG-4 video.
Although lavf mov demuxer properly detects codec id as TSCC2, it still
tries to parse esds and since it's no MPEG-4 video it resets the codec
id, preventing video to be decoded.
---
libavformat/mov.c | 2 +-
1 file changed, 1
From: Carl Eugen Hoyos ceho...@ag.or.at
Instead check for all mov code-points when demuxing avi
and print a warning if a video codec is found like this.
Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
---
libavformat/Makefile | 2 +-
libavformat/avidec.c | 12
On 16/03/15 07:28, Vittorio Giovara wrote:
On Sun, Mar 15, 2015 at 10:51 PM, Luca Barbato lu_z...@gentoo.org wrote:
Bug-Id: 833
---
libavformat/matroska.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 237f26f..47fdea6 100644
---
On Mon, Mar 16, 2015 at 9:40 AM, Luca Barbato lu_z...@gentoo.org wrote:
On 16/03/15 07:28, Vittorio Giovara wrote:
On Sun, Mar 15, 2015 at 10:51 PM, Luca Barbato lu_z...@gentoo.org wrote:
Bug-Id: 833
---
libavformat/matroska.c | 1 +
1 file changed, 1 insertion(+)
diff --git
It uses 6 registers, unbreaks building on hardened x86 system.
Bug-Id: gentoo/541930
CC: libav-sta...@libav.org
---
Now with the needed header (failed at git commit --amend -a again)
libavcodec/x86/mathops.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/x86/mathops.h
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index db91749..02588bc 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -39,6 +39,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
{ AV_CODEC_ID_H264, MKTAG('V',
The current behavior may produce packets in a different order
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream based on
timestamp, which may not necessarily match the original packet
order.
This makes implementing certain
I definitely have no intention to support old ( 2 years) trees. If someone
wants to step up to the plate, go ahead.
With our new release schedule, maintaining more than 3-4 trees is ultimately
untenable. We don't have the resources.
When release/12 comes out, we'll have rels 9 through 12 to
On 16/03/15 5:00 AM, Niels Möller wrote:
James Almer jamr...@gmail.com writes:
Valgrind is complaining about this code (Conditional jump or move
depends on uninitialised
value error), as seen here
https://fate.libav.org/x86_64-linux-gcc-valgrind/20150316044429
Zero initializing the
On 14/03/15 12:38, Nicolas George wrote:
Le quartidi 24 ventôse, an CCXXIII, Luca Barbato a écrit :
+if (e) {
+av_log(s, AV_LOG_ERROR,
+ Cannot get the image data
+ event_error: response_type:%u error_code:%u
+ sequence:%u resource_id:%u
On Mon, Mar 16, 2015 at 9:34 PM, Luca Barbato lu_z...@gentoo.org wrote:
From: Niels Möller ni...@lysator.liu.se
Prevent a spuriour read from uninitialized memory.
---
I'm ok with the patch, I'd push it tomorrow morning.
libavcodec/dca_xll.c | 2 +-
1 file changed, 1 insertion(+), 1
On Mon, Mar 16, 2015 at 10:34:26PM +0100, Luca Barbato wrote:
From: Niels Möller ni...@lysator.liu.se
Prevent a spuriour read from uninitialized memory.
spuriou_S
Diego
___
libav-devel mailing list
libav-devel@libav.org
From: Niels Möller ni...@lysator.liu.se
Prevent a spuriour read from uninitialized memory.
---
I'm ok with the patch, I'd push it tomorrow morning.
libavcodec/dca_xll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index
On Mon, Mar 16, 2015 at 11:32:24AM +0100, Luca Barbato wrote:
It uses 6 registers, unbreaks building on hardened x86 system.
Bug-Id: gentoo/541930
CC: libav-sta...@libav.org
---
Now with the needed header (failed at git commit --amend -a again)
libavcodec/x86/mathops.h | 5 +
1
On Sat, Mar 14, 2015 at 4:08 PM, Himangi Saraogi himangi...@gmail.com wrote:
On 14 March 2015 at 21:36, Anton Khirnov an...@khirnov.net wrote:
The value of AV_PIX_FMT_NONE is not 0.
What is the value?
libavutil/pixfmt.h
AV_PIX_FMT_NONE = -1,
--
Vittorio
On Sun, Mar 15, 2015 at 4:48 AM, Sean McGovern gsean...@gmail.com wrote:
---
src/download | 88
+-
src/index| 40 +-
src/news | 31 +
3 files changed, 95 insertions(+), 64
On Sun, Mar 15, 2015 at 10:51 PM, Luca Barbato lu_z...@gentoo.org wrote:
Bug-Id: 833
---
libavformat/matroska.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 237f26f..47fdea6 100644
--- a/libavformat/matroska.c
+++
On Sat, Mar 14, 2015 at 11:30 AM, Luca Barbato lu_z...@gentoo.org wrote:
And notify why the capture is impossible.
---
libavdevice/xcbgrab.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index
James Almer jamr...@gmail.com writes:
Valgrind is complaining about this code (Conditional jump or move
depends on uninitialised
value error), as seen here
https://fate.libav.org/x86_64-linux-gcc-valgrind/20150316044429
Zero initializing the param_state[16] struct from
From: Paul B Mahol one...@gmail.com
Signed-off-by: Paul B Mahol one...@gmail.com
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 68ddd32..fcd696a 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -173,6 +173,7 @@
On 16/03/15 12:58, Vittorio Giovara wrote:
TSCC2 seems to put esds atom despite not containing MPEG-4 video.
Although lavf mov demuxer properly detects codec id as TSCC2, it still
tries to parse esds and since it's no MPEG-4 video it resets the codec
id, preventing video to be decoded.
---
On 16/03/15 09:57, Vittorio Giovara wrote:
And deprecate av_dlog macro.
---
This seemed to be the general consensus on IRC.
Up for discussion.
Vittorio
Set ok for me.
lu
___
libav-devel mailing list
libav-devel@libav.org
From: Derek Buitenhuis derek.buitenh...@gmail.com
The current behavior may produce a different sequence of packets
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream individually,
based on timestamp, which may set each stream at a
On Mon, 16 Mar 2015, Derek Buitenhuis wrote:
The current behavior may produce packets in a different order
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream based on
timestamp, which may not necessarily match the original
This applies to every library except lavc for performance reasons.
---
avplay.c | 8 ++---
libavdevice/dv1394.c | 4 +--
libavdevice/fbdev.c | 2 +-
libavfilter/avfilter.c| 4 +--
libavfilter/internal.h| 2 +-
libavfilter/setpts.c
And deprecate av_dlog macro.
---
This seemed to be the general consensus on IRC.
Up for discussion.
Vittorio
cmdutils.c | 1 +
doc/APIchanges | 3 +++
doc/avtools-common-opts.texi | 1 +
libavutil/log.c | 9 ++---
libavutil/log.h | 9
---
This one appears to add little signal, but a lot of noise.
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 05608f4..f6c9bec 100755
--- a/configure
+++ b/configure
@@ -2736,7 +2736,7 @@ msvc_flags(){
-Wall)
56 matches
Mail list logo
