> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Niklas Haas
> Sent: Saturday, February 09, 2019 1:30 AM
> To: Kps, Harish Krupo
> Cc: vittorio.giov...@gmail.com; Sharma, Shashank
> ; Palli, Tapani ;
> FFmpeg development discussions and pa
Hello,
Please find attached patch for nv-codec-headers.
It adds Video Codec SDK 9 support.
--
BR, Roman Arzumanyan
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidentia
Hello,
Please find attached patch, it adds HEVC B-frames support to nvenc_hevc.
This feature requires Video Codec SDK 9 + Turing card.
--
BR, Roman Arzumanyan
---
This email message is for the sole use of the intend
Hi Harish,
On Tue, 12 Feb 2019 19:43:33 +0530, Harish Krupo
wrote:
> Hi Niklas,
>
> Thanks a lot for your comments. Please find my reply inline.
>
> Niklas Haas writes:
>
> > Hi,
> >
> > The important thing to consider is what constraints we are trying to
> > solve. And I think the expected
Hello,
Please find attached patch, it adds HEVC YUV444P decoding support.
Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE,
AV_PIX_FMT_YUV444P12LE.
This feature requires Video Codec SDK 9.
--
BR, Roman Arzumanyan
-
From: Wenxiang Qian
Signed-off-by: Michael Niedermayer
---
libavformat/ftp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index e072067480..3adc04ee1f 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -389,7 +389,7 @@ static i
From: Wenxiang Qian
Signed-off-by: Michael Niedermayer
---
libavformat/http.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index a0a0636cf2..072a6ce0b9 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -915,7 +915,7 @@ sta
Fixes: out of array access
Found-by: Wenxiang Qian
Signed-off-by: Michael Niedermayer
---
libavformat/webmdashenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index 1280d8a763..26b8727304 100644
--- a/libavformat/webmdashenc.c
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>On Behalf Of gxw
>Sent: Tuesday, February 12, 2019 6:56 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: gxw
>Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora
>decoding with mm
2019-02-13 8:52 GMT+01:00, Wang, Shaofei :
>> > +AVFrame input_frm;
>>
>> sizeof(AVFrame) is not part of the ABI. You need to allocate it
>> somewhere.
>>
> Please tell more?
See the documentation for AVFrame in libavutil/frame.h
Use av_frame_alloc()
Carl Eugen
_
> >> sizeof(AVFrame) is not part of the ABI. You need to allocate it
> >> somewhere.
> >>
> > Please tell more?
>
> See the documentation for AVFrame in libavutil/frame.h Use av_frame_alloc()
>
> Carl Eugen
Thanks Carl
___
ffmpeg-devel mailing list
ff
On 12/02/2019 22:28, Michael Niedermayer wrote:
> @@ -5048,7 +5048,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> for (i = 0; i < c->fc->nb_streams; i++) {
> st = c->fc->streams[i];
> sc = st->priv_data;
> -if (!sc->ha
Reported-by: Steve Lhomme
This was found through the Hacker One program on VLC but is not a security
issue in libavformat
Signed-off-by: Michael Niedermayer
---
libavformat/matroskadec.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavf
Best regards, Reto
0001-doc-muxers-fix-typo.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 13-02-2019 06:41 PM, Reto Kromer wrote:
Best regards, Reto
Pushed as
bf78aa9ee9c42c89bcd88a301e23ce8efbd155ce
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 11/02/2019 23:41, Michael Niedermayer wrote:
breaks fate-cdgraphics
Hi Michael,
Thanks for testing my patch. I wasn't aware of this specific test, sorry
about that.
What would be the proper way to address this? Should the fate reference
be updated?
The test file is still properly pla
2019-02-13 16:19 GMT+01:00, Guillaume Desmottes
:
> Thanks for testing my patch. I wasn't aware of this specific test, sorry
> about that.
>
> What would be the proper way to address this? Should the fate reference
> be updated?
Yes, unless the change is wrong.
Carl Eugen
___
2019-02-13 14:18 GMT+01:00, Reto Kromer :
> ffmpeg | branch: master | Reto Kromer | Wed Feb 13 14:08:23
> 2019 +0100| [bf78aa9ee9c42c89bcd88a301e23ce8efbd155ce] | committer: Gyan
> Doshi
>
> doc/muxers: fix typo
>
> Signed-off-by: Gyan Doshi
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=c
Carl Eugen Hoyos wrote:
>> +Any hexadecimal value between @code{0x01} to @code{0xff} as defined in
>
>Shouldn't this be "between 0x01 and 0xff"?
Yep, of course. I will fix this. Thank you! Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Best regards, Reto
0001-doc-muxers-fix-typo.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 13-02-2019 09:36 PM, Reto Kromer wrote:
Best regards, Reto
A grammar change rather than a typo.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
When a JACOsub subtitle has two timestamps, they represent its start and
end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
duration is the difference between the two, not the sum of the two.
The subtitle end times in the FATE test for this were wrong as a result;
fix them too. (
On 13.02.2019 09:56, Roman Arzumanyan wrote:
Hello,
Please find attached patch, it adds HEVC YUV444P decoding support.
Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE,
AV_PIX_FMT_YUV444P12LE.
This feature requires Video Codec SDK 9.
There is one big issue with this.
And th
On 13.02.2019 09:47, Roman Arzumanyan wrote:
Hello,
Please find attached patch for nv-codec-headers.
It adds Video Codec SDK 9 support.
Applied and followed up with a patch adding some more new fields from
SDK 9.0.18.
smime.p7s
Description: S/MIME Cryptographic Signature
___
On 13.02.2019 09:52, Roman Arzumanyan wrote:
Hello,
Please find attached patch, it adds HEVC B-frames support to nvenc_hevc.
This feature requires Video Codec SDK 9 + Turing card.
Will it cause issues if set on an older card, or just plain get ignored?
If it's ignored, this LGTM.
smime.p
---
libavformat/movenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7794330..bb8bbdb 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1088,6 +1088,7 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MO
On Sun, Feb 10, 2019 at 3:12 PM James Almer wrote:
> If nb_bits is zero when reading an OBU, then it's not a bug in CBS but an
> invalid bitstream, and we should abort gracefully instead.
>
> Signed-off-by: James Almer
> ---
> rav1e is currently encoding invalid Metadata OBUs without trailing bi
So, should this go in? :)
On 2/8/19 11:10 PM, Mathieu Duponchelle wrote:
> ---
> doc/encoders.texi | 3 +++
> libavcodec/mpeg12enc.c | 32
> libavcodec/mpegvideo.h | 2 ++
> 3 files changed, 37 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders
On Tue, 12 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-11 23:42 GMT+01:00, Marton Balint :
ISO-10646 alone means UCS-4 for iconv, the specs refers to the Basic
Multilingual Plane (BMP), therefore we need UCS-2. VLC also using that.
Signed-off-by: Marton Balint
---
libavformat/mpegts.c | 2 +-
On Tue, 12 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-11 23:42 GMT+01:00, Marton Balint :
The default codepage (ISO6937) should be used in this case.
lgtm
Thanks, applied.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
On Mon, 11 Feb 2019, Marton Balint wrote:
On Tue, 5 Feb 2019, Marton Balint wrote:
This removes lots of code duplication and also allows more complex
specifiers,
for example you can use p:204:a:m:language:eng to select the English
language
audio stream from program 204.
Ping... Will
Fixes: runtime error: signed integer overflow: 2147421862 - -33624063 cannot be
represented in type 'int'
Fixes:
12885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5733516975800320
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmp
ffserver documentation and sample configuration file has been moved to
the wiki:
https://trac.ffmpeg.org/wiki/ffserver
The files unlinked by this patch will be removed from the server.
Signed-off-by: Lou Logan
---
src/documentation | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/docum
Signed-off-by: Lou Logan
---
generate-doc.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/generate-doc.sh b/generate-doc.sh
index d8d01d3..4555a35 100755
--- a/generate-doc.sh
+++ b/generate-doc.sh
@@ -34,9 +34,9 @@ export FA_ICONS=true
rm -rf build-doc
mkdir build-
On Wed, 13 Feb 2019 19:47:27 +0100
Timo Rothenpieler wrote:
> On 13.02.2019 09:56, Roman Arzumanyan wrote:
> > Hello,
> >
> > Please find attached patch, it adds HEVC YUV444P decoding support.
> >
> > Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE,
> > AV_PIX_FMT_YUV444P12LE.
With the official release of the Video SDK 9.0, I'm resending my
previous patch series for the new decode capabilities. I have left out
the new pixel formats representing MSB packed 444p10 and 444p12 due to
the lack of concensus on introducing these pixel formats. That means we
will always treat th
We need all the flags to be exposed to be able to pass them on to
HW decoders. I did not attempt to nuance any of the warnings about
flags being unsupported as there's no way, at the point we extract
flags, to say whether an HW decoder is being used.
Signed-off-by: Philip Langdale
---
libavcodec
This is the equivalent change for cuviddec after the previous change
for nvdec. I made similar changes to the copying routines to handle
pixel formats in a more generic way.
Note that unlike with nvdec, there is no confusion about the ability
of a codec to output 444 formats. This is because the c
With the introduction of HEVC 444 support, we technically have two
codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG,
it can decode, but can only output one of the semi-planar formats.
That means we need additional logic to decide whether to use a
444 output format or not.
Signed-
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. Supporting this is relatively straight-forward;
we need to account for the different chroma format and pick the
right output and sw formats at the right times.
There was one bug which was the hard-coded assumptio
40 matches
Mail list logo
