* make HEVC parser respect PARSER_FLAG_ONCE flag
Signed-off-by: Dima Buzdyk
---
libavcodec/hevc_parser.c | 4
libavformat/avformat.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 5af4b788d5..d0c9aa6e44 10064
On Tue, Jul 14, 2020 at 11:14:19PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Tue, Jul 14, 2020 at 10:43:51PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Tue, Jul 14, 2020 at 05:34:50PM +0200, Andreas Rheinhardt wrote:
> get_ue_golomb_31() uses a LUT
On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick wrote:
>
> On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> > Maybe I give an inaccurate description in the commit message, in fact,
> > libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will
> > lead to FFmpeg build
From: Wang Cao
Signed-off-by: Wang Cao
---
doc/encoders.texi | 36 +
libavcodec/libaomenc.c | 60 ++
libavcodec/version.h | 2 +-
3 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encode
From: Wang Cao
Signed-off-by: Wang Cao
---
doc/encoders.texi | 20
libavcodec/libaomenc.c | 32
libavcodec/version.h | 2 +-
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 5
On Wed, Jul 15, 2020 at 12:54:35AM +0100, Kieran Kunhya wrote:
> On Wed, 15 Jul 2020 at 00:36, wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/h264_slice.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/libavcodec/h264_slice.c
On Wed, 15 Jul 2020 at 00:36, wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/h264_slice.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index c7b2764..db720de 100644
> --- a/libavcodec/h264_s
From: Limin Wang
Please test with below command:
./ffmpeg -export_side_data s12m_tc -i
../fate-suite/h264/crew_cif_timecode-2.h264 out.mp4
Signed-off-by: Limin Wang
---
libavformat/movenc.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --g
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/h264_slice.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index c7b2764..db720de 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1307,6 +1307,7 @
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/dvenc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavformat/dvenc.c b/libavformat/dvenc.c
index b04d604..b5fea8f 100644
--- a/libavformat/dvenc.c
+++ b/libavformat/dvenc.c
@@ -396,6 +396,18 @@ static int dv_wri
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/internal.h | 5 +
libavcodec/utils.c| 30 ++
2 files changed, 35 insertions(+)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 0a1c0a1..e0040fc 100644
--- a/libavcodec/internal.h
+++
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/APIchanges | 3 +++
doc/codecs.texi| 3 +++
libavcodec/avcodec.h | 4
libavcodec/options_table.h | 1 +
libavcodec/version.h | 2 +-
5 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/API
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/hevcdec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index b77df8d..6e24c9b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2827,6 +2827,7 @@ static int se
Michael Niedermayer:
> On Tue, Jul 14, 2020 at 10:43:51PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Tue, Jul 14, 2020 at 05:34:50PM +0200, Andreas Rheinhardt wrote:
get_ue_golomb_31() uses a LUT of 512 entries; therefore it can be used
to parse exp-golomb codes of le
On Tue, Jul 14, 2020 at 10:43:51PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Tue, Jul 14, 2020 at 05:34:50PM +0200, Andreas Rheinhardt wrote:
> >> get_ue_golomb_31() uses a LUT of 512 entries; therefore it can be used
> >> to parse exp-golomb codes of length <= 9, i.e. those co
On 7/14/2020 5:49 PM, Michael Niedermayer wrote:
> On Tue, Jul 14, 2020 at 11:19:54AM -0300, James Almer wrote:
>> On 7/14/2020 9:47 AM, Nicolas George wrote:
>>> James Almer (12020-07-10):
Because my opinion and tastes are not yours. I already said why *i*
consider it ugly. It doesn't ne
On Tue, Jul 14, 2020 at 11:19:54AM -0300, James Almer wrote:
> On 7/14/2020 9:47 AM, Nicolas George wrote:
> > James Almer (12020-07-10):
> >> Because my opinion and tastes are not yours. I already said why *i*
> >> consider it ugly. It doesn't need to fit *your* conception of ugliness.
> >
> > If
Michael Niedermayer:
> On Tue, Jul 14, 2020 at 05:34:50PM +0200, Andreas Rheinhardt wrote:
>> get_ue_golomb_31() uses a LUT of 512 entries; therefore it can be used
>> to parse exp-golomb codes of length <= 9, i.e. those codes with at most
>> four leading bits that have five effective bits; this im
On Tue, Jul 14, 2020 at 05:34:50PM +0200, Andreas Rheinhardt wrote:
> get_ue_golomb_31() uses a LUT of 512 entries; therefore it can be used
> to parse exp-golomb codes of length <= 9, i.e. those codes with at most
> four leading bits that have five effective bits; this implies a range of
> 0..30 a
Michael Niedermayer:
> On Tue, Jul 14, 2020 at 06:10:39PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Mon, Jul 13, 2020 at 09:04:30PM +0200, Tomas Härdin wrote:
fre 2020-07-10 klockan 15:48 +0200 skrev Andreas Rheinhardt:
> This happened in get_ue_golomb() if the cached
On Tue, Jul 14, 2020 at 06:10:39PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, Jul 13, 2020 at 09:04:30PM +0200, Tomas Härdin wrote:
> >> fre 2020-07-10 klockan 15:48 +0200 skrev Andreas Rheinhardt:
> >>> This happened in get_ue_golomb() if the cached bitstream reader was
>
get_ue_golomb_30() and get_ue_golomb() (as well as
get_ue_golomb2()) can only parse values within a certain range
correctly; if the parsed value is not within said range, the latter two
functions return AVERROR_INVALIDDATA, while the former returns something
outside of said range (currently 32 for
instead of get_ue_golomb(). The difference between the two is that the
latter also has to take into account the case in which the read code is
more than 9 bits (four preceding zeroes + at most five value bits) long.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cavsdec.c | 2 +-
libavcod
If the return value is undefined if the value of the encountered
exp golomb code was outside the 0..30 range, said function can't
be used anywhere where one wants to check for correctness. So document
that in this case the return value is outside the range 0..30 (it
currently always returns 32 in t
get_ue_golomb_31() uses a LUT of 512 entries; therefore it can be used
to parse exp-golomb codes of length <= 9, i.e. those codes with at most
four leading bits that have five effective bits; this implies a range of
0..30 and not 31. In particular, this function must not be used to parse
e.g. the H
This happened in get_ue_golomb() if the cached bitstream reader was in
use, because there was no check to handle the case of the read value
not being in the supported range.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/golomb.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec
Said error message is not very informative and lacked a proper logging
context; furthermore, many callers already provided more descriptive
error messages of their own. So just drop this one.
Suggested-by: James Almer
Signed-off-by: Andreas Rheinhardt
---
libavcodec/golomb.h | 4 +---
1 file ch
Actually, forget this patch. It was modeled after the previous AVOption patch
I sent for the ftp protocol, but a better more generic approach would be to
have some sort of callback for API users so they can just implement .netrc.
Like this, with just AVOption for usernames and passwords, we can't
On Tue, Jul 14, 2020 at 10:13:13PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> Currently, the COC marker overrides the SOP marker bit.
> However, only the COD marker may set this value. This
> patch fixes this bug.
> ---
> libavcodec/jpeg2000dec.c | 4 +++-
> 1 file change
On Tue, Jul 14, 2020 at 10:44:19AM +0300, Martin Storsjö wrote:
> On Sun, 12 Jul 2020, Michael Niedermayer wrote:
>
> > Regression since: 3adffab073bc59af39035168ac72bc9ffde3
> >
> > -1 is consistent what other error paths return
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libsws
On Tue, Jul 14, 2020 at 10:42:24AM +0300, Martin Storsjö wrote:
> On Sun, 12 Jul 2020, Michael Niedermayer wrote:
>
> > Regression since: 3adffab073bc59af39035168ac72bc9ffde3
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libswscale/tests/swscale.c | 2 +-
> > 1 file changed, 1 insert
James Almer (12020-07-14):
> Perhaps this should instead be implemented as an AV_OPT_TYPE_DICT option
> that can accept anything you would otherwise pass as part of the url, so
> user, pass, port, etc.
It makes things more complicated for us (accessing a dictionary instead
of options directly), fo
On 7/14/2020 3:06 PM, Nicolas Frattaroli wrote:
> This introduces two new AVOption options for the SFTP protocol,
> one named sftp_user to supply the username to be used for auth,
> one named sftp_password to supply the password to be used for auth.
>
> These are useful for when an API user does n
Thanks for the patch. I thnink it is a good idea. See preliminary
comments below.
I do not know if Lukasz, who wrote this file, still reads the list. If
he does not appear in the next few days, try Ccing him.
Nicolas Frattaroli (12020-07-14):
> This introduces two new AVOption options for the SF
This introduces two new AVOption options for the SFTP protocol,
one named sftp_user to supply the username to be used for auth,
one named sftp_password to supply the password to be used for auth.
These are useful for when an API user does not wish to deal with
URL manipulation and percent encoding
James Almer:
> On 7/14/2020 12:34 PM, Andreas Rheinhardt wrote:
>> This is designed for scenarios where the caller already checks that the
>> returned value is within a certain allowed range and returns an error
>> message if not.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/golom
James Almer (12020-07-14):
> Is it worth keeping the error messages at all, for that matter? They
> don't even use a proper logging context, so the printed output is ugly
> and unidentifiable by itself.
Good point. We should probably try to eliminate all av_log(NULL) uses
from the libraries, in fa
On 7/14/2020 12:34 PM, Andreas Rheinhardt wrote:
> This is designed for scenarios where the caller already checks that the
> returned value is within a certain allowed range and returns an error
> message if not.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/golomb.h | 32
Am Mo., 13. Juli 2020 um 15:19 Uhr schrieb James Almer :
>
> On 7/13/2020 4:02 AM, Carl Eugen Hoyos wrote:
> >
> >
> >> Am 13.07.2020 um 02:33 schrieb James Almer :
> >>
> >> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled
> >> CPUs.
> >
> > FFmpeg does not require aligne
From: Gautam Ramakrishnan
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
---
libavcodec/jpeg2000dec.c | 111 +++
1 file changed, 101 insertions(+), 10 deletions(-)
diff --git a/libavco
From: Gautam Ramakrishnan
Currently, the COC marker overrides the SOP marker bit.
However, only the COD marker may set this value. This
patch fixes this bug.
---
libavcodec/jpeg2000dec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/
From: Gautam Ramakrishnan
The PCRL progression checks were incomplete. This patch
modifes completes the check. Tested on p1_05.j2k.
---
libavcodec/jpeg2000dec.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg
From: Gautam Ramakrishnan
The RPCL progression order check was incomplete. This
patch completes the check. Tested on p1_07.j2k.
---
libavcodec/jpeg2000dec.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
Michael Niedermayer:
> On Mon, Jul 13, 2020 at 09:04:30PM +0200, Tomas Härdin wrote:
>> fre 2020-07-10 klockan 15:48 +0200 skrev Andreas Rheinhardt:
>>> This happened in get_ue_golomb() if the cached bitstream reader was
>>> in
>>> use, because there was no check to handle the case of the read valu
get_ue_golomb_30() and get_ue_golomb() (as well as
get_ue_golomb2()) can only parse values within a certain range
correctly; if the parsed value is not within said range, the latter two
functions return AVERROR_INVALIDDATA, while the former returns something
outside of said range (currently 32 for
instead of get_ue_golomb(). The difference between the two is that the
latter also has to take into account the case in which the read code is
more than 9 bits (four preceding zeroes + at most five value bits) long.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cavsdec.c | 4 ++--
libavc
The difference of this function and get_ue_golomb() is that the latter
emits an error message upon encountering an exp golomb code outside the
range of 0..8190. But this error message is unnecessary in cases where
there is a dedicate error message in case of range error (these error
messages also u
get_ue_golomb_31() uses a LUT of 512 entries; therefore it can be used
to parse exp-golomb codes of length <= 9, i.e. those codes with at most
four leading bits that have five effective bits; this implies a range of
0..30 and not 31. In particular, this function must not be used to parse
e.g. the H
If the return value is undefined if the value of the encountered
exp golomb code was outside the 0..30 range, said function can't
be used anywhere where one wants to check for correctness. So document
that in this case the return value is outside the range 0..30 (it
currently always returns 32 in t
This is designed for scenarios where the caller already checks that the
returned value is within a certain allowed range and returns an error
message if not.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/golomb.h | 32
1 file changed, 24 insertions(+), 8 delet
On 7/14/2020 9:47 AM, Nicolas George wrote:
> James Almer (12020-07-10):
>> Because my opinion and tastes are not yours. I already said why *i*
>> consider it ugly. It doesn't need to fit *your* conception of ugliness.
>
> If it is only a matter of taste, then it cannot count as an argument.
> But
I wrote a code to mix two audio streams which is working. However,
somehow `avfilter_graph_parse2` is not preserving the pad names
For example, below is a filter spec
```
filter_spec =
"abuffer=time_base=1/48000:sample_rate=48000:sample_fmt=fltp:channel_layout=0x3[a0]
;
abuffer=time_base=1/4800
On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> Maybe I give an inaccurate description in the commit message, in fact,
> libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will
> lead to FFmpeg build fail when using libsrt version >= 1.4.1
I don't mind you descrip
James Almer (12020-07-10):
> Because my opinion and tastes are not yours. I already said why *i*
> consider it ugly. It doesn't need to fit *your* conception of ugliness.
If it is only a matter of taste, then it cannot count as an argument.
But tastes are frequently a proxy for minor factors. If y
On Mon, Jul 13, 2020 at 13:16:18 +0200, Jean-Baptiste Kempf wrote:
> We need to export init_uni_ac_vlc to init_uni_ac_vlc and therefore need
"to ff_init_uni_ac_vlc"?
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
On 14-07-2020 05:14 pm, Andreas Rheinhardt wrote:
Gyan Doshi:
Some legacy applications such as AVI2MVE expect raw RGB bitmaps
to be stored bottom-up, whereas our RIFF BITMAPINFOHEADER assumes
they are always stored top-down and thus write a negative value
for height. This can prevent reading o
On Sun, Jul 12, 2020 at 10:54:45 -0400, Andriy Gelman wrote:
> On Fri, 10. Jul 21:13, Moritz Barsnick wrote:
> > Since xcbgrab is getting some attention recently...
> >
> > Fixes a segfault, as reported in #7312.
> >
> > To reproduce:
> > Terminal 1:
> > $ Xvfb :1 -nolisten tcp -screen 0 800x600x24
Gyan Doshi:
> Some legacy applications such as AVI2MVE expect raw RGB bitmaps
> to be stored bottom-up, whereas our RIFF BITMAPINFOHEADER assumes
> they are always stored top-down and thus write a negative value
> for height. This can prevent reading of these files.
>
> Option flipped_raw_rgb adde
On Mon, Jul 13, 2020 at 12:46:17PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Reviewed-by: Marton Balint
> Signed-off-by: Limin Wang
> ---
> libavdevice/decklink_dec.cpp | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/libavdevice/decklink_dec.cpp b/li
tis 2020-07-14 klockan 14:23 +0800 skrev Steven Liu:
> Because the newpos variable is set value before use it.
> The newpos variable declared at the head partition of crypto_seek.
> Make the code clean.
>
> Signed-off-by: Steven Liu
> ---
> libavformat/crypto.c | 12
> 1 file change
On 14-07-2020 01:54 pm, Paul B Mahol wrote:
Why is option called rgb?
It have nothing to do with rgb.
Flipped can be any encoded file.
No, coded or uncoded streams with a codec tag or raw YUV bitmaps are
always indicated as positive height. Only raw RGB bitmaps can be
signaled as flipped.
Why is option called rgb?
It have nothing to do with rgb.
Flipped can be any encoded file.
On 7/14/20, Gyan Doshi wrote:
> Plan to push in 24h.
>
> On 08-07-2020 06:21 pm, Gyan Doshi wrote:
>> Some legacy applications such as AVI2MVE expect raw RGB bitmaps
>> to be stored bottom-up, whereas our
Plan to push in 24h.
On 08-07-2020 06:21 pm, Gyan Doshi wrote:
Some legacy applications such as AVI2MVE expect raw RGB bitmaps
to be stored bottom-up, whereas our RIFF BITMAPINFOHEADER assumes
they are always stored top-down and thus write a negative value
for height. This can prevent reading of
On Sun, 12 Jul 2020, Michael Niedermayer wrote:
Regression since: 3adffab073bc59af39035168ac72bc9ffde3
-1 is consistent what other error paths return
Signed-off-by: Michael Niedermayer
---
libswscale/tests/swscale.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib
On Sun, 12 Jul 2020, Michael Niedermayer wrote:
Regression since: 3adffab073bc59af39035168ac72bc9ffde3
Signed-off-by: Michael Niedermayer
---
libswscale/tests/swscale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.
65 matches
Mail list logo
