On 11/03/2023 18:05, Anton Khirnov wrote:
Since these are external encoders not under our control, we cannot test
the encoded output exactly as is done for internal encoders. We can
still test however that the output is decodable and produces the
expected number of frames with expected dimension
On 10/03/2023 22:10, Marton Balint wrote:
On Mon, 6 Mar 2023, Nicolas Gaullier wrote:
[...]
Some weeks later now and no replies, maybe time to go on ?
I think the "case AV_CODEC_ID_DVVIDEO:" can be removed as discussed,
fate updated and that should be ok for everybody.
(Ideally, it could ha
On 31/01/2023 15:53, Tomas Härdin wrote:
sön 2023-01-29 klockan 11:36 -0500 skrev Dave Rice:
On Jan 20, 2023, at 10:17 AM, Tomas Härdin wrote:
ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez:
On 18/01/2023 14:40, Tomas Härdin wrote:
Creating a new subthread because I just noticed
Please consider the attached patch.
Before: "Overread buffer. Invalid header?" despite that all bytes are
there (the precheck is wrong, not the parsing after the precheck)
After: transcoding is fine
A (zeroed) sample file is available at https://trac.ffmpeg.org/ticket/10259
Jérôme
On 19/10/2
On 3/14/2023 3:33 AM, Lynne wrote:
The attached patchset is all the common code changes that my Vulkan patchset
needs.
In total lines of code, this part has 425 additions and 131 deletions.
Most of that is additions to HEVC parsing. Excluding them, the patchset is
200 lines of code added, which
Quoting zhilizhao(赵志立) (2023-03-02 11:41:30)
>
>
> > On Mar 2, 2023, at 18:11, Anton Khirnov wrote:
> >
> > Quoting zhilizhao(赵志立) (2023-02-28 10:00:15)
> >>
> >>> On Jan 6, 2023, at 23:52, Zhao Zhili wrote:
> >>>
> >>> From: Zhao Zhili
> >>>
> >>> v2:
> >>> 1. Check vps_max_layers and vps
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 *av
Raphaël Zumer:
> 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
Can I help in any way in advancing this patch?
On 03/02/2023 15:18, Francesco Carusi wrote:
On 30/01/2023 13:19, Paul B Mahol wrote:
On 1/30/23, Francesco Carusi wrote:
On 28/01/2023 16:32, Paul B Mahol wrote:
On 1/28/23, Francesco Carusi wrote:
On 27/01/2023 18:31, Paul B Mahol wrote:
On Tue, Mar 14, 2023 at 4:59 PM Francesco Carusi
wrote:
> Can I help in any way in advancing this patch?
>
I will apply it if nobody objects in next 48h.
>
> On 03/02/2023 15:18, Francesco Carusi wrote:
> >
> >
> > On 30/01/2023 13:19, Paul B Mahol wrote:
> >> On 1/30/23, Francesco Carusi wro
On Mon, 2023-03-06 at 20:02 +0800, Zhao Zhili wrote:
> From: Zhao Zhili
>
> This patchset adds support of demux/mux PCM in mp4, and related channel
> layout information. PCM in mp4 is defined by ISO/IEC 23003-5. The channel
> layout tag 'chn' is defined by ISO/IEC 14496-12 with reference to ISO/I
On 2023-03-14 04:37:17+0100, Andreas Rheinhardt wrote:
> The reason we write it the way we do is that webvtt is muxed differently
> in Matroska than WebM. This needs to be fixed, too, before S_TEXT/WEBVTT
> can be used for Matroska.
Ah, I see. I wasn't aware of the differences in muxing. Thanks fo
This allows weird subsampling with progressive JPEGs to be decoded,
such as full-RG and only B subsampled.
---
libavcodec/mjpegdec.c | 38 --
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index c833
On Sat, Mar 11, 2023 at 11:54:52AM +0100, Anton Khirnov wrote:
> These fields are supposed to store information about the packet the
> frame was decoded from, specifically the byte offset it was stored at
> and its size.
>
> However,
> - the fields are highly ad-hoc - there is no strong reason why
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 this)
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/libda
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 insertion
17 matches
Mail list logo
