On 2025-05-23T13:55:57.000+02:00, Michael Niedermayer
wrote:
> On Fri, May 23, 2025 at 11:33:40AM +0200, Timothée wrote:
>
>> On 2025-05-23T02:57:36.000+02:00, Michael Niedermayer
>> wrote:
>>
>>> On Fri, May 23, 2025 at 02:45:59AM +0200
The 2025-05-22T14:33:22.000+02:00, Ramiro Polla
wrote :
> Hi,
>
> On Thu, May 22, 2025 at 1:59 PM Ronald S. Bultje wrote:
>
>> On Wed, May 21, 2025 at 9:34 AM Timothée <
>> timothee.informati...@regaud-chapuy.fr> wrote:
>>
>>> I am int
On 2025-05-23T02:57:36.000+02:00, Michael Niedermayer
wrote:
> On Fri, May 23, 2025 at 02:45:59AM +0200, Michael Niedermayer wrote:
>
>> Hi Ronald On Thu, May 22, 2025 at 07:59:06AM -0400, Ronald S.
>> Bultje wrote:
>>
>>> Hi, On Wed,
e or information that might help me
contribute effectively.
Thank you for your time and consideration.
Timothée
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
ff_h264_decode_mb_cabac() and ff_h264_decode_mb_cavlc() already
set qscale_table on their own (on success), so that all the changes to
h264_slice.c seem completely redundant.
- Andreas
Here is a new version of the patch without the redundant lines.
Thanks,
Timothée
qp_table.c |3 ++-
qp_table.h
Context from the first version : Subject was "avcodec/h264: fixed qp table attach
for h264"
Here is a patch where I fixed the attach of per-macroblock qp tables for
H.264. It was implemented for MPEG2 so I have only extended it.
I tested the functionality with the codecview filter using the f
, H266
We cannot have a incompatible data structure for each standard
in public API
I was focusing on H.264 but it will be easier in the long term if I
implement it in a more flexible way.
missing entry in sd_props[]
It fixed the error. Thank's !
Tim
nt to make it more
generic to be compatible with other codecs, that seems to be the correct
place.
Thanks,
Timothée
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abov
On 18/07/2025 19:42, Lynne a wrote :
On 18/07/2025 19:30, Timothée Regaud wrote:
From: Timothee Regaud
Adds the generic data structures to libavutil. The design is
recursive to support other codecs, even though the implementation is
only for H.264 for now.
Signed-off-by: Timothee Regaud
On 18/07/2025 17:48, Michael Niedermayer wrote :
Hi
On Fri, Jul 18, 2025 at 12:30:52PM +0200, Timothée Regaud wrote:
From: Timothee Regaud
Adds the generic data structures to libavutil. The design is recursive to
support other codecs, even though the implementation is only for H.264 for now
From: Timothee Regaud
Hooks into the H.264 decoder to populate the new generic video coding info
structures. It handles allocation of the side data buffer, collection of
modes/MVs/refs for all macroblock types, and attach the final side data buffer
to the output frame.
This should serve as a
From: Timothee Regaud
The filter now checks for AV_FRAME_DATA_VIDEO_CODING_INFO and contains a
recursive logging function to traverse the block-partitioning tree. This
demonstrates how a consumer would parse the new generic data structure.
Signed-off-by: Timothee Regaud
---
libavfilter/vf_co
From: Timothee Regaud
Adds the generic data structures to libavutil. The design is recursive to
support other codecs, even though the implementation is only for H.264 for now.
Signed-off-by: Timothee Regaud
---
libavutil/Makefile| 1 +
libavutil/frame.h | 7 ++
lib
From: Timothee Regaud
Adds the AV_CODEC_EXPORT_DATA_VIDEO_CODING_INFO flag and the corresponding
video_coding_info option to the options table, allowing users to enable this
feature.
Signed-off-by: Timothee Regaud
---
libavcodec/avcodec.h | 6 ++
libavcodec/options_table.h | 1 +
2
14 matches
Mail list logo
