From: Zhao Zhili
It's well known that mediacodec encoder requires 16x16 alignment.
Use our bsf to fix the crop info.
---
v3: don't change the dimension for AV_PIX_FMT_MEDIACODEC. It can have
side effect.
configure | 2 +
libavcodec/mediacodecenc.c | 78
So, as was discussed at the last meeting, we should move towards
removing YUVJ. I want to gather feedback on what appears to be to the
major hurdle, and possible ways to solve it.
The basic major issue is how to handle the case of combining limited
range input with an encoder for a format that onl
3. :)
On Fri, 9 Dec 2022, at 12:49, Niklas Haas wrote:
> So, as was discussed at the last meeting, we should move towards
> removing YUVJ. I want to gather feedback on what appears to be to the
> major hurdle, and possible ways to solve it.
>
> The basic major issue is how to handle the case of co
On Fri, 09 Dec 2022 13:10:02 +0100 Andreas Rheinhardt
wrote:
> This is incorrect: Here are the pixel formats advertised by the mjpeg
> encoder:
>
> .p.pix_fmts = (const enum AVPixelFormat[]) {
> AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
> AV_PIX_FMT_Y
On 12/9/22, Niklas Haas wrote:
> On Fri, 09 Dec 2022 13:10:02 +0100 Andreas Rheinhardt
> wrote:
>> This is incorrect: Here are the pixel formats advertised by the mjpeg
>> encoder:
>>
>> .p.pix_fmts = (const enum AVPixelFormat[]) {
>> AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_P
On Fri, Dec 9, 2022 at 12:49 PM Niklas Haas wrote:
>
> So, as was discussed at the last meeting, we should move towards
> removing YUVJ. I want to gather feedback on what appears to be to the
> major hurdle, and possible ways to solve it.
>
> The basic major issue is how to handle the case of comb
On 07/12/2022 23:22, Michael Niedermayer wrote:
On Wed, Dec 07, 2022 at 02:20:23PM +0100, Timo Rothenpieler wrote:
From: Anton Khirnov
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids
On 12/9/2022 10:09 AM, Timo Rothenpieler wrote:
On 07/12/2022 23:22, Michael Niedermayer wrote:
On Wed, Dec 07, 2022 at 02:20:23PM +0100, Timo Rothenpieler wrote:
From: Anton Khirnov
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls
From: Anton Khirnov
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids duplicating the logic that wraps the decoder
invocation and will be useful in the following commits.
---
libavcodec/d
On Fri, Dec 9, 2022 at 1:45 PM Niklas Haas wrote:
> Oh, you are right. So that presents an alternative to 4 - rather than an
> encoder flag, we can tie the auto-conversion in fftools to be tied to
> the strict_std_compliance check.
>
> I will try implementing this approach, it may be the best com
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 16
libavcodec/options_table.h | 1 +
libavcodec/version.h | 4 ++--
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ab7ce15fae..328028f293 100644
--
---
libavcodec/nvdec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index fbaedf0b6b..a477449d14 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
CudaFunctio
Quoting Zhao Zhili (2022-11-18 19:48:02)
> From: Zhao Zhili
>
> Unlike the pipe protocol, fd protocol has seek support if it
> corresponding to a regular file.
> ---
> Sometimes it's the only way to access files via file descriptor, e.g.,
> requesting a shared file on Android:
> https://developer
We shouldn't be providing links to unverified and non-FFmpeg-controlled
content in our documentation.
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index b9c9485646..d1c6fced7
It is a URL rewriter for IPFS gateways, not an actual implementation of
IPFS, and naming it as such was both incorrect and misleading.
Signed-off-by: Derek Buitenhuis
---
As was discussed at the developer meeting last week, presented here for
comments.
Personally I think libavformat is no place
Derek Buitenhuis (12022-12-09):
> It is a URL rewriter for IPFS gateways, not an actual implementation of
> IPFS, and naming it as such was both incorrect and misleading.
>
> Signed-off-by: Derek Buitenhuis
> ---
> As was discussed at the developer meeting last week, presented here for
> comment
On 12/9/2022 3:45 PM, Nicolas George wrote:
>> -static int ipfs_read(URLContext *h, unsigned char *buf, int size)
>> +static int ipfs_gateway_read(URLContext *h, unsigned char *buf, int size)
>
> There is no need to rename local symbols.
My intent was to rename in case we ever got an actual IPFS
Derek Buitenhuis (12022-12-09):
> My intent was to rename in case we ever got an actual IPFS implementation,
> but I have no strong opinion on whether to keep this part of the patch or
> not.
Even if we do, the names are local, they do not conflict.
> My personal preference is verbosity here, but
On Fri, Dec 09, 2022 at 02:09:45PM +0100, Timo Rothenpieler wrote:
> On 07/12/2022 23:22, Michael Niedermayer wrote:
> > On Wed, Dec 07, 2022 at 02:20:23PM +0100, Timo Rothenpieler wrote:
> > > From: Anton Khirnov
> > >
> > > Reorganize the code such that the frame threading code does not call th
On Fri, Dec 09, 2022 at 12:49:41PM +0100, Niklas Haas wrote:
> So, as was discussed at the last meeting, we should move towards
> removing YUVJ. I want to gather feedback on what appears to be to the
> major hurdle, and possible ways to solve it.
>
> The basic major issue is how to handle the case
On Thu, Dec 08, 2022 at 09:40:12PM +, Kieran Kunhya wrote:
> I intend to buy this RAM:
> https://www.amazon.co.uk/Crucial-CT2K16G4SFRA32A-PC4-25600-SODIMM-260-Pin/dp/B08C4X9VR5
>
> 2x £529 for NUCs
> 2x £102.48 for RAM
> 2x £69 for M.2 NVMe SSD
>
> £1400 total.
iam in favor of this too
I wou
On Fri, 9 Dec 2022 15:16:16 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 16
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 4 ++--
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff
On Fri, 9 Dec 2022 15:16:17 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..a477449d14 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavco
On Fri, Dec 09, 2022 at 02:37:04PM +0100, Timo Rothenpieler wrote:
> From: Anton Khirnov
>
> Reorganize the code such that the frame threading code does not call the
> decoders directly, but instead calls back into the generic decoding
> code. This avoids duplicating the logic that wraps the deco
On 09.12.2022 20:20, Philip Langdale wrote:
On Fri, 9 Dec 2022 15:16:17 +0100
Timo Rothenpieler wrote:
---
libavcodec/nvdec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index fbaedf0b6b..a477449d14 100644
--- a
Some encoders, like flac, can send side data only packets at the end.
Eventually, said extradata update should ideally be used to update the header
when writting to seekable output, but for now, ignore them.
Should fix the undefined behavior of passing NULL to memcpy().
Signed-off-by: James Almer
26 matches
Mail list logo
