Hi all,
any chance someone could possibly have a look at this patch, please?
Thanks in advance
Elias
On Wed, 2023-05-03 at 12:27 +, Carotti, Elias wrote:
> Sorry to revive an old thread, but I updated the patch for ffmpeg 6
> and
> this new patch should address the comments.
> Still this is
Sorry to revive an old thread, but I updated the patch for ffmpeg 6 and
this new patch should address the comments.
Still this is a libx264-only patch, and provides a means to specify
that only portions of the frame have changed from the previous one
while the others should be P_SKIP-ped.
More
Anton Khirnov:
> Quoting Andreas Rheinhardt (2022-06-23 16:21:18)
>> Anton Khirnov:
>>> Quoting Carotti, Elias (2022-06-21 10:48:07)
Hi,
extending AVVideoEncParams was the first hypothesis I made but it
didn't seem it was the proper place to add the mb_info flags.
I
Quoting Andreas Rheinhardt (2022-06-23 16:21:18)
> Anton Khirnov:
> > Quoting Carotti, Elias (2022-06-21 10:48:07)
> >> Hi,
> >>
> >> extending AVVideoEncParams was the first hypothesis I made but it
> >> didn't seem it was the proper place to add the mb_info flags.
> >>
> >> I may be wrong but my
Anton Khirnov:
> Quoting Carotti, Elias (2022-06-21 10:48:07)
>> Hi,
>>
>> extending AVVideoEncParams was the first hypothesis I made but it
>> didn't seem it was the proper place to add the mb_info flags.
>>
>> I may be wrong but my impression is that AVVideoEncParams is used to
>> carry encoding
Quoting Carotti, Elias (2022-06-21 10:48:07)
> Hi,
>
> extending AVVideoEncParams was the first hypothesis I made but it
> didn't seem it was the proper place to add the mb_info flags.
>
> I may be wrong but my impression is that AVVideoEncParams is used to
> carry encoding parameters read from
Quoting Carotti, Elias (2022-06-17 10:41:30)
> Hi all,
> any chance someone could possibly have a look at this patch, please?
> Thanks in advance
This looks like it belongs in AVVideoEncParams.
--
Anton Khirnov
___
ffmpeg-devel mailing list
On date Friday 2022-06-17 17:10:25 +0200, Timo Rothenpieler wrote:
> On 17.06.2022 12:59, Carotti, Elias wrote:
[...]
> > Again, you don't have to pass the ownership, and in fact in my use case
> > I do not pass it since I actually recycle and update the same buffer
> > for subsequent frames. If
On 17.06.2022 12:59, Carotti, Elias wrote:
Yes, exactly. It relies on x264 to free it.
Not really. It can rely on x264 if you explicitly want that behavior.
If you do not set a deallocator, it remains the caller responsibility.
What happens if x264 is not involved, but some other encoder,
On 17.06.2022 12:15, Carotti, Elias wrote:
Hi,
thanks for pointing out the printf. That's a left over which I removed.
I am not clear on the possible leak you are hinting at.
The new side information only passes two pointers to libx264, the first
one being a buffer with the flags and a pointer
On 17.06.2022 10:41, Carotti, Elias wrote:
Hi all,
any chance someone could possibly have a look at this patch, please?
Thanks in advance
On Fri, 2022-06-10 at 10:11 +, Carotti, Elias wrote:
Hi,
patch attached to add support for passing down to libx264 information
about which macroblock
11 matches
Mail list logo
