quietvoid:
> Tests the parsing and writing of AVDOVIDecoderConfigurationRecord,
> when it is present as a Dolby Vision configuration block addition mapping.
>
> Signed-off-by: quietvoid
> ---
> The required regression test file is available here: https://0x0.st/-hWK.mkv
> Should be moved to fate-
quietvoid:
> To avoid duplicating code. The implementation in dovi_isom is identical.
>
> Signed-off-by: quietvoid
> ---
> libavformat/mov.c | 50 +++
> 1 file changed, 7 insertions(+), 43 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/
quietvoid:
> On Fri, Dec 31, 2021 at 9:16 PM Andreas Rheinhardt
> wrote:
>>
>> quietvoid:
>>> Both parse/write implementations are based on mov/movenc.
>>>
>>> This only adds support for the "Dolby Vision configuration box".
>>> Other configuration boxes, such as
>>> "Dolby Vision enhancement laye
On Sun, Dec 12, 2021 at 3:12 PM Mark Reid wrote:
>
>
> On Wed, Nov 24, 2021 at 1:15 PM wrote:
>
>> From: Mark Reid
>>
>> changes since v2:
>> * fixed label
>> changes since v1:
>> * remove vex intruction on sse4 path
>> * some load/pack marcos use less intructions
>> * fixed some typos
>>
>
On Fri, Dec 31, 2021 at 9:16 PM Andreas Rheinhardt
wrote:
>
> quietvoid:
> > Both parse/write implementations are based on mov/movenc.
> >
> > This only adds support for the "Dolby Vision configuration box".
> > Other configuration boxes, such as
> > "Dolby Vision enhancement layer configuration b
Tests the parsing and writing of AVDOVIDecoderConfigurationRecord,
when it is present as a Dolby Vision configuration block addition mapping.
Signed-off-by: quietvoid
---
The required regression test file is available here: https://0x0.st/-hWK.mkv
Should be moved to fate-suite/mkv/dovi-p5.mkv
It
Improves code legibility by not using bit shifts.
Also avoids duplicating the dvcC/dvvC ISOM box writing code.
Signed-off-by: quietvoid
---
libavformat/movenc.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc
To avoid duplicating code. The implementation in dovi_isom is identical.
Signed-off-by: quietvoid
---
libavformat/mov.c | 50 +++
1 file changed, 7 insertions(+), 43 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 351ecde770..ad5
Adds handling of dvcC/dvvC block addition mappings.
The parsing creates AVDOVIDecoderConfigurationRecord side data.
The configuration block is written when muxing into Matroska,
if DOVI side data is present for the track.
Most of the Matroska element parsing is based on Plex's FFmpeg source code.
Both parse/write implementations are based on mov/movenc.
This only adds support for the "Dolby Vision configuration box".
Other configuration boxes, such as
"Dolby Vision enhancement layer configuration box" are not supported.
The new functions will be used to implement parsing/writing the DOVI
This patch set adds support for reading/writing the Matroska
BlockAdditionMapping
elements, as well as for reading/writing dvcC/dvvC blocks in Matroska.
Created utility functions to read/write Dolby Vision boxes for ISOM.
This was done to avoid duplicating the code, as the Matroska blocks and MOV
-Original Message-
From: ffmpeg-devel On Behalf Of Alex
Sent: 2022年1月1日 3:16
To: FFmpeg development discussions and patches
Subject: [FFmpeg-devel] DNN data layout CHW or HWC and data normalization or
denormalization?
Hi!
Can any one tell me is it layout of DNNData->data are chw or hw
quietvoid:
> Both parse/write implementations are based on mov/movenc.
>
> This only adds support for the "Dolby Vision configuration box".
> Other configuration boxes, such as
> "Dolby Vision enhancement layer configuration box" are not supported.
>
> The new functions will be used to implement
quietvoid:
> To avoid duplicating code. The implementation in dovi_isom is identical.
>
> Signed-off-by: quietvoid
> ---
> libavformat/mov.c | 52 ---
> 1 file changed, 9 insertions(+), 43 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/
quietvoid:
> Adds handling of dvcC/dvvC block addition mappings.
>
> The parsing creates AVDOVIDecoderConfigurationRecord side data.
> The configuration block is written when muxing into Matroska,
> if DOVI side data is present for the track.
>
> Most of the Matroska element parsing is based on P
Signed-off-by: John-Paul Stewart
---
libavformat/mvdec.c | 72 ++---
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c
index 0f0474141b..4f233aff5f 100644
--- a/libavformat/mvdec.c
+++ b/libavformat/mv
Only allocate an audio stream if there is one in the data. Silicon
Graphics movie format will contain default values (16 bit samples, 2
audio channels, 22050 Hz sample rate) even when no audio is present in
the file. This confuses FFmpeg into thinking such an audio stream is
present with 0 sample
Changed in v2:
Allocate the audio stream first to maintain consistent behaviour
with prior code.
Recent discussion on the list led me to realize that libavformat was
unconditionally creating an audio stream for all SGI movie format
(version 2) files, even when no audio is present in the fi
On 2021-12-31 19:33, Andreas Rheinhardt wrote:
> John-Paul Stewart:
>> On 2021-12-31 17:19, Andreas Rheinhardt wrote:
>>> John-Paul Stewart:
Recent discussion on the list led me to realize that libavformat was
unconditionally creating an audio stream for all SGI movie format
(version
John-Paul Stewart:
> On 2021-12-31 17:19, Andreas Rheinhardt wrote:
>> John-Paul Stewart:
>>> Recent discussion on the list led me to realize that libavformat was
>>> unconditionally creating an audio stream for all SGI movie format
>>> (version 2) files, even when no audio is present in the file.
On 2021-12-31 17:19, Andreas Rheinhardt wrote:
> John-Paul Stewart:
>> Recent discussion on the list led me to realize that libavformat was
>> unconditionally creating an audio stream for all SGI movie format
>> (version 2) files, even when no audio is present in the file.
>>
>> A sample of a mov
John-Paul Stewart:
> Recent discussion on the list led me to realize that libavformat was
> unconditionally creating an audio stream for all SGI movie format
> (version 2) files, even when no audio is present in the file.
>
> A sample of a movie file with no audio can be found at
> http://ww
Signed-off-by: John-Paul Stewart
---
libavformat/mvdec.c | 64 ++---
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c
index 7493bcc762..469ac32092 100644
--- a/libavformat/mvdec.c
+++ b/libavformat/mv
Only allocate an audio stream if there is one in the data. Silicon
Graphics movie format will contain default values (16 bit samples, 2
audio channels, 22050 Hz sample rate) even when no audio is present in
the file. This confuses FFmpeg into thinking such an audio stream is
present with 0 sample
Recent discussion on the list led me to realize that libavformat was
unconditionally creating an audio stream for all SGI movie format
(version 2) files, even when no audio is present in the file.
A sample of a movie file with no audio can be found at
http://www.personalprojects.net/ffmpeg/s
Hi,
On Mon, Dec 27, 2021 at 2:08 PM Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Dec 27, 2021 at 4:38 AM Eran Kornblau
> wrote:
>
>> > -Original Message-
>> > From: ffmpeg-devel On Behalf Of
>> Ronald S. Bultje
>> > Sent: Sunday, 26 December 2021 16:07
>> > To: FFmpeg development discussi
On Fri, Dec 31, 2021 at 10:45:46PM +0530, Gyan Doshi wrote:
>
>
> On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
> > On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
> > > On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
> > > > On Wed, 22 Dec 2021, at
Hi!
Can any one tell me is it layout of DNNData->data are chw or hwc or nchw or
nhwc?
And how to perform convertion from hwc to chw and reverse?
How to normalize and denormalize data (-1..0..1 <=> 0...255) ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
31 Dec 2021, 17:52 by mich...@niedermayer.cc:
> On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
>
>> On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
>> > On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
>> > > Is the December target to get into the featur
On 2021-12-31 11:12 pm, Romain Beauxis wrote:
* Implement support for AudioConverter
* Switch to AudioConverter's API to convert unsupported PCM
formats (non-interleaved, non-packed) to supported formats
* Minimize data copy.
This fixes: https://trac.ffmpeg.org/ticket/9502
API ref:
https:/
Signed-off-by: Romain Beauxis
—
[Sorry for the noise but an issue came up with the previous set]
This is the third patch of a series of 3 that fix, cleanup and enhance the
avfoundation implementation for libavdevice.
These patches come from an actual user-facing application relying on
libavdevic
* Use a CMSimpleQueueEnqueue with maximum length to queue and process incoming
audio and video frames.
* Log avfoundation errors.
* Use AVERROR_EXTERNAL instead of AVERROR(EIO) in avfoundation errors.
Signed-off-by: Romain Beauxis
—
[Sorry for the noise but an issue came up with the previous set
* Implement support for AudioConverter
* Switch to AudioConverter's API to convert unsupported PCM
formats (non-interleaved, non-packed) to supported formats
* Minimize data copy.
This fixes: https://trac.ffmpeg.org/ticket/9502
API ref:
https://developer.apple.com/documentation/audiotoolbox/aud
On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
Is the December target to get into the feature freez
Signed-off-by: James Almer
---
tests/fate/libswscale.mak | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/fate/libswscale.mak b/tests/fate/libswscale.mak
index 599d27b0a5..cf9319ec44 100644
--- a/tests/fate/libswscale.mak
+++ b/tests/fate/libswscale.mak
@@ -15,8 +15
On Fri, 31 Dec 2021, Andreas Rheinhardt wrote:
Marton Balint:
This makes sure the error condition is kept in AVIOContext even if the user
does not check the return value of avio_read_to_bprint or
ff_read_line_to_bprint.
Signed-off-by: Marton Balint
---
libavformat/aviobuf.c | 8 ++--
On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
> On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
> > On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
> > > Is the December target to get into the feature freeze schedule from
> > > distros?
> >
> > No, it
Signed-off-by: Romain Beauxis
—
This is the third patch of a series of 3 that cleanup and enhance the
avfoundation implementation for libavdevice.
Changes:
v2: None
v3:
* Switched unique ID to use system-prodvided unique ID
* Implemented unique IDs for screen capture
v4: Cleanup
v5: Fix ind
* Use a CMSimpleQueueEnqueue with maximum length to queue and process incoming
audio and video frames.
* Log avfoundation errors.
* Use AVERROR_EXTERNAL instead of AVERROR(EIO) in avfoundation errors.
Signed-off-by: Romain Beauxis
—
This is the second patch of a series of 3 that fix, cleanup and
* Implement support for AudioConverter
* Switch to AudioConverter's API to convert unsupported PCM
formats (non-interleaved, non-packed) to supported formats
* Minimize data copy.
This fixes: https://trac.ffmpeg.org/ticket/9502
API ref:
https://developer.apple.com/documentation/audiotoolbox/aud
> On Dec 28, 2021, at 6:54 PM, Aman Karmani wrote:
>
>
>
> On Tue, Dec 28, 2021 at 2:50 PM Romain Beauxis wrote:
> This is the first patch of a series of 3 that fix, cleanup and enhance the
> avfoundation implementation for libavdevice.
>
> The patches have been submitted a couple of times
31 Dec 2021, 14:25 by z...@zanevaniperen.com:
>
>
> On 31/12/21 21:19, Paul B Mahol wrote:
>
>> ++i instead of i++
>>
>
> You're right, I missed that. I'll submit a patch.
>
Revert it today or I will.
I NAK'd it from entering 5.0. It requires more fuzzing, more
testing and more reviewing. As for
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-12-15 13:35:34)
>> It is small (16 B) and therefore the overhead of exporting it more
>> than outweighs the size savings from not having duplicated symbols:
>> When the symbol is no longer avpriv, one saves twice the size of
>> the string containing
On 31/12/21 21:19, Paul B Mahol wrote:
++i instead of i++
You're right, I missed that. I'll submit a patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, o
Marton Balint:
> And move data shift function from movenc to utils.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/internal.h | 7 ++
> libavformat/movenc.c | 55 ++---
> libavformat/utils.c| 56 ++
> 3
Marton Balint:
> Signed-off-by: Marton Balint
> ---
> libavformat/segafilmenc.c | 51 ---
> 1 file changed, 5 insertions(+), 46 deletions(-)
>
> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
> index ff8cb66aca..737805faa6 100644
> --- a/li
Anton Khirnov:
> This object was never intended to be thread-safe, so these carry no
> useful information.
> ---
> libavutil/fifo.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/libavutil/fifo.c b/libavutil/fifo.c
> index 171c1aa9cd..f38e8ff089 100644
> --- a/libavutil/fifo.c
> +++
When editlist is disabled, the workaournd method of shift dts to
zero and increase the first sample duration doesn't work if the
timestamp is larger than mp4 spec restriction (e.g., sample_delta
in stts entry). Further more, it triggers get_cluster_duration()
assert failure. This patch will drop la
---
libavformat/movenc.c | 80 +---
1 file changed, 45 insertions(+), 35 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index f5bb785b01..9b3bd99e97 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5403,6 +5403,45 @@ s
---
libavformat/tests/movenc.c | 30 +-
tests/ref/fate/movenc | 14 ++
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
index 2af72f11c7..79de20ee75 100644
--- a/libavformat/tests/mov
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 9b3bd99e97..faae684fdb 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5465,7 +5465,7 @@ static int mov_flush_fragment(AVFormatContext *s,
Anton Khirnov:
> FLAC parser currently uses AVFifoBuffer in a highly non-trivial manner,
> modifying its "internals" (the whole struct is currently public, but no
> other code touches its contents directly). E.g. it does not use any
> av_fifo functions for reading the FIFO contents, but implements
++i instead of i++
On Fri, Dec 31, 2021 at 11:40 AM Zane van Iperen
wrote:
>
>
> On 31/12/21 19:40, Paul B Mahol wrote:
> > Why was this applied?
>
> >>
> >> Both patches lgtm, I'll apply in a few days if no objections.
> >>
>
> No one objected.
>
>
> > It still breaks style of ffmpeg code, just
This object was never intended to be thread-safe, so these carry no
useful information.
---
libavutil/fifo.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 171c1aa9cd..f38e8ff089 100644
--- a/libavutil/fifo.c
+++ b/libavutil/fifo.c
@@ -144,7 +144,
Trying to write too much will currently overwrite previous data. Trying
to read too much will either av_assert2() in av_fifo_drain() or return
old data. Trying to peek too much will either av_assert2() in
av_fifo_generic_peek_at() or return old data.
Return an error code in all these cases, which
This is the only remaining caller of av_fifo_peek2(), which will be
deprecated.
---
libavformat/dvenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/dvenc.c b/libavformat/dvenc.c
index 9a853ba7ce..b76539b59f 100644
--- a/libavformat/dvenc.c
+++ b/libavformat
av_realloc() the buffer and only move the part of the ring buffer that
needs it. Also avoids allocating a temporary fifo.
---
libavutil/fifo.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 5eee18a8
It returns a pointer inside the fifo's buffer, which cannot be safely
used without accessing AVFifoBuffer internals. It is easier and safer to
use av_fifo_generic_peek_at().
---
libavutil/fifo.h | 4
libavutil/tests/fifo.c | 8
libavutil/version.h| 1 +
tests/ref/fate/fi
FLAC parser currently uses AVFifoBuffer in a highly non-trivial manner,
modifying its "internals" (the whole struct is currently public, but no
other code touches its contents directly). E.g. it does not use any
av_fifo functions for reading the FIFO contents, but implements its own.
Reimplement t
Turn it into a wrapper around av_fifo_alloc_array().
---
libavutil/fifo.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 1060aedf13..5eee18a8c8 100644
--- a/libavutil/fifo.c
+++ b/libavutil/fifo.c
@@ -24,9 +24,10 @@
#i
Marton Balint:
> This makes sure the error condition is kept in AVIOContext even if the user
> does not check the return value of avio_read_to_bprint or
> ff_read_line_to_bprint.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/aviobuf.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 del
On 31/12/21 19:40, Paul B Mahol wrote:
Why was this applied?
Both patches lgtm, I'll apply in a few days if no objections.
No one objected.
It still breaks style of ffmpeg code, just from quick glance.
Which parts specifically?
The main potential issue I can see is the long scanf(
Andreas Rheinhardt:
> Currently, ff_mpv_encode_end() is the close function of
> the two MJPEG-based encoders; it calls ff_mjpeg_encode_close()
> for them which adds a check to the generic code.
> This commit reverses the order of this relationship:
> The MJPEG encoders directly use a custom close f
Why was this applied?
It still breaks style of ffmpeg code, just from quick glance.
Please revert or I leave this project forever.
On Tue, Dec 28, 2021 at 6:28 AM Zane van Iperen
wrote:
>
>
> On 27/12/21 10:47, p...@sandflow.com wrote:
> > From: Pierre-Anthony Lemieux
> >
> > Signed-off-by:
James Almer:
>
>
> On 12/30/2021 12:26 PM, Hendrik Leppkes wrote:
>> On Thu, Dec 30, 2021 at 4:13 PM James Almer wrote:
>>>
>>>
>>>
>>> On 12/30/2021 12:08 PM, Hendrik Leppkes wrote:
Aborting decoding of the entire packet on a missing PPS can result in
missing the actual PPS on streams
Pushed as 9cfc7a244052dced520776ff0ecc6f0a9390f62b
On 2021-12-28 10:12 pm, Gyan Doshi wrote:
Very high stts sample deltas may occasionally be intended but usually
they are written in error or used to store a negative value for dts correction
when treated as signed 32-bit integers.
This option l
66 matches
Mail list logo
