On Thu, May 21, 2020 at 8:14 AM Paul B Mahol wrote:
> Probably ok, except code style.
> Please keep code style consistent across files.
>
Thanks a lot for the feedback. I see a few inconsistently named variables,
maybe I used too many spaces in places. Could you tell me where is it that
you hav
James Almer:
> On 5/22/2020 12:31 AM, James Almer wrote:
>> On 5/21/2020 10:24 PM, Andreas Rheinhardt wrote:
>>> av_stream_get_side_data() tells the caller whether a stream has side
>>> data of a specific type; if present it can also tell the caller the size
>>> of the side data via an optional arg
On 5/22/2020 12:31 AM, James Almer wrote:
> On 5/21/2020 10:24 PM, Andreas Rheinhardt wrote:
>> av_stream_get_side_data() tells the caller whether a stream has side
>> data of a specific type; if present it can also tell the caller the size
>> of the side data via an optional argument. The Matroska
On 5/21/2020 10:24 PM, Andreas Rheinhardt wrote:
> by using a const void * pointer as an intermediate.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Why is the side-data API (both the packet as well as the stream one)
> actually based around uint8_t * and not pointers to void despite
> side-data
James Almer:
> On 5/21/2020 10:24 PM, Andreas Rheinhardt wrote:
>> av_stream_get_side_data() tells the caller whether a stream has side
>> data of a specific type; if present it can also tell the caller the size
>> of the side data via an optional argument. The Matroska muxer always
>> used this op
On 5/21/2020 10:24 PM, Andreas Rheinhardt wrote:
> av_stream_get_side_data() tells the caller whether a stream has side
> data of a specific type; if present it can also tell the caller the size
> of the side data via an optional argument. The Matroska muxer always
> used this optional argument, al
Andreas Rheinhardt:
> In order to parse a number from a string, the WebM DASH manifest muxer
> would duplicate (via heap-allocation) the part of the string that
> contains the number, then read the number via atoi() and then free the
> duplicate again. This has been replaced by simply using strtoll
Andreas Rheinhardt:
> by storing s->streams[i] in a pointer instead of constantly using
> s->streams[i]->...
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/segment.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/segment.c b/lib
Andreas Rheinhardt:
> Since commit c5324d92c5f206dcdc2cf93ae237eaa7c1ad0a40 all custom
> interleave_packet() functions always return clean packets (even on
> error), so that unreferencing manually can be removed.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mux.c | 5 +
> 1 file
by using a const void * pointer as an intermediate.
Signed-off-by: Andreas Rheinhardt
---
Why is the side-data API (both the packet as well as the stream one)
actually based around uint8_t * and not pointers to void despite
side-data being mostly structures and not just buffers?
libavformat/mat
Signed-off-by: Andreas Rheinhardt
---
Was the earlier behaviour actually a bug (I think so) or is this new
behaviour something that should be explicitly documented?
Btw, the stream and packet side-data APIs differ in two more ways:
av_packet_new_side_data() adds padding to the buffer and zeroes i
av_stream_get_side_data() tells the caller whether a stream has side
data of a specific type; if present it can also tell the caller the size
of the side data via an optional argument. The Matroska muxer always
used this optional argument, although it doesn't really need the size,
as the relevant s
On Mon, 20 Apr 2020, Kevin Wheatley wrote:
Activated when the -mov_timescale command line/MOVMuxContext
parameter is set to 0 or less. If the user passes any value
greater than 0, then it will be used as-is. The default
value is kept unchanged at 1000.
When active, it uses the base assumption
On Mon, 20 Apr 2020, Kevin Wheatley wrote:
Signed-off-by: Kevin Wheatley
---
libavformat/movenc.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
You should squash this patch with the previous.
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7
On Mon, 20 Apr 2020, Kevin Wheatley wrote:
Signed-off-by: Kevin Wheatley
---
libavformat/movenc.c | 1 +
libavformat/movenc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 253cff8..7d79eca 100644
--- a/libavformat/movenc.c
+++ b/libavfor
On Sun, 10 May 2020, Joey Smith wrote:
Updated patch attached
Thanks, applied.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpe
Andreas Rheinhardt:
> AVStream.request_probe as well as AVStream.mux_ts_offset are below the
> separator of public and private fields, so that a further "NOT PART OF
> PUBLIC API" is redundant.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I initially also wanted to remove the internal note for A
Hi!
When receiving jpeg frames via rtp, libavformat currently writes a
wrong JFIF version (2.01 instead of 1.02), see also 85ca012ba68.
Attached patch fixes the version.
Please comment, Carl Eugen
From cf3250c1f044a940336ce17484a1d783849ed71f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date:
Am Mi., 20. Mai 2020 um 22:21 Uhr schrieb Michael Niedermayer
:
>
> On Wed, May 20, 2020 at 08:48:41PM +0530, Gautam Ramakrishnan wrote:
> > On Tue, Apr 21, 2020 at 3:41 AM Michael Niedermayer
> > wrote:
> > >
> > > On Mon, Apr 20, 2020 at 04:13:44PM +0530, Gautam Ramakrishnan wrote:
> > > > On Mo
Am Mi., 20. Mai 2020 um 15:49 Uhr schrieb Martin Storsjö :
> Would it work better
[...]
Or we could go for the simple solution which somehow
became out-of-style here recently.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ff
On Thu, May 21, 2020 at 12:37 AM Michael Niedermayer
wrote:
> gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
> used with ccache on a x86-64
>
Huh, I guess there's no early abort for conditionals in a preprocessor
statement with __has_builtin for some reason. I've added a AV_HAS_BUILTIN
macro to workaro
avformat/mov: typo. when sidx time is found should assing it to pts instead
of dts
Fixes: AVPacket.dts was't monotonically increasing
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e11c9f4..b2132e6 100
On Thu, May 21, 2020 at 1:51 AM Michael Niedermayer
wrote:
>
> On Wed, May 20, 2020 at 08:48:41PM +0530, Gautam Ramakrishnan wrote:
> > On Tue, Apr 21, 2020 at 3:41 AM Michael Niedermayer
> > wrote:
> > >
> > > On Mon, Apr 20, 2020 at 04:13:44PM +0530, Gautam Ramakrishnan wrote:
> > > > On Mon, A
>> Has anybody proposed a patch to allow people to set that MOV_TIMESCALE
>> variable from the command line?
>> It seems that would be an easy patch to do and could be used to fix this and
>> numerous other requests for different movie timescales.
>> I looked for discussion on this and didn't fin
Hi!
Attached patch is supposed to fix ticket #8638.
Please comment, Carl Eugen
From 5349586a4c17727eafd770279e6768805fbb72a5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 21 May 2020 17:40:18 +0200
Subject: [PATCH] examples/hw_decode: Add binary mode to fopen() for non-POSIX
system
LGTM
On 5/19/20, mindm...@gmail.com wrote:
> From: Mark Reid
>
> ---
> libavfilter/vf_lut3d.c | 207 +++--
> 1 file changed, 201 insertions(+), 6 deletions(-)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 5/20/2020 9:34 PM, myp...@gmail.com wrote:
> On Wed, May 20, 2020 at 12:08 PM James Almer wrote:
>>
>> It's been a wrapper for a simple av_bsf_free() call since c96904f525.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/decode.c | 7 +--
>> libavcodec/decode.h | 2 --
>> libavcodec
On 5/21/2020 10:21 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-05-18 18:33:26)
>> Both are codec properties and not encoder capabilities. The relevant
>> AVCodecDescriptor.props flags exist for this purpose.
>>
>> Signed-off-by: James Almer
>> ---
>
> Don't know if it makes sense to bump
I kindly ask everybody including you to stop wasting time on
supporting only old opencv versions features, and instead to use such
resources in writing C++ filter wrapper with same name which will work
with latest opencv version.
Consider this module/file deprecated.
On 5/21/20, lance.lmw...@gmai
Probably ok, except code style.
Please keep code style consistent across files.
On 5/19/20, mindm...@gmail.com wrote:
> From: Mark Reid
>
> ---
> libavfilter/vf_lut3d.c | 367 +++--
> 1 file changed, 312 insertions(+), 55 deletions(-)
>
__
On Thu, May 21, 2020 at 04:44:26PM +0200, Paul B Mahol wrote:
> On 5/21/20, lance.lmw...@gmail.com wrote:
> > On Thu, May 21, 2020 at 04:12:56PM +0200, Paul B Mahol wrote:
> >> On 5/18/20, lance.lmw...@gmail.com wrote:
> >> > On Mon, May 18, 2020 at 01:11:12PM +0200, Paul B Mahol wrote:
> >> >> T
Anton Khirnov (12020-05-21):
> This is wrong. We should not fix warnings, we should fix bugs. Warnings
> suggest there may be a bug, but not all warnings are correct.
>
> In this case, I believe the warnings is invalid and there is no problem
> to fix. It's correct that the comparison is always fa
> [FFmpeg-devel] [PATCH] avutil/video_enc_param: fix warning
This is wrong. We should not fix warnings, we should fix bugs. Warnings
suggest there may be a bug, but not all warnings are correct.
In this case, I believe the warnings is invalid and there is no problem
to fix. It's correct that the
On Thu, May 21, 2020 at 04:34:57PM +0200, Carl Eugen Hoyos wrote:
> Am Do., 21. Mai 2020 um 16:21 Uhr schrieb :
> >
> > From: Limin Wang
> >
> > warning: comparison is always false due to limited range of data type
> > [-Wtype-limits]
> > Also nb_blocks is unsigned int, so nb_blocks * sizeof(AVVi
lance.lmw...@gmail.com (12020-05-21):
> I'm not sure, Mac compile give below warning:
>
> warning: comparison of constant 922337203685477580 with expression of type
> 'unsigned int' is always false
> [-Wtautological-constant-out-of-range-compare]
>
Certainly. And?
> > The cast is unnece
On Thu, May 21, 2020 at 04:34:39PM +0200, Nicolas George wrote:
> lance.lmw...@gmail.com (12020-05-21):
> > From: Limin Wang
> >
> > warning: comparison is always false due to limited range of data type
> > [-Wtype-limits]
>
> > Also nb_blocks is unsigned int, so nb_blocks * sizeof(AVVideoBlock
On 5/21/20, lance.lmw...@gmail.com wrote:
> On Thu, May 21, 2020 at 04:12:56PM +0200, Paul B Mahol wrote:
>> On 5/18/20, lance.lmw...@gmail.com wrote:
>> > On Mon, May 18, 2020 at 01:11:12PM +0200, Paul B Mahol wrote:
>> >> This opencv module is obsolete for latest opencv.
>> >>
>> >> Instead the
On Thu, May 21, 2020 at 04:12:56PM +0200, Paul B Mahol wrote:
> On 5/18/20, lance.lmw...@gmail.com wrote:
> > On Mon, May 18, 2020 at 01:11:12PM +0200, Paul B Mahol wrote:
> >> This opencv module is obsolete for latest opencv.
> >>
> >> Instead there should be C++ wrapper.
> >
> > Sorry, where is
Am Mo., 18. Mai 2020 um 13:11 Uhr schrieb Paul B Mahol :
>
> This opencv module is obsolete for latest opencv.
Which is not supported by FFmpeg so I don't think
this is a useful argument.
> Instead there should be C++ wrapper.
If you don't plan to implement the wrapper, it
shouldn't be an argume
Am Do., 21. Mai 2020 um 16:21 Uhr schrieb :
>
> From: Limin Wang
>
> warning: comparison is always false due to limited range of data type
> [-Wtype-limits]
> Also nb_blocks is unsigned int, so nb_blocks * sizeof(AVVideoBlockParams) may
> overflow,
> so force to size_t
>
> Signed-off-by: Limin W
lance.lmw...@gmail.com (12020-05-21):
> From: Limin Wang
>
> warning: comparison is always false due to limited range of data type
> [-Wtype-limits]
> Also nb_blocks is unsigned int, so nb_blocks * sizeof(AVVideoBlockParams) may
> overflow,
> so force to size_t
No it may not, the test just be
From: Limin Wang
warning: comparison is always false due to limited range of data type
[-Wtype-limits]
Also nb_blocks is unsigned int, so nb_blocks * sizeof(AVVideoBlockParams) may
overflow,
so force to size_t
Signed-off-by: Limin Wang
---
libavutil/video_enc_params.c | 4 ++--
1 file change
On 5/18/20, lance.lmw...@gmail.com wrote:
> On Mon, May 18, 2020 at 01:11:12PM +0200, Paul B Mahol wrote:
>> This opencv module is obsolete for latest opencv.
>>
>> Instead there should be C++ wrapper.
>
> Sorry, where is the C++ wrapper? Now Opencv 2.x and 3.x is good
> to use for my current func
On Tue, May 19, 2020 at 2:43 AM Marton Balint wrote:
>
>
>
> On Mon, 11 May 2020, Marton Balint wrote:
>
> > This will be used for AVCodecContext->profile. By specifying constants in
> > the
> > encoders we won't have to use the common AVCodecContext options table and
> > different encoders can u
Quoting Marton Balint (2020-05-18 20:43:45)
> Ping for the series, is there anybody against the approach I took to move
> profile name constants to encoders?
I like it. Wondered if sharing options like that might cause problems
but couldn't think of anything.
--
Anton Khirnov
__
Quoting James Almer (2020-05-18 18:33:26)
> Both are codec properties and not encoder capabilities. The relevant
> AVCodecDescriptor.props flags exist for this purpose.
>
> Signed-off-by: James Almer
> ---
Don't know if it makes sense to bump version just because something was
deprecated.
Other
Quoting Marton Balint (2020-05-20 20:26:53)
>
>
> You asked that why the AVProfiles list of the encoders should be different
> to the AVProfile lists stored in libavcodec/profiles.c. Or at least that's
> how I understood your question...
>
> Anyway, I'd still argue against the usage of AVCodec
On 18.05.2020 09:54, Roman Arzumanyan wrote:
Hello,
The patch fixes bug with CQ RC mode: max and average bitrate values were not
set to zero.
How to reproduce:
#CQ 30 file
ffmpeg \
-i big_buck_bunny_1080p_h264.mov -c:v h264_nvenc -preset medium \
-cq 30 -y output_cq30.mp4
#CQ 10 file
ffm
---
libavformat/Makefile | 1 +
tests/Makefile| 1 +
tests/fate-run.sh | 7 +
tests/fate/h264.mak | 6 +-
tests/fate/vpx.mak| 5 +
tests/ref/fate/h264-encparams | 404 +++
tests/ref/fate/vp9-encparams | 937 +
On Thu, May 21, 2020 at 12:13:15PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-05-21 08:59:27)
> >
> > I dont see IS_IRAP_NAL() and IS_IDR_NAL() to check every field in the
> > headers
> > to be consistent with IDR / IRAP NALs, which is what the tiff code in this
> > thread do
On Thu, 21 May 2020, Michael Niedermayer wrote:
On Wed, May 20, 2020 at 09:10:21AM +0300, Martin Storsjö wrote:
Sticking a full frame in the extradata works, as the code for writing
the avcC/hvcC extracts the relevant parameter set NAL units - provided
that they actually exist in the frame.
So
Move the copying of the frame to vos_data further up in the function,
so that when writing the actual frame data for the first frame, it's
clear that the stream really is in annex b format, for the cases where
we create extradata from the first frame.
Alternatively - we could invert the checks for
On Thu, 21 May 2020, Jan Ekström wrote:
On Thu, May 21, 2020 at 2:00 PM Martin Storsjö wrote:
Oh, indeed, you're right.
However wrong that is from the mov/mp4 point of view, it may very well be
that AVC intra is supposed to be written like this in mov/mp4 files - but
we'd need a word from so
On Thu, May 21, 2020 at 2:00 PM Martin Storsjö wrote:
>
> Oh, indeed, you're right.
>
> However wrong that is from the mov/mp4 point of view, it may very well be
> that AVC intra is supposed to be written like this in mov/mp4 files - but
> we'd need a word from somebody who actually knows that cas
Move the copying of the frame to vos_data further up in the function,
so that when writing the actual frame data for the first frame, it's
clear that the stream really is in annex b format, for the cases where
we create extradata from the first frame.
Alternatively - we could invert the checks for
On Thu, 21 May 2020, Andreas Rheinhardt wrote:
Martin Storsjö:
On Thu, 21 May 2020, Andreas Rheinhardt wrote:
Martin Storsjö:
On Thu, 21 May 2020, Michael Niedermayer wrote:
On Wed, May 20, 2020 at 09:10:21AM +0300, Martin Storsjö wrote:
Sticking a full frame in the extradata works, as th
Martin Storsjö:
> On Thu, 21 May 2020, Andreas Rheinhardt wrote:
>
>> Martin Storsjö:
>>> On Thu, 21 May 2020, Michael Niedermayer wrote:
>>>
On Wed, May 20, 2020 at 09:10:21AM +0300, Martin Storsjö wrote:
> Sticking a full frame in the extradata works, as the code for writing
> the a
On Thu, 21 May 2020, Andreas Rheinhardt wrote:
Martin Storsjö:
On Thu, 21 May 2020, Michael Niedermayer wrote:
On Wed, May 20, 2020 at 09:10:21AM +0300, Martin Storsjö wrote:
Sticking a full frame in the extradata works, as the code for writing
the avcC/hvcC extracts the relevant parameter s
On Tue, Apr 07, 2020 at 01:03:34PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: stack-buffer-overflow-READ-0x0831fff1
>
> Found-by: GalyCannon
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/aadec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
wil
On Fri, Feb 07, 2020 at 02:48:31PM +0100, Michael Niedermayer wrote:
> This should improve coverage
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/bitpacked.c | 4
> 1 file changed, 4 insertions(+)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611E
On Sun, Feb 16, 2020 at 08:43:01PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -9223372036854775808 - 45000 cannot be
> represented in type 'long'
> Fixes: ticket8187
>
> Found-by: Suhwan
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mpegenc.c | 2 +-
> 1 file
On Sun, Feb 16, 2020 at 08:43:00PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 3299 * 256 cannot be represented in type
> 'int'
> Fixes: ticket8184
>
> Found-by: Suhwan
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/swfenc.c | 2 +-
> 1 file changed, 1 inse
On Sun, Apr 26, 2020 at 11:12:17PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -717241856 + -1434459904 cannot be
> represented in type 'int'
> Fixes:
> 21405/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5677143666458624
>
> Found-by: continuous fu
On Fri, Mar 20, 2020 at 01:03:35AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 21104/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5129580475318272
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signe
On Sat, May 02, 2020 at 11:08:07PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -1238335488 + -1003634688 cannot be
> represented in type 'int'
> Fixes:
> 21649/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-5112005765890048
>
> Found-by: continuous fuzzing
On Mon, May 04, 2020 at 10:10:00PM +0200, Michael Niedermayer wrote:
> Fixes: division by zero
> Fixes:
> 21677/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DSD_MSBF_fuzzer-5712547983654912
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ff
On Sat, May 16, 2020 at 06:37:32PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 65535 * 55335 cannot be represented in type
> 'int'
> Fixes:
> 21955/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5669206981083136
>
> Found-by: continuous fuzzing process
>
On Wed, May 13, 2020 at 01:06:26AM +0200, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes:
> 21666/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO4_fuzzer-5706468994318336
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffm
Quoting Michael Niedermayer (2020-05-21 08:59:27)
>
> I dont see IS_IRAP_NAL() and IS_IDR_NAL() to check every field in the headers
> to be consistent with IDR / IRAP NALs, which is what the tiff code in this
> thread does kind off ..
>
> to match hevc, i could add something like
> #define HAVE_T
Martin Storsjö:
> On Thu, 21 May 2020, Michael Niedermayer wrote:
>
>> On Wed, May 20, 2020 at 09:10:21AM +0300, Martin Storsjö wrote:
>>> Sticking a full frame in the extradata works, as the code for writing
>>> the avcC/hvcC extracts the relevant parameter set NAL units - provided
>>> that they
On Thu, 21 May 2020, Michael Niedermayer wrote:
On Wed, May 20, 2020 at 09:10:21AM +0300, Martin Storsjö wrote:
Sticking a full frame in the extradata works, as the code for writing
the avcC/hvcC extracts the relevant parameter set NAL units - provided
that they actually exist in the frame.
So
This fixes test failures in fate-cbs-hevc-* in certain configurations
since c53f9f436440be4e18.
---
Not sure if this is what was intended, but the current code doesn't
work at least.
---
libavcodec/cbs_h265_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libav
On Wed, May 20, 2020 at 09:10:21AM +0300, Martin Storsjö wrote:
> Sticking a full frame in the extradata works, as the code for writing
> the avcC/hvcC extracts the relevant parameter set NAL units - provided
> that they actually exist in the frame.
>
> Some encoders don't provide split out extrad
On Wed, May 20, 2020 at 01:02:39PM -0700, Dale Curtis wrote:
> On Wed, May 20, 2020 at 1:17 AM Michael Niedermayer
> wrote:
>
> >
> > In file included from ./libavutil/avutil.h:296:0,
> > from ./libavutil/log.h:25,
> > from ./libavutil/thread.h:34,
> >
On Thu, 21 May 2020, Kaplan, John wrote:
Hi Guys,
I've just finished a bunch of research on encoding audio .flac files into
MP4/AAC using ffmpeg, and we're seeing a detail in the header data that is
keeping some audio players from correctly interpreting the metadata in the MP4
elst box.
L
On Thu, Feb 27, 2020 at 12:07:16PM -0300, James Almer wrote:
> On 2/27/2020 11:10 AM, Carl Eugen Hoyos wrote:
> > Am Do., 27. Feb. 2020 um 15:05 Uhr schrieb Anton Khirnov
> > :
> >>
> >> Quoting Michael Niedermayer (2020-02-19 16:49:51)
> >>> TIFF 6 spec: "Do not use both strip-oriented and tile-o
76 matches
Mail list logo
