Signed-off-by: James Almer
---
This is an actual fix for the existing parsing code instead of a copy
of the AVCodecParser code, as an alternative to patches 2 and 3 of this
set.
Five FATE tests will have to be updated with patch 6 if this is applied,
as this parsing code filters unnecessary NAL u
On Fri, Mar 24, 2017 at 01:49:16PM +0100, wm4 wrote:
> The old "API" that signaled rotation as a metadata value has been
> replaced by DISPLAYMATRIX side data quite a while ago.
>
> There is no reason to make muxers/demuxers/API users support both. In
> addition, the metadata API is dangerous, as
Signed-off-by: Micah Galizia
---
libavformat/http.c | 41 +
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 293a8a7..37bdacf 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -29,6 +29,7
Hi,
This is my second attempt at fixing how we are handling expired cookies. As a
reminder, on some authenticated Neulion streams, they send a cookie from the
past, like so:
Set-Cookie: nlqptid=""; Domain=.neulion.com; Expires=Thu, 01-Jan-1970 00:00:10
GMT; Path=/
These expired cookies are ig
Hi,
On Fri, Mar 24, 2017 at 9:15 PM, Michael Niedermayer wrote:
> Repeatly starting a discussion when some patch comes up on a subject
> but then failing to really reach a decission and failing to document
> it and repeating the cycle over and over is not good
+1. So... Vote?
Ronald
_
On Fri, Mar 24, 2017 at 10:16:42AM -0400, Ronald S. Bultje wrote:
[...]
> There is also the risk with the initial patch that compiling libavcodec
> against a newer libavutil but then runtime linking it with another (older)
> one would lead to crashes.
This should not be possible
the minor version
On 3/24/2017 7:31 PM, James Almer wrote:
> The current code discards every non SPS/PPS/VPS NAL from extradata.
> No samples where such filtering breaks decoding has been found, but it's
> nonetheless safer to keep the current behaviour from AVCodecParser for the
> time being, or until the failures
This merges commits 8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4 and
096a8effa3f8f3455292c958c3ed07e798def7bd by Anton Khirnov, with the
following change:
- extract_extradata_check() is added to know if the codec is supported
by the bsf before trying to initialize it. This behaviour is similar to
the
The current code discards every non SPS/PPS/VPS NAL from extradata.
No samples where such filtering breaks decoding has been found, but it's
nonetheless safer to keep the current behaviour from AVCodecParser for the
time being, or until the failures with h264 are fixed.
Signed-off-by: James Almer
It's a simplifaction of the same code, originally commited as 3b5ad8fbf77.
Signed-off-by: James Almer
---
libavcodec/extract_extradata_bsf.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/extract_extradata_bsf.c
b/libavcodec/extract_extradata_bsf.c
i
It's a simplifaction of the same code, originally commited as b4b9a64bdb6.
Signed-off-by: James Almer
---
libavcodec/extract_extradata_bsf.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/libavcodec/extract_extradata_bsf.c
b/libavcodec/extract_extradata_
The current code discards every non SPS/PPS NAL from extradata, which even if
in theory they aren't needed there, some samples fail to decode without them,
like "11159 HD-PVR sample.mpg".
Signed-off-by: James Almer
---
Someone who wants to look why those filtered NALs are needed by such samples,
Required by some samples, like PVA_test-partial.pva
Signed-off-by: James Almer
---
libavcodec/extract_extradata_bsf.c | 46 ++
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/libavcodec/extract_extradata_bsf.c
b/libavcodec/extract_extradata_bsf
This set implements commits 8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4 by
Anton Khirnov, originally merged as 1c193ac1f9cfe703d6a1c36795f309ba5d14bf6e
then reverted in 40fa9d416a2597b1f8a1b9096bfaf05ad367999c as it wasn't
properly tested, and commit 096a8effa3f8f3455292c958c3ed07e798def7bd by
Anton K
Hi,
On Fri, Mar 24, 2017 at 3:53 PM, Carl Eugen Hoyos
wrote:
> 2017-02-26 11:07 GMT+01:00 Carl Eugen Hoyos :
>
> > I believe attached patch does not change the logic of the conditions
> > but silences a (9 times shown, long-time) gcc warning.
>
> Patch applied.
> -if (l >=
2017-02-26 11:07 GMT+01:00 Carl Eugen Hoyos :
> I believe attached patch does not change the logic of the conditions
> but silences a (9 times shown, long-time) gcc warning.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
> Will Storey will at summercat.com wrote on Mon Feb 20 22:46:34 EET 2017:
> > No longer write a final 0x00 byte when flushing the LZW bitstream. There
> > is no mention of doing this in GIF89a specification to do this, and
> > decoders may not expect it.
>
> > Adding this byte for padding was add
On Fri, Mar 24, 2017 at 01:47:10PM +0100, wm4 wrote:
> async_mutex has is used in a very strange but intentional way: it is
> locked by default, and unlocked only in regions that can be run
> concurrently.
>
> If the user was calling API functions to the same context from different
> threads (in a
On Fri, Mar 24, 2017 at 12:47 AM, wm4 wrote:
> On Mon, 20 Mar 2017 14:39:07 -0700
> Fredrik Hubinette wrote:
>
> > It looks like the value in s->error also comes from an earlier call to
> > avio_read().
> > ogg_read_page tries to read 4439 bytes from the file. It has 524 bytes
> > already buffer
On Thu, Mar 23, 2017 at 10:48:28PM -0700, Thomas Turner wrote:
> Signed-off-by: Thomas Turner
> ---
> libavcodec/Makefile | 1 +
> libavcodec/tests/celp_math.c | 48
>
> tests/fate/libavcodec.mak| 5 +
> 3 files changed, 54 insertio
Hi,
On Fri, Mar 24, 2017 at 10:05 AM, Clément Bœsch wrote:
> On Fri, Mar 24, 2017 at 10:40:21AM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes #6255.
> >
> > Please comment, Carl Eugen
>
> > From 1c249440c62271565be12112f321ad9aa6a922fb Mon Sep 17 00:00:00 2001
> > From: Car
On Fri, Mar 24, 2017 at 10:40:21AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes #6255.
>
> Please comment, Carl Eugen
> From 1c249440c62271565be12112f321ad9aa6a922fb Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Fri, 24 Mar 2017 10:38:22 +0100
> Subject: [PATCH] lav
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or
async_mutex has is used in a very strange but intentional way: it is
locked by default, and unlocked only in regions that can be run
concurrently.
If the user was calling API functions to the same context from different
threads (in a safe way), this could unintentionally unlock the mutex on
a diff
Le 23 mars 2017 7:31 PM, "James Almer" a écrit :
On 3/23/2017 3:15 PM, Matthieu Bouron wrote:
> Le 23 mars 2017 12:35 AM, "James Almer" a écrit :
>
> Signed-off-by: James Almer
> ---
> Untested.
>
> libavcodec/mediacodec.c | 5 ++---
> libavcodec/mediacodecdec.c| 1 -
> lib
On Fri, 24 Mar 2017 07:48:53 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Fri, Mar 24, 2017 at 7:40 AM, Ronald S. Bultje
> wrote:
>
> > Hi,
> >
> > On Fri, Mar 24, 2017 at 6:23 AM, Carl Eugen Hoyos
> > wrote:
> >
> >> there are several similar cases there.
> >
> >
> > That is classically
Hi,
On Fri, Mar 24, 2017 at 7:40 AM, Ronald S. Bultje
wrote:
> Hi,
>
> On Fri, Mar 24, 2017 at 6:23 AM, Carl Eugen Hoyos
> wrote:
>
>> there are several similar cases there.
>
>
> That is classically how ff_ symbols became public API. Please don't use
> that argument ever again.
>
Btw, I'm not
Hi,
On Fri, Mar 24, 2017 at 6:23 AM, Carl Eugen Hoyos
wrote:
> there are several similar cases there.
That is classically how ff_ symbols became public API. Please don't use
that argument ever again.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel
On Fri, 24 Mar 2017 11:23:44 +0100
Carl Eugen Hoyos wrote:
> 2017-03-24 10:59 GMT+01:00 wm4 :
> > On Fri, 24 Mar 2017 10:40:21 +0100
> > Carl Eugen Hoyos wrote:
> >
> >> From 1c249440c62271565be12112f321ad9aa6a922fb Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos
> >> Date: Fri, 24 Mar 2
Hi,
attached patch will fix ticket #2674.
Tested with examples from ticket 2674 and other files at various frame rates.
v2: Use av_frame_get_pkt_duration to calculate count of duplication of last
frame.
Use average of the earlier pts steps when av_frame_get_pkt_duration is not set.
v3: Write at
2017-03-24 10:59 GMT+01:00 wm4 :
> On Fri, 24 Mar 2017 10:40:21 +0100
> Carl Eugen Hoyos wrote:
>
>> From 1c249440c62271565be12112f321ad9aa6a922fb Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Fri, 24 Mar 2017 10:38:22 +0100
>> Subject: [PATCH] lavc/h264_ps: Check that chroma_locati
On Fri, 24 Mar 2017 10:40:21 +0100
Carl Eugen Hoyos wrote:
> From 1c249440c62271565be12112f321ad9aa6a922fb Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Fri, 24 Mar 2017 10:38:22 +0100
> Subject: [PATCH] lavc/h264_ps: Check that chroma_location is within limits.
>
> Fixes ticket #62
Hi!
Attached patch fixes #6255.
Please comment, Carl Eugen
From 1c249440c62271565be12112f321ad9aa6a922fb Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 24 Mar 2017 10:38:22 +0100
Subject: [PATCH] lavc/h264_ps: Check that chroma_location is within limits.
Fixes ticket #6255.
---
lib
On Mon, 20 Mar 2017 14:39:07 -0700
Fredrik Hubinette wrote:
> It looks like the value in s->error also comes from an earlier call to
> avio_read().
> ogg_read_page tries to read 4439 bytes from the file. It has 524 bytes
> already buffered.
> fill_buffer() fails with an EIO, but because of the bu
34 matches
Mail list logo
