From: Bas Nieuwenhuizen
This way we can pass explicit modifiers in. Sometimes the
modifier matters for the number of memory planes that
libva accepts, in particular when dealing with
driver-compressed textures. Furthermore the driver might
not actually be able to determine the implicit modifier
i
Vaapi can import external surface, but all the planes of the external
frames should be in the same drm object. A new flag is introduced and
vulkan can choose to allocate planes in one memory according this flag.
This flag will be enabled when the vulkan device is derived from vaapi
device, so that
Vulkan will map nv12 to R8 and GR88, so add this map to vaapi to support
vulkan frame.
Signed-off-by: Wenbin Chen
---
libavutil/hwcontext_vaapi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 75acc851d6..994b744e4d 100644
---
sem_sig_val is wrongly assigned to pWaitSemaphoreValues when export drm. Now fix
it.
Signed-off-by: Wenbin Chen
---
libavutil/hwcontext_vulkan.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index b857d1a9ed..
The vaapi can import external frame, but the planes of the external
frames should be in the same drm object. I add a new function to
allocate vkFrame in one memory and vulkan device will choose a way
to allocate memory according to one_memory flag.
A new variable is added to AVVKFrame to store the
Add hwupload and hwdownload support to vulkan when frames are allocated
in one memory
Signed-off-by: Wenbin Chen
---
libavutil/hwcontext_vulkan.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index f7878
When vulkan image exports to drm, the tilling need to be
VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT. Now add code to create vulkan
image using this format.
Now the following command line works:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format \
vaapi -i input_1080p.2
From: songyutong
In function vtenc_populate_extradata(), there is a manually created
pixel buffer that has not been released. So we should use CVPixelBufferRelease
to release this pixel buffer at the end, otherwise will cause a memory leak.
---
libavcodec/videotoolboxenc.c | 1 +
1 file changed,
From: songyutong
In function vtenc_populate_extradata(), there is a manually created
pixel buffer that has not been released. So we should use CVPixelBufferRelease
to release this pixel buffer at the end, otherwise will cause a memory leak.
---
libavcodec/videotoolboxenc.c | 1 +
1 file changed,
<13102179...@163.com> 于2021年11月9日周二 下午6:52写道：
>
> From: songyutong
>
> In function vtenc_populate_extradata(), there is a manually created
> pixel buffer that has not been released. So we should use CVPixelBufferRelease
> to release this pixel buffer at the end, otherwise will cause a memory leak.
On Tue, Nov 9, 2021 at 5:57 AM Steven Liu wrote:
> <13102179...@163.com> 于2021年11月9日周二 下午6:52写道：
> >
> > From: songyutong
> >
> > In function vtenc_populate_extradata(), there is a manually created
> > pixel buffer that has not been released. So we should use
> CVPixelBufferRelease
> > to releas
sön 2021-11-07 klockan 12:32 +0100 skrev Marton Balint:
>
> > +
> > + while (channel_ordering_ptr->uid[0]) {
> > + if (IS_KLV_KEY(channel_ordering_ptr->uid,
> > mca_sub_descriptor->mca_label_dictionary_id)) {
>
> You should check if current_channel < desc
On 11/6/2021 11:36 PM, Andreas Rheinhardt wrote:
>> +/*
>> + * Due to limitions in avcodec's current frame threading code, it cannot
>> + * handle adding frame side data in any place except before the slice
>> has
>> + * started decoding. Since Dolby Vision RPUs (which appear as NA
Derek Buitenhuis:
> On 11/6/2021 11:36 PM, Andreas Rheinhardt wrote:
>>> +/*
>>> + * Due to limitions in avcodec's current frame threading code, it
>>> cannot
>>> + * handle adding frame side data in any place except before the slice
>>> has
>>> + * started decoding. Since Dolby V
On Sun, Nov 07, 2021 at 06:27:03PM -0800, mindm...@gmail.com wrote:
> From: Mark Reid
>
> ---
> libswscale/input.c | 36 +++-
> 1 file changed, 11 insertions(+), 25 deletions(-)
This should be benchmarked with START/STOP_TIMER
same for the other patch
thx
[...]
The mxf and mxf_opatom muxer expect H.264 in Annex B format.
Signed-off-by: Andreas Rheinhardt
---
The check here is taken from mpegtsenc.
libavformat/mxfenc.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index c36ebef932..d
will apply soon
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
On 11/9/2021 2:58 PM, Paul B Mahol wrote:
will apply soon
A checkasm test to go with this would be ideal.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or emai
Also covers writing mastering display metadata.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/mxf.mak | 17 ++--
tests/ref/fate/mxf-remux-applehdr10 | 68 +
2 files changed, 82 insertions(+), 3 deletions(-)
create mode 100644 tests/ref/fate/mx
These tests exhibit two bugs: Instead of using the in-band extradata
the demuxer makes up some extradata designed for AVC intra tracks
that lack in-band extradata; these files are nevertheless decodable
because of the in-band extradata. Furthermore, the frame reordering
is lost.
Signed-off-by: And
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index d1c4d43a50..3b6604d0d6 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2203,9 +2203,9 @@ static int
None of the muxers here has the AVFMT_NOSTREAMS flag set,
so it is checked generically that there are streams.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3b6604d0d6..fd9e2c4c48
(Unless the packet has a size of zero, the packet will run afoul
of the cbr_index check a few lines below.)
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index a6535eb43f.
It is just a flag per supported CID. So there is no reason to use
an avpriv function for this purpose.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 47 ++--
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/libavformat/mxfenc.
The MXF muxers only write the header after they have received
a packet; the actual write_header function does not write anything.
So make an init function out of it.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --g
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index c20ba9bfca..cf63340313 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2509,7 +2509,7
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index cf63340313..aa9857fcff 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -421,6 +421,7 @@ typed
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfdec.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index af9d33f796..4191e82474 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1984,22 +1984,15
It is unused.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dnxhddata.c | 8
libavcodec/dnxhddata.h | 1 -
2 files changed, 9 deletions(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 3a69a0f501..e3b260f328 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/d
The actual frame_size is no longer used since commit
3d38e45eb85c7a2420cb48a9cd45625c28644b2e; and the check for
"< 0" is equivalent to the CID being valid. But this is already
ensured by mxf_dnxhd_codec_uls containing this CID.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mxfenc.c | 8 +---
It is no longer used in libavformat.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dnxhd_parser.c | 4 ++--
libavcodec/dnxhddata.c| 4 ++--
libavcodec/dnxhddata.h| 4 ++--
libavcodec/dnxhdenc.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/dnxhd
Besides being unused it should not be used at all:
The order of options of bitstream filters is not guaranteed
to be stable at all.
Signed-off-by: Andreas Rheinhardt
---
I wonder whether the undocumented and widely unknown shorthand stuff
in bsf.c should be removed as well.
libavformat/utils.c
Signed-off-by: Andreas Rheinhardt
---
fftools/ffmpeg_opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 7aff43d917..ab4c63a362 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -79,7 +79,7 @@ static const char
The earlier code has ignored it for all stream types except
video and subtitles, probably because audio was presumed
to only consist of keyframes. Yet this assumption is not true
for e.g. TrueHD.
Signed-off-by: Andreas Rheinhardt
---
fftools/ffmpeg_opt.c | 7 +++
1 file changed, 3 insertions
On 11/9/2021 2:34 PM, Andreas Rheinhardt wrote:
The mxf and mxf_opatom muxer expect H.264 in Annex B format.
Amazing that nobody noticed this until now. Guess remuxing from mp4/mkv
to mxf is not a common scenario.
LGTM, just tested a quick remux and without the bsf it just fails.
Signed-o
On Tue, Nov 9, 2021 at 9:21 AM Michael Niedermayer
wrote:
> On Sun, Nov 07, 2021 at 06:27:03PM -0800, mindm...@gmail.com wrote:
> > From: Mark Reid
> >
> > ---
> > libswscale/input.c | 36 +++-
> > 1 file changed, 11 insertions(+), 25 deletions(-)
>
> This should
Ronald S. Bultje:
> Hi Thomas,
>
> On Fri, Oct 29, 2021 at 9:12 AM Tomas Härdin wrote:
>
>> tor 2021-10-28 klockan 21:09 +0200 skrev Paul B Mahol:
>>> +const uint16_t *src = (const uint16_t *)ssrc;
>>
>> This is not -fstrict-aliasing safe
>>
>
> I don't believe that is correct. It's true we
tis 2021-11-09 klockan 18:34 +0100 skrev Andreas Rheinhardt:
> The mxf and mxf_opatom muxer expect H.264 in Annex B format.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> The check here is taken from mpegtsenc.
You didn't think to make both muxers share code instead of copy-
pasting?
/Tomas
___
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> Also covers writing mastering display metadata.
So you're merging the D-10 user comments test and ProRes remuxing? What
about remuxing D-10?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-deve
Tomas Härdin:
> tis 2021-11-09 klockan 18:34 +0100 skrev Andreas Rheinhardt:
>> The mxf and mxf_opatom muxer expect H.264 in Annex B format.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> The check here is taken from mpegtsenc.
>
> You didn't think to make both muxers share code instead of cop
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mxfenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index d1c4d43a50..3b6604d0d6 100644
> --- a/lib
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> None of the muxers here has the AVFMT_NOSTREAMS flag set,
> so it is checked generically that there are streams.
Didn't know about AVFMT_NOSTREAMS
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mxfenc.c | 3 ---
> 1 file
Tomas Härdin:
> tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
>> Also covers writing mastering display metadata.
>
> So you're merging the D-10 user comments test and ProRes remuxing? What
> about remuxing D-10?
>
No, I am adding a new test; the old test is still there. And both o
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> The MXF muxers only write the header after they have received
> a packet; the actual write_header function does not write anything.
> So make an init function out of it.
New API being put to good use. Patch looks OK
We could write *so
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> (Unless the packet has a size of zero, the packet will run afoul
> of the cbr_index check a few lines below.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mxfenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mxfenc.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
Aha, this one does exactly what I just suggested with return values.
D'oh!
Looks OK of course
/
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mxfenc.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index cf63340313..aa9857fcff 100644
> --
Tomas Härdin:
> tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/mxfenc.c | 10 +++---
>> 1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index cf63340313..
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mxfdec.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index af9d33f796..4191e82474 100644
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> It is just a flag per supported CID. So there is no reason to use
> an avpriv function for this purpose.
This is data duplication. Honestly these ULs should probably live in
dnxhddata.c.
>
> Signed-off-by: Andreas Rheinhardt
> ---
>
Tomas Härdin:
> tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
>> It is just a flag per supported CID. So there is no reason to use
>> an avpriv function for this purpose.
>
> This is data duplication. Honestly these ULs should probably live in
> dnxhddata.c.
>
But aren't these ULs
tis 2021-11-09 klockan 22:48 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> > > It is just a flag per supported CID. So there is no reason to use
> > > an avpriv function for this purpose.
> >
> > This is data duplication. Honestl
tis 2021-11-09 klockan 22:07 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2021-11-09 klockan 18:34 +0100 skrev Andreas Rheinhardt:
> > > The mxf and mxf_opatom muxer expect H.264 in Annex B format.
> > >
> > > Signed-off-by: Andreas Rheinhardt
> > >
> > > ---
> > > The check here is ta
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> The actual frame_size is no longer used since commit
> 3d38e45eb85c7a2420cb48a9cd45625c28644b2e; and the check for
> "< 0" is equivalent to the CID being valid. But this is already
> ensured by mxf_dnxhd_codec_uls containing this CID.
>
tis 2021-11-09 klockan 19:01 +0100 skrev Andreas Rheinhardt:
> These tests exhibit two bugs: Instead of using the in-band extradata
> the demuxer makes up some extradata designed for AVC intra tracks
> that lack in-band extradata; these files are nevertheless decodable
> because of the in-band extr
> Adding nb_surfaces in AVD3D11VAFramesContext in the end of the structure
> to support flexible size of this arrays and align to
> AVDXVA2FramesContext and AVVAAPIFramesContext.
>
> Signed-off-by Wenbin Chen
> ---
> libavutil/hwcontext_d3d11va.c | 3 +--
> libavutil/hwcontext_d3d11va.h | 2 ++
>
> This commandline cause core dumped:
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
> -hwaccel_output_format vaapi -i input.264 \
> -vf "hwmap=derive_device=qsv,format=qsv" \
> -c:v h264_qsv output.264
>
> reason: We use nb_surfaces to assign surface to handle_pairs_internal
> but
> From: nyanmisaka
>
> The data stored in data[3] in VAAPI AVFrame is VASurfaceID while
> the data stored in pair->first is the pointer of VASurfaceID, so
> we need to do cast to make following commandline works:
>
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
> -hwaccel_output_f
> From: nyanmisaka
>
> mfxHDLPair was added to qsv, so modify qsv->opencl map function as well.
> Now the following commandline works:
>
> ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 \
> -init_hw_device qsv=qs@va -init_hw_device opencl=ocl@va -
> filter_hw_device ocl \
> -hwac
On Mon, 2021-09-27 at 08:41 +, Xiang, Haihao wrote:
> On Mon, 2021-09-27 at 10:21 +0200, Andreas Rheinhardt wrote:
> > Xiang, Haihao:
> > > On Sun, 2021-09-26 at 08:32 +0200, Andreas Rheinhardt wrote:
> > > > Since commit 3bbe0c210b05fc6fbd7b1d4bbd8479db7f2cf957, the Payloads
> > > > array of e
9 Nov 2021, 10:18 by wenbin.c...@intel.com:
> sem_sig_val is wrongly assigned to pWaitSemaphoreValues when export drm. Now
> fix
> it.
>
> Signed-off-by: Wenbin Chen <> wenbin.c...@intel.com> >
>
Thanks for spotting this, I fixed that in my patchset and updated branch.
frame->sem_value is safe t
61 matches
Mail list logo
