...@tebako.net wrote:
From: Raphaël Zumer
This is an alias for JEDEC P22.
The name associated with the value is also changed
from "jedec-p22" to "ebu3213" to match ITU-T H.273.
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 3 +++
libavutil/pixdesc.c | 2 +-
lib
It's been about 3 weeks, so sending a reminder in case anyone can review
this.
On 2019-08-11 9:54 a.m., rzu...@tebako.net wrote:
From: Raphaël Zumer
This is an alias for JEDEC P22.
The name associated with the value is also changed
from "jedec-p22" to "ebu3213" to match
On 2019-08-09 7:51 a.m., Vittorio Giovara wrote:
this value was already present, this is just a rename
I think it counts as a new enum value (variant), even though it aliases
another.
I initially wrote "rename", but reworded the commit message based on
James Almer's comment:
The subject
Signed-off-by: Raphaël Zumer
---
libavformat/ivfenc.c | 3 ++-
libavformat/version.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index adf72117e9..54327f5025 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
The IVF format includes a 4-byte field for the number of frames.
I could not find a specification to cite, but for example,
the Chromium IVF parser handles this field.
Please see:
https://chromium.googlesource.com/chromium/src/media/+/master/filters/ivf_parser.h
On Tue, 2019-10-01 at 15:57 -0400, Calvin Walton wrote:
> On Tue, 2019-10-01 at 21:41 +0200, Carl Eugen Hoyos wrote:
> > Am Di., 1. Okt. 2019 um 21:35 Uhr schrieb Raphaël Zumer <
> > rzu...@tebako.net>:
> > > On Tue, 2019-10-01 at 20:09 +0100, Derek Buitenhuis wro
There is no change in the encoded bitstream, but this
ensures that the written field length is consistent
with the reference implementation.
Unused bytes are zeroed out for backwards compatibility.
Signed-off-by: Raphaël Zumer
---
libavformat/ivfenc.c | 3 ++-
1 file changed, 2 insertions
Signed-off-by: Raphaël Zumer
---
libavformat/ivfdec.c | 3 ++-
libavformat/ivfenc.c | 5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
index 40ae464b76..2fdb6f5a04 100644
--- a/libavformat/ivfdec.c
+++ b/libavformat/ivfdec.c
On Tue, 2019-10-01 at 20:09 +0100, Derek Buitenhuis wrote:
> On 01/10/2019 18:25, James Almer wrote:
> > The value in the unused field will be 0x after this change
> > instead of 0, since you're writing 32 bits as duration instead of
> > 64
> > where the high 32 bits (corresponding to the
This is a superset of my patch(es). It should match the behavior of
libvpx more closely, but the validity of the change from duration to
number of frames depends on your interpretation of the reference
implementation, which comments the field as "length".
On Tue, 2019-10-01 at 23:41 +0530, Gyan
Thank you for the review. I have left the encoded value as 64 bits and
split the patch into two in the v2 just sent: one for the decoder
change in field size, and one for the encoder comments.
On Tue, 2019-10-01 at 14:25 -0300, James Almer wrote:
> On 10/1/2019 2:05 PM, Raphaël Zumer wr
Signed-off-by: Raphaël Zumer
---
libavformat/ivfenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index adf72117e9..ae461a872b 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -53,7 +53,7 @@ static int
Signed-off-by: Raphaël Zumer
---
libavformat/ivfdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
index 40ae464b76..4a802573e7 100644
--- a/libavformat/ivfdec.c
+++ b/libavformat/ivfdec.c
@@ -53,7 +53,8 @@ static int
Just sending a reminder for my set of patches (the set of v2 patches up
in the thread and this one). Are there any further comments?
Thanks
Raphaël Zumer
On Wed, 2019-10-02 at 09:04 -0400, Raphaël Zumer wrote:
> There is no change in the encoded bitstream, but this
> ensures that the w
av_malloc()
and is directly accessible through the data field. Am I missing some detail?
Raphaël Zumer
On 3/12/23 15:48, Anton Khirnov wrote:
> Quoting Raphaël Zumer (2023-03-02 22:43:29)
>> +/**
>> + * Serialize dynamic HDR10+ metadata to a user data registered ITU-T T.35
>> buf
On 3/12/23 17:52, James Almer wrote:
> On 3/12/2023 6:50 PM, Raphaël Zumer wrote:
>> I expanded on this in another email in the chain, but the buffer size needs
>> to be communicated to the user, as it is not embedded in the payload. It
>> seems needlessly convoluted to me
On 3/13/23 19:25, James Almer wrote:
>>> You are allocating without any padding. This implies that one could not
>>> use this buffer with our GetBit-API or in other places where one needed
>>> a padded buffer.
>> Is there any comparable code that does that? I feel like padding a buffer
>> should
On 3/13/23 18:35, Andreas Rheinhardt wrote:
> size being mandatory is different from similar APIs. There is even a
> usecase without size: If you simply feed this to something that expects
> the data to be serialized and trust the data to be complete, you don't
> need the size.
OK, I'll amend
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 6 +-
libavcodec/av1dec.c | 6 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavcodec
Co-authored-by: Mohammad Izadi
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 148 +++
libavutil/hdr_dynamic_metadata.h | 13 +++
libavutil/version.h | 2 +-
4 files changed, 167
On 3/13/23 20:44, Andreas Rheinhardt wrote:
>> diff --git a/libavutil/hdr_dynamic_metadata.h
>> b/libavutil/hdr_dynamic_metadata.h
>> index 2d72de56ae..3d327241c1 100644
>> --- a/libavutil/hdr_dynamic_metadata.h
>> +++ b/libavutil/hdr_dynamic_metadata.h
>> @@ -340,4 +340,15 @@ AVDynamicHDRPlus
Co-authored-by: Mohammad Izadi
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 148 +++
libavutil/hdr_dynamic_metadata.h | 13 +++
libavutil/version.h | 2 +-
4 files changed, 167
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 6 +-
libavcodec/av1dec.c | 6 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavcodec
On 3/13/23 20:44, Andreas Rheinhardt wrote:
> Looking at the calculation in av_dynamic_hdr_plus_to_t35(), it seems
> that the maximum bitlength of a valid ITU-T T.35 payload is
> 48+2×937+27+1+10+25×25×4+3×82+(3×15×24)+(1+10+25×25×4+3×1)+(3×(28+15×10))+3+3×6
> = 8855 bits (please double-check
On 3/13/23 12:58, James Almer wrote:
> On 3/13/2023 1:56 PM, Raphaël Zumer wrote:
>> On 3/13/23 12:09, Andreas Rheinhardt wrote:
>>>>
>>>> +/**
>>>> + * Parse the user data registered ITU-T T.35 to AVbuffer
>>>> (AVDynamicHDRV
anything.
Thanks,
Raphaël Zumer
On 3/2/23 16:43, Raphaël Zumer wrote:
> Fixed brace style and moved inline buffer size calculation comments to a
> single block at the top.
>
>
> Signed-off-by: Raphaël Zumer
> ---
> libavutil/hdr_dynamic_metadata.c | 142 +++
> + int size);
> Who has an interest in this function being public?
>
> - Andreas
I have no need for it so can change it to avpriv_ considering there's no
serialization function available for it, if there's no objection to that.
Raphaël Zumer
__
On 3/13/23 13:10, James Almer wrote:
> On 3/13/2023 2:05 PM, Raphaël Zumer wrote:
>> On 3/13/23 12:58, James Almer wrote:
>>> On 3/13/2023 1:56 PM, Raphaël Zumer wrote:
>>>> On 3/13/23 12:09, Andreas Rheinhardt wrote:
>>>>>>
>>>>
On 3/13/23 18:19, James Almer wrote:
> On 3/13/2023 6:38 PM, Raphaël Zumer wrote:
>> diff --git a/libavutil/hdr_dynamic_metadata.c
>> b/libavutil/hdr_dynamic_metadata.c
>> index 0fa1ee82de..98f399b032 100644
>> --- a/libavutil/hdr_dynamic_metadata.c
>> +++ b
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 2 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavutil/hdr_dynamic_metadata.c | 180
On 3/13/23 16:47, James Almer wrote:
> On 3/13/2023 5:23 PM, Raphaël Zumer wrote:
>> Signed-off-by: Raphaël Zumer
>> ---
>> doc/APIchanges | 5 ++
>> libavutil/hdr_dynamic_metadata.c | 146 +++
>> libav
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile | 6 +-
libavcodec/av1dec.c | 6 +-
libavcodec/dynamic_hdr10_plus.c | 198 ---
libavcodec/dynamic_hdr10_plus.h | 35 --
libavcodec/h2645_sei.c | 6 +-
libavcodec
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 146 +++
libavutil/hdr_dynamic_metadata.h | 12 +++
libavutil/version.h | 2 +-
4 files changed, 164 insertions(+), 1 deletion(-)
diff --git
Co-authored-by: Mohammad Izadi
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 5 ++
libavutil/hdr_dynamic_metadata.c | 145 +++
libavutil/hdr_dynamic_metadata.h | 13 +++
libavutil/version.h | 2 +-
4 files changed, 164
On 3/2/23 15:24, Leo Izen wrote:
> On 3/2/23 14:25, Raphaël Zumer wrote:
>> Signed-off-by: Raphaël Zumer
>> ---
>> libavutil/hdr_dynamic_metadata.c | 146 +++
>> libavutil/hdr_dynamic_metadata.h | 11 +++
>> libavutil/version.h
Fixed brace style and moved inline buffer size calculation comments to a single
block at the top.
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 142 +++
libavutil/hdr_dynamic_metadata.h | 11 +++
libavutil/version.h | 2 +-
3
header (country
code, terminal provider code, etc.) and the remainder of the payload, so the
AV1 specification does not conform either to other implementations nor to the
standard. Following the most authoritative document is the safest route in my
op
ion 8.3.1 of ITU-T Rec. H.274 as well as
> section D.2.6 of ITU-T Rec. H.265.
>
> So i think this function should not set the country code at all as part
> of the payload, and start with itu_t_t35_terminal_provider_code.
OK, I will make that change
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 146 +++
libavutil/hdr_dynamic_metadata.h | 11 +++
libavutil/version.h | 2 +-
3 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/libavutil/hdr_dynamic_metadata.c b
commit, or with both of them, considering there are public API changes
associated with each one.
Raphaël Zumer
Signed-off-by: Raphaël Zumer
---
libavcodec/Makefile| 3 +-
libavcodec/dynamic_hdr10_plus.c| 198 -
libavcodec
Resent due to my mail client incorrectly re-wrapping lines in the version I
sent earlier.
See the previous patch for context.
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 147 +++
libavutil/hdr_dynamic_metadata.h | 10 +++
libavutil/version.h
to do that, but I will be happy to consider alternative
solutions.
Please let me know if it is preferred to bump libavutil with the first
commit, or with both of them, considering there are public API changes
associated with each one.
Raphaël Zumer
Signed-off-by: Raphaël Zumer
See the previous patch for context.
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 147 +++
libavutil/hdr_dynamic_metadata.h | 10 +++
libavutil/version.h | 2 +-
3 files changed, 158 insertions(+), 1 deletion(-)
diff --git
?) but will add that once
other details are sorted out.
Thanks,
Raphaël Zumer
Signed-off-by: Raphaël Zumer
---
libavcodec/codec_par.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
index 775c187073
implementation of the pcmC box) will continue to fail decoding due to the
sample size not being available. I see that it was assumed to be 16-bit before
commit d4ee17.
Signed-off-by: Raphaël Zumer
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
of the alternative implementations comes out cleaner
(*probably* a separate function due to the multiple call locations) and either
send a v2 RFC patch or separate set later.
Raphaël Zumer
On 7/25/23 14:53, Anton Khirnov wrote:
Quoting Vittorio Giovara
Any comments on this patch? If no objections
Hello,
On 7/26/23 00:09, "zhilizhao(赵志立)" wrote:
On Jul 26, 2023, at 00:28, Raphaël Zumer wrote:
Encoding PCM in MP4 currently causes subsequent decoding to fail due to a
sample size of 0.
This doesn’t give a context on which case the sample size is 0.
Using FFmpeg (round-trip)
th FFmpeg, whereas bits_per_coded_sample has the correct
value from the samples that I tested.
Raphaël Zumer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On 7/26/23 11:37, Zhao Zhili wrote:
I think you mixed up PCM in mp4 (-f mp4) and PCM in quicktime format (-f mov).
There is no support of mux PCM in mp4 before the patch. And demux PCM in mp4
only works by chance.
Let's focus on improve current situation, there isn't much to look back.
I
On 7/26/23 11:22, Zhao Zhili wrote:
From: ffmpeg-devel On Behalf Of Raphaël Zumer
Sent: 2023年7月26日 21:38
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: fix sample size being
zero in pcmC
On 7/25/23 23:45, Zhao Zhili wrote:
From: Zhao Zhili
-avio_w8
50 matches
Mail list logo
