Juan De León (12019-08-19):
> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> AV_FRAME_DATA_ENCODE_INFO.
> The structure stores quantization index for each plane, DC/AC deltas
> for luma and chroma planes, and an array of AVEncodeInfoBlock type
> denoting position, size, and
Hi there,
I'm Fabrice Nicol, the developer of the free software dvda-author, which
creates DVD-Audio discs (http://dvd-audio.sourceforge.net/)
1. With the help of Jai Luthra, the MLP encoder maintainer, I've been
implementing DVD-Audio authoring for MLP files using libavcodec. This
will be a
On Tue, Aug 20, 2019 at 7:04 PM James Almer wrote:
> On 8/20/2019 5:29 AM, Paul B Mahol wrote:
> > On Mon, Aug 19, 2019 at 11:31 PM James Almer wrote:
> >
> >> On 8/13/2019 10:14 PM, Eugene Lyapustin wrote:
> >>> Signed-off-by: Eugene Lyapustin
> >>> ---
> >>> doc/filters.texi | 137 +
Am Mi., 21. Aug. 2019 um 10:01 Uhr schrieb fabrice nicol :
> I was wondering whether the ffmpeg team has investigated the potential
> legal issues with the MLP decoder/encoder, as it was originally created
> under proprietary licensing terms.
To the best of our knowledge, the mlp decoder was writ
On Wed, Aug 21, 2019 at 10:29 AM Carl Eugen Hoyos
wrote:
> Am Mi., 21. Aug. 2019 um 10:01 Uhr schrieb fabrice nicol <
> fabrni...@gmail.com>:
>
> > I was wondering whether the ffmpeg team has investigated the potential
> > legal issues with the MLP decoder/encoder, as it was originally created
>
The configure line is not needed. Where is Makefile change?
Changlelog one does not apply.
On Tue, Aug 20, 2019 at 7:25 PM Carl Eugen Hoyos wrote:
> Am Di., 20. Aug. 2019 um 10:30 Uhr schrieb Paul B Mahol >:
> >
> > Do not use full caps name for short name.
>
> New patch attached.
>
> Thank you
Am Mi., 21. Aug. 2019 um 10:40 Uhr schrieb Paul B Mahol :
>
> The configure line is not needed. Where is Makefile change?
This line makes no sense.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmp
On Wed, Aug 21, 2019 at 10:44 AM Carl Eugen Hoyos
wrote:
> Am Mi., 21. Aug. 2019 um 10:40 Uhr schrieb Paul B Mahol >:
> >
> > The configure line is not needed. Where is Makefile change?
>
> This line makes no sense.
>
Nope, you do not make sense. Configure line is completely bollocks.
Makefile
Am Mi., 21. Aug. 2019 um 10:54 Uhr schrieb Paul B Mahol :
>
> On Wed, Aug 21, 2019 at 10:44 AM Carl Eugen Hoyos
> wrote:
>
> > Am Mi., 21. Aug. 2019 um 10:40 Uhr schrieb Paul B Mahol > >
> > > The configure line is not needed. Where is Makefile change?
> >
> > This line makes no sense.
>
> Nope,
Hello,
this goal of this patchset is making avio_enum_protocols const correct.
It currently ignores the distinction between const URLProtocol *
const * and const URLProtocol ** in the line p = p ? p + 1 : url_protocols;
(where p is of the latter type and url_protocols is of the former (after
the a
Using avio_enum_protocols works as follows: One initializes a pointer to
void and gives avio_enum_protocols the address of said pointer as
argument; the pointer will be updated to point to a member of the
url_protocols array. Now the address of the pointer can be reused for
another call to avio_enu
The tests for concat use this option which is scheduled for removal and
does nothing any more. So remove it; otherwise, these tests would fail
at the next major version bump.
Signed-off-by: Andreas Rheinhardt
---
tests/fate-run.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
wtvfile_read_packet did not abide by the requirements of a function
destined to read a packet: If it did not read anything, it returned
zero, which currently leads to a warning in read_packet_wrapper in
aviobuf.c. Said warning will be an av_assert2 as soon as
FF_API_OLD_AVIO_EOF_0 is zero (probably
Am Mi., 21. Aug. 2019 um 11:13 Uhr schrieb Andreas Rheinhardt
:
>
> Hello,
>
> this goal of this patchset is making avio_enum_protocols const correct.
> It currently ignores the distinction between const URLProtocol *
> const * and const URLProtocol ** in the line p = p ? p + 1 : url_protocols;
> (
tis 2019-08-20 klockan 21:05 -0300 skrev James Almer:
> Should reduce date copying considerably.
>
> Signed-off-by: James Almer
> ---
> Fixed a stupid mistake when checking the return value for av_new_packet().
> Still untested.
Works great for me. Should make fuzzing faster overall, better use
On Wed, Aug 21, 2019 at 11:12 AM Carl Eugen Hoyos
wrote:
> Am Mi., 21. Aug. 2019 um 10:54 Uhr schrieb Paul B Mahol >:
> >
> > On Wed, Aug 21, 2019 at 10:44 AM Carl Eugen Hoyos
> > wrote:
> >
> > > Am Mi., 21. Aug. 2019 um 10:40 Uhr schrieb Paul B Mahol <
> one...@gmail.com
> > > >
> > > > The c
On Tue, Aug 20, 2019 at 11:51:48AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp5.c | 2 +-
> libavcodec/vp6.c | 2 +-
> libavcodec/vp8.c | 8
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/vp5.c b/libavcodec
ons 2019-08-21 klockan 11:04 +0200 skrev Andreas Rheinhardt:
> Using avio_enum_protocols works as follows: One initializes a pointer to
> void and gives avio_enum_protocols the address of said pointer as
> argument; the pointer will be updated to point to a member of the
> url_protocols array. Now
Carl Eugen Hoyos:
> Am Mi., 21. Aug. 2019 um 11:13 Uhr schrieb Andreas Rheinhardt
> :
>>
>> Hello,
>>
>> this goal of this patchset is making avio_enum_protocols const correct.
>> It currently ignores the distinction between const URLProtocol *
>> const * and const URLProtocol ** in the line p = p
Tomas Härdin:
> ons 2019-08-21 klockan 11:04 +0200 skrev Andreas Rheinhardt:
>> Using avio_enum_protocols works as follows: One initializes a pointer to
>> void and gives avio_enum_protocols the address of said pointer as
>> argument; the pointer will be updated to point to a member of the
>> url_p
On Wed, Aug 21, 2019, at 11:35, Paul B Mahol wrote:
> > > > > The configure line is not needed. Where is Makefile change?
> > > >
> > > > This line makes no sense.
> > >
> > > Nope, you do not make sense.
> >
> > I hope you agree it is difficult to "make sense" in an answer to
> > something that ma
Signed-off-by: Steven Liu
---
doc/examples/decode_video.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
index 5a9d43f689..169188a4b9 100644
--- a/doc/examples/decode_video.c
+++ b/doc/examples/decode_video.c
@@ -95,
Signed-off-by: Steven Liu
---
doc/examples/decode_audio.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/doc/examples/decode_audio.c b/doc/examples/decode_audio.c
index 19dcafd2c8..23d0c9bf50 100644
--- a/doc/examples/decode_audio.c
+++ b/doc/examples/d
On 8/21/2019 6:15 AM, Tomas Härdin wrote:
> tis 2019-08-20 klockan 21:05 -0300 skrev James Almer:
>> Should reduce date copying considerably.
>>
>> Signed-off-by: James Almer
>> ---
>> Fixed a stupid mistake when checking the return value for av_new_packet().
>> Still untested.
>
> Works great fo
On Tue, Aug 20, 2019 at 20:53:43 +0530, Shivam wrote:
> Please review,
(Untested, just visual code inspection.)
> +- DICOM decoder and demxer
Typo -> demuxer. Also, when splitting the commits, also split the
changes to the Changelog. (Can still be one line eventually.)
> +.props = A
On Tue, Aug 20, 2019 at 20:53:43 +0530, Shivam wrote:
> I have also uploaded DICOM samples here.
> https://1drv.ms/u/s!AosJ9_SrP4Tsh2WoPfQAI8cSsqUs?e=ZMd5fR
I found something else, with valgrind:
> +static int read_implicit_seq_item(AVFormatContext *s, DataElement *de)
> +{
> +int ret, f = -2
On Tue, Aug 20, 2019 at 20:53:43 +0530, Shivam wrote:
One more. Some more nitpicking around this. Please use valgrind with
all your samples and some demuxing and decoding command lines.
> +static int dicom_read_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +DICOMContext *dicom = s->priv_da
From: Aman Gupta
Signed-off-by: Aman Gupta
---
libavcodec/omx.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index a1e5a46a54..8c722b573c 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -802,6 +802,26 @@ static int omx_enc
Forwarded Message
Subject: Re: [FFmpeg-devel] [PATCH] lavf: Add DICOM demuxer, lavc: Add
DICOM decoder
Date: Thu, 22 Aug 2019 00:27:55 +0530
From: Shivam
To: Michael Niedermayer
On 8/21/19 2:00 AM, Michael Niedermayer wrote:
On Tue, Aug 20, 2019 at 08:53:43PM
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas
for luma and chroma planes, and an array of AVEncodeInfoBlock type
denoting position, size, and delta quantizer for each block in the
On Thu, Aug 15, 2019 at 11:00 AM Peter Collingbourne wrote:
>
> As of LLVM r368102, Clang will set a pointer tag in bits 56-63 of the
> address of a global when compiling with -fsanitize=hwaddress. This requires
> an adjustment to assembly code that takes the address of such globals: the
> code ca
From: elliottk
Current default is 256kbps, which produces inconsistent
results (too high for low-res, too low for hi-res).
Use CRF instead, which will adapt.
---
libavcodec/libaomenc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libaomenc.c b/libavcode
On Thu, Aug 22, 2019 at 00:28:28 +0530, Shivam wrote:
> >> + dicom->height = *(uint16_t *)bytes;
> > does this work on big endian ?
> > maybe you where looking for AV_RL16()
>
> Big endian DICOM files are retired and no longer supported by the standard.
What Michael means: What happens if you use
It appears that CRF=32 is a better default, since the scale is
different from other codecs. I will start a new thread.
On Tue, Aug 20, 2019 at 5:31 PM Elliott Karpilovsky wrote:
>
> I believe the documentation is out of date. I added some debug
> statements and verified that variable was being us
As of LLVM r368102, Clang will set a pointer tag in bits 56-63 of the
address of a global when compiling with -fsanitize=hwaddress. This requires
an adjustment to assembly code that takes the address of such globals: the
code cannot use the regular R_AARCH64_ADR_PREL_PG_HI21 relocation to refer
to
On Tue, 20 Aug 2019, Devin Heitmueller wrote:
A couple of follow-up Qs:
Is auto-detection available for all Decklink devices?
No, but AFAIK it is for all devices which support SDI. Generally it's
the older analog capture devices which don't support it.
For those for which it is available
On Sun, 18 Aug 2019, Tomas Härdin wrote:
lör 2019-08-17 klockan 21:41 +0200 skrev Marton Balint:
The return value was unintentionally lost after
00a2652df3bf25a27d174cc67ed508b5317cb115.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 dele
On Tue, 20 Aug 2019, Carl Eugen Hoyos wrote:
Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol :
I kindly ask that following commit: d702769213487923c0fb0abe4b61f4d9ebddb88b
I still believe what the patch does is a very good idea and a revert would
hurt FFmpeg.
If the patch is kept
Hey guys,
> On Aug 19, 2019, at 9:54 AM, Thomas Mundt wrote:
>
> Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin > :
>
>> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
>>> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
>> tjop...@acc.umu.se
:
ons 2019-08-1
On Mon, Aug 19, 2019 at 7:22 PM Carl Eugen Hoyos wrote:
>
> This score would mean that mjpeg can never be detected.
> I suspect you have to reduce one of the demuxers to "- 1".
>
>
Thanks Carl.
Attached patch to reduce mpeg probe by -1, which also fixes the issue.
Alternatively I could bump both
Fixes: out of array access
Fixes:
16277/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5696629440512000
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/vividas.c | 10 --
1 file
Fixes: Timeout (128sec -> 6sec)
Fixes:
16568/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IDCIN_fuzzer-5675004095627264
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 2
Fixes: memleak
Fixes:
16277/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5696629440512000
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/realtextdec.c | 2 ++
1 file changed, 2 inser
Fixes: undefined mempcpy() use
Fixes:
16302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5678750575886336
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/iff.c | 4
1
On 8/21/2019 7:18 PM, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes:
> 16277/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5696629440512000
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
example command line to verify it:
./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M
tmp.webm
Signed-off-by: Guo, Yejun
---
libavcodec/libvpxenc.c | 193 +
1 file changed, 193 insertions(+)
diff --git a/libavcodec/libvpxe
On Tue, Aug 20, 2019 at 5:31 PM Elliott Karpilovsky
wrote:
>
> I believe the documentation is out of date. I added some debug
> statements and verified that variable was being used to pull CRF
> values when AOM_Q mode is set. I have
> https://aomedia-review.googlesource.com/c/aom/+/94104 out to up
On Wed, Aug 21, 2019 at 12:18 PM Elliott Karpilovsky
wrote:
>
> From: elliottk
>
> Current default is 256kbps, which produces inconsistent
> results (too high for low-res, too low for hi-res).
> Use CRF instead, which will adapt.
> ---
> libavcodec/libaomenc.c | 9 +
> 1 file changed, 5
On 8/21/19 7:27 PM, Moritz Barsnick wrote:
On Tue, Aug 20, 2019 at 20:53:43 +0530, Shivam wrote:
Please review,
(Untested, just visual code inspection.)
+- DICOM decoder and demxer
Typo -> demuxer. Also, when splitting the commits, also split the
changes to the Changelog. (Can still be one
Hi!
On Tue, Aug 20, 2019 at 10:19 AM Michael Niedermayer
wrote:
>
> On Sun, Aug 18, 2019 at 12:32:03PM +0200, Stanislav Ionascu wrote:
> > Hi,
> >
> > thanks for looking into this.
> >
> > On Sun, Aug 18, 2019 at 4:55 AM Andreas Rheinhardt
> > wrote:
> > >
> > > Hello,
> > >
> > > I am no expert
50 matches
Mail list logo
