Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Thu, 2021-07-15 at 06:43 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Xiang, Haihao > > Sent: Thursday, 15 July 2021 07:43 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > d3d11va support, added mfxhdlpair > > > > On Thu, 2021-07-15 at 03:49 +, Soft Works wrote: > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > James Almer > > > > Sent: Thursday, 15 July 2021 05:21 > > > > To: ffmpeg-devel@ffmpeg.org > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > > > d3d11va support, added mfxhdlpair > > > > > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: ffmpeg-devel On > > > > Behalf > > > > > > Of Xiang, Haihao > > > > > > Sent: Thursday, 15 July 2021 04:35 > > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: > > > > > > enabling d3d11va support, added mfxhdlpair > > > > > > > > > > > > On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > > > > > > On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > > > > > > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Adding DX11 relevant device type checks and adjusting > > > > > > > > > callbacks with proper MediaSDK pair type support. > > > > > > > > > > > > > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > > > > > > > > > > > > > Signed-off-by: Artem Galin . > > > > > > > > > > > > > > > > > > > > > > > > Patchset obviously closes the gap of DirectX 11 support and > > > > > > > > already checked with several apps that use FFMPEG. > > > > > > > > > > > > > > > > Any particular review comments should be yet expected? > > > > > > > > > > > > > > > > Changes seem to be straight forward and incorporate prev. > > > > comments. > > > > > > > > > > > > > > > > thank in advance > > > > > > > > > > > > > > > > regards > > > > > > > > Max > > > > > > > > > > > > > > There are some issues pointed out by Soft Works related to > > > > > > > switching the default to DX11 breaking existing command lines > > > > > > > with DX9, plus an OpenCL<->QSV interop regression this would > > > > > > > introduce that according to him should be easy to fix. > > > > > > > > > > > > > > If those are addressed, the set should be good. > > > > > > > > > > > > If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > > > > > June/281778.html > > > > > > (qsvdec: add support for HW_DEVICE_CTX method) first, we should > > > > > > be able to use the common device stuff to initialize d3d11va > > > > > > device for QSV and needn't use child_device_type to specify child > > > > device. > > > > > > > > > > There's no doubt that the new method will be better, but the point > > > > > is not > > > > > > > > to break existing command lines. From my experience, ffmpeg usually > > > > avoids to break established command line patterns, which is a good thing > > > > imo. > > > > > > > > > > Anything more official than my perception? Please feel free to > > > > > chime in... ;-) > > > > > > > > That patch appears to attempt to maintain support for existing > > > > command lines for a deprecation period, something we've done before > > > > with other hwaccels like cuvid, so if it's really better, it's fine and > > > > acceptable. > > > > > > ^ > > > > > > Hi James, > > > > > > "That patch" that preserves compatibility doesn't exist yet. We need > > > to make sure that command lines using the '--child_device' parameter > > > will continue to work, while Haihao's patch will be the "future way": > > > > > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va > > > > > > The new behaviour that is introduced by this patch is that an > > > initialized hw device can now be applied to qsv decoders (currently > > > only to filter graphs and qsv encoders). > > > > '-init_hw_device qsv=qsv:hw,child_device=xxx' still works, > > Sure - that needs to work anyway. What I meant is the -qsv_device parameter, > which is a global-scope param and takes a device path on Linux or the D3D > adapter ID on Windows. > > ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v h264_qsv -i input.mp4 > -c:v h264_qsv output.mp4 Yes, -qsv_device still works, I added opt_qsv_device() to handle qsv_device option. > > For my implementation I had added an additional global parameter ( > --qsv_use_dx11). When it is set, the -qsv_device parameter indicates a DXGI > adapter id rather than a D3D adapter. But let's forget about that. The > init_hw_device approach is much better, and -qsv_device should just keep > working like before. > > I'm currently rebasing all our patches to the latest ffmpeg; probably tomorrow > I'll check out your patch. Thanks for checking out th
Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Thursday, 15 July 2021 09:56 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > d3d11va support, added mfxhdlpair > > On Thu, 2021-07-15 at 06:43 +, Soft Works wrote: > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Xiang, Haihao > > > Sent: Thursday, 15 July 2021 07:43 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > > d3d11va support, added mfxhdlpair > > > > > > On Thu, 2021-07-15 at 03:49 +, Soft Works wrote: > > > > > -Original Message- > > > > > From: ffmpeg-devel On > Behalf > > > > > Of James Almer > > > > > Sent: Thursday, 15 July 2021 05:21 > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: > > > > > enabling d3d11va support, added mfxhdlpair > > > > > > > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: ffmpeg-devel On > > > > > > Behalf > > > > > > > Of Xiang, Haihao > > > > > > > Sent: Thursday, 15 July 2021 04:35 > > > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: > > > > > > > enabling d3d11va support, added mfxhdlpair > > > > > > > > > > > > > > On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > > > > > > > On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > > > > > > > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Adding DX11 relevant device type checks and adjusting > > > > > > > > > > callbacks with proper MediaSDK pair type support. > > > > > > > > > > > > > > > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Artem Galin . > > > > > > > > > > > > > > > > > > > > > > > > > > > Patchset obviously closes the gap of DirectX 11 support > > > > > > > > > and already checked with several apps that use FFMPEG. > > > > > > > > > > > > > > > > > > Any particular review comments should be yet expected? > > > > > > > > > > > > > > > > > > Changes seem to be straight forward and incorporate prev. > > > > > > comments. > > > > > > > > > > > > > > > > > > thank in advance > > > > > > > > > > > > > > > > > > regards > > > > > > > > > Max > > > > > > > > > > > > > > > > There are some issues pointed out by Soft Works related to > > > > > > > > switching the default to DX11 breaking existing command > > > > > > > > lines with DX9, plus an OpenCL<->QSV interop regression > > > > > > > > this would introduce that according to him should be easy to > > > > > > > > fix. > > > > > > > > > > > > > > > > If those are addressed, the set should be good. > > > > > > > > > > > > > > If we may apply > > > > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > > > > > > June/281778.html > > > > > > > (qsvdec: add support for HW_DEVICE_CTX method) first, we > > > > > > > should be able to use the common device stuff to initialize > > > > > > > d3d11va device for QSV and needn't use child_device_type to > > > > > > > specify child > > > > > > device. > > > > > > > > > > > > There's no doubt that the new method will be better, but the > > > > > > point is not > > > > > > > > > > to break existing command lines. From my experience, ffmpeg > > > > > usually avoids to break established command line patterns, which > > > > > is a good thing > > > > > > imo. > > > > > > > > > > > > Anything more official than my perception? Please feel free to > > > > > > chime in... ;-) > > > > > > > > > > That patch appears to attempt to maintain support for existing > > > > > command lines for a deprecation period, something we've done > > > > > before with other hwaccels like cuvid, so if it's really better, > > > > > it's fine and > > > > > > acceptable. > > > > > > > > ^ > > > > > > > > Hi James, > > > > > > > > "That patch" that preserves compatibility doesn't exist yet. We > > > > need to make sure that command lines using the '--child_device' > > > > parameter will continue to work, while Haihao's patch will be the > "future way": > > > > > > > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device > qsv@d3d11va > > > > > > > > The new behaviour that is introduced by this patch is that an > > > > initialized hw device can now be applied to qsv decoders > > > > (currently only to filter graphs and qsv encoders). > > > > > > '-init_hw_device qsv=qsv:hw,child_device=xxx' still works, > > > > Sure - that needs to work anyway. What I meant is the -qsv_device > > parameter, which is a global-scope param and takes a device path on > > Linux or the D3D adapter ID on Windows. > > > > ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v h264_qsv -i > > input.mp4 -c:v h264_qsv output.mp4 > > Yes, -qsv_device sti
Re: [FFmpeg-devel] [PATCH] ffmpeg-web/robots.txt: attempt to keep spiders out of dynamically generated git content
On Wed, Jul 14, 2021 at 10:40:53PM +0200, Michael Niedermayer wrote: > On Wed, Jul 14, 2021 at 04:00:53PM -0400, ffmpegandmahanstreamer@lolcow.email > wrote: > > On 2021-07-14 14:51, Michael Niedermayer wrote: > > > Signed-off-by: Michael Niedermayer > > > --- > > > htdocs/robots.txt | 13 - > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > diff --git a/htdocs/robots.txt b/htdocs/robots.txt > > > index eb05362..4bbc395 100644 > > > --- a/htdocs/robots.txt > > > +++ b/htdocs/robots.txt > > > @@ -1,2 +1,13 @@ > > > User-agent: * > > > -Disallow: > > > +Crawl-delay: 10 > > > +Disallow: /gitweb/ > > > +Disallow: /*a=search* > > > +Disallow: /*/search/* > > > +Disallow: /*a=blobdiff* > > > +Disallow: /*/blobdiff/* > > > +Disallow: /*a=commitdiff* > > > +Disallow: /*/commitdiff/* > > > +Disallow: /*a=snapshot* > > > +Disallow: /*/snapshot/* > > > +Disallow: /*a=blame* > > > +Disallow: /*/blame/* > > LGTM based on my own personal experiences. But the robots.txt has to be > > will apply > > > > applied for git.ffmpeg.org as well, and not just ffmpeg.org. Or else they > > will just do the same for git.ffmpeg since there are treated separately. > > was expecting this a bit ... > i will look into that tomorrow or so unless someone else does before me done [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Thu, Jul 15, 2021 at 5:49 AM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > James Almer > > Sent: Thursday, 15 July 2021 05:21 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > d3d11va support, added mfxhdlpair > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > >> -Original Message- > > >> From: ffmpeg-devel On Behalf Of > > >> Xiang, Haihao > > >> Sent: Thursday, 15 July 2021 04:35 > > >> To: ffmpeg-devel@ffmpeg.org > > >> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > >> d3d11va support, added mfxhdlpair > > >> > > >> On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > >>> On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > >> wrote: > > > > > Adding DX11 relevant device type checks and adjusting callbacks > > > with proper MediaSDK pair type support. > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > Signed-off-by: Artem Galin . > > > > > > Patchset obviously closes the gap of DirectX 11 support and already > > checked with several apps that use FFMPEG. > > > > Any particular review comments should be yet expected? > > > > Changes seem to be straight forward and incorporate prev. comments. > > > > thank in advance > > > > regards > > Max > > >>> > > >>> There are some issues pointed out by Soft Works related to switching > > >>> the default to DX11 breaking existing command lines with DX9, plus > > >>> an OpenCL<->QSV interop regression this would introduce that > > >>> according to him should be easy to fix. > > >>> > > >>> If those are addressed, the set should be good. > > >> > > >> If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > >> June/281778.html > > >> (qsvdec: add support for HW_DEVICE_CTX method) first, we should be > > >> able to use the common device stuff to initialize d3d11va device for > > >> QSV and needn't use child_device_type to specify child device. > > > > > > There's no doubt that the new method will be better, but the point is > not > > to break existing command lines. From my experience, ffmpeg usually > avoids > > to break established command line patterns, which is a good thing imo. > > > > > > Anything more official than my perception? Please feel free to chime > > > in... ;-) > > > > That patch appears to attempt to maintain support for existing command > > lines for a deprecation period, something we've done before with other > > hwaccels like cuvid, so if it's really better, it's fine and acceptable. > ^ > > Hi James, > > "That patch" that preserves compatibility doesn't exist yet. We need to > make sure that command lines using the '--child_device' parameter will > continue to work, while Haihao's patch will be the "future way": > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va > > The new behaviour that is introduced by this patch is that an initialized > hw device can now be applied to qsv decoders (currently only to filter > graphs and qsv encoders). > > Additionally, the default should remain to be D3D9 (if none of the above > is specified) as laid out earlier - again for maintaining compatibility but > also for better robustness and performance. > > Upon introduction of DX11/D3D11VA support, it makes sense to make it default as well, this would help for upcoming implementations and general usages in the long run, including new usages, as headless platforms support, which is an obvious D3D9 gap, as an example. Compatibility is still preserved and available with D3D9 path, there is no functional change. If D3D9 is critical for further usage - it has to be requested explicitly. regards Max ___ 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".
Re: [FFmpeg-devel] [PATCH] ffprobe: use quotation marks in the xml header output
On 14.07.2021 16:57, James Almer wrote:
xmllint (silently) replaces the ' with " when fixing and validating the output
of ffprobe in fate-ffprobe_xsd.
Signed-off-by: James Almer
---
fftools/ffprobe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 2d452c212e..94c73fd32c 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1682,9 +1682,9 @@ static void xml_print_section_header(WriterContext *wctx)
wctx->section[wctx->level-1] : NULL;
if (wctx->level == 0) {
-const char *qual = " xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
"
-"xmlns:ffprobe='http://www.ffmpeg.org/schema/ffprobe' "
-"xsi:schemaLocation='http://www.ffmpeg.org/schema/ffprobe
ffprobe.xsd'";
+const char *qual = "
xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"; "
+"xmlns:ffprobe=\"http://www.ffmpeg.org/schema/ffprobe\"; "
+"xsi:schemaLocation=\"http://www.ffmpeg.org/schema/ffprobe
ffprobe.xsd\"";
printf("\n");
printf("<%sffprobe%s>\n",
Both, single and double quotes are technically valid for XML attributes.
But I agree that it is better to use double quotes here as they are used
for attributes throughout the ffprobe XML writer.
Regards,
Tobias
___
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".
Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
> -Original Message- > From: ffmpeg-devel On Behalf Of > Max Dmitrichenko > Sent: Thursday, 15 July 2021 17:15 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > d3d11va support, added mfxhdlpair > > On Thu, Jul 15, 2021 at 5:49 AM Soft Works wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > James Almer > > > Sent: Thursday, 15 July 2021 05:21 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > > d3d11va support, added mfxhdlpair > > > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > > > > >> -Original Message- > > > >> From: ffmpeg-devel On Behalf > Of > > > >> Xiang, Haihao > > > >> Sent: Thursday, 15 July 2021 04:35 > > > >> To: ffmpeg-devel@ffmpeg.org > > > >> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: > > > >> enabling d3d11va support, added mfxhdlpair > > > >> > > > >> On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > > >>> On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > > > > > >> wrote: > > > > > > > Adding DX11 relevant device type checks and adjusting > > > > callbacks with proper MediaSDK pair type support. > > > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > > > Signed-off-by: Artem Galin . > > > > > > > > > Patchset obviously closes the gap of DirectX 11 support and > > > already checked with several apps that use FFMPEG. > > > > > > Any particular review comments should be yet expected? > > > > > > Changes seem to be straight forward and incorporate prev. > comments. > > > > > > thank in advance > > > > > > regards > > > Max > > > >>> > > > >>> There are some issues pointed out by Soft Works related to > > > >>> switching the default to DX11 breaking existing command lines > > > >>> with DX9, plus an OpenCL<->QSV interop regression this would > > > >>> introduce that according to him should be easy to fix. > > > >>> > > > >>> If those are addressed, the set should be good. > > > >> > > > >> If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > > >> June/281778.html > > > >> (qsvdec: add support for HW_DEVICE_CTX method) first, we should > > > >> be able to use the common device stuff to initialize d3d11va > > > >> device for QSV and needn't use child_device_type to specify child > device. > > > > > > > > There's no doubt that the new method will be better, but the point > > > > is > > not > > > to break existing command lines. From my experience, ffmpeg usually > > avoids > > > to break established command line patterns, which is a good thing imo. > > > > > > > > Anything more official than my perception? Please feel free to > > > > chime in... ;-) > > > > > > That patch appears to attempt to maintain support for existing > > > command lines for a deprecation period, something we've done before > > > with other hwaccels like cuvid, so if it's really better, it's fine and > acceptable. > > ^ > > > > Hi James, > > > > "That patch" that preserves compatibility doesn't exist yet. We need > > to make sure that command lines using the '--child_device' parameter > > will continue to work, while Haihao's patch will be the "future way": > > > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv@d3d11va > > > > The new behaviour that is introduced by this patch is that an > > initialized hw device can now be applied to qsv decoders (currently > > only to filter graphs and qsv encoders). > > > > Additionally, the default should remain to be D3D9 (if none of the > > above is specified) as laid out earlier - again for maintaining > > compatibility but also for better robustness and performance. > > > > > Upon introduction of DX11/D3D11VA support, it makes sense to make it > default as well, this would help for upcoming implementations and general > usages in the long run, including new usages, as headless platforms support, > which is an obvious D3D9 gap, as an example. > > Compatibility is still preserved and available with D3D9 path, there is no > functional change. > If D3D9 is critical for further usage - it has to be requested explicitly. Which is a breaking change. It would not only affect a huge amount of applications and users - it would also invalidate thousands of command parameter examples that are spread all over the web. I'd love to hear some other voices on this (even when opinions differ). I don't want to be the only one opposing it each time.. softworkz ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter: add afwtdn filter
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".
Re: [FFmpeg-devel] [FFmpeg-cvslog] configure: use pkg-config for xlib/Xv
On Wed, Jul 14, 2021 at 10:32:24PM +, Timo Rothenpieler wrote: > ffmpeg | branch: master | Timo Rothenpieler | Wed Jul > 14 23:16:02 2021 +0200| [7ec7e6aa2d394d8d25472c55c5da2e44b0a60041] | > committer: Timo Rothenpieler > > configure: use pkg-config for xlib/Xv > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7ec7e6aa2d394d8d25472c55c5da2e44b0a60041 > --- > > configure | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) breaks build on normal standard ubuntu here /usr/bin/ld: libavdevice/libavdevice.a(xv.o): undefined reference to symbol 'XShmDetach' //usr/lib/x86_64-linux-gnu/libXext.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:123: recipe for target 'ffmpeg_g' failed make: *** [ffmpeg_g] Error 1 "-lXext" is missing locate xv.pc /usr/lib/x86_64-linux-gnu/pkgconfig/xv.pc pkg-config --libs xv -lXv this is from: ii libxv-dev:amd64 2:1.0.11-1amd64 X11 Video extension library (development headers) https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=libxv-dev says thats the latest Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [FFmpeg-cvslog] configure: use pkg-config for xlib/Xv
On 7/15/2021 4:26 PM, Michael Niedermayer wrote: On Wed, Jul 14, 2021 at 10:32:24PM +, Timo Rothenpieler wrote: ffmpeg | branch: master | Timo Rothenpieler | Wed Jul 14 23:16:02 2021 +0200| [7ec7e6aa2d394d8d25472c55c5da2e44b0a60041] | committer: Timo Rothenpieler configure: use pkg-config for xlib/Xv http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7ec7e6aa2d394d8d25472c55c5da2e44b0a60041 --- configure | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) breaks build on normal standard ubuntu here /usr/bin/ld: libavdevice/libavdevice.a(xv.o): undefined reference to symbol 'XShmDetach' //usr/lib/x86_64-linux-gnu/libXext.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:123: recipe for target 'ffmpeg_g' failed make: *** [ffmpeg_g] Error 1 "-lXext" is missing locate xv.pc /usr/lib/x86_64-linux-gnu/pkgconfig/xv.pc pkg-config --libs xv -lXv this is from: ii libxv-dev:amd64 2:1.0.11-1amd64 X11 Video extension library (development headers) https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=libxv-dev says thats the latest Thanks Yes, I pushed a fix a few minutes ago. Can you confirm if it works for you? ___ 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".
Re: [FFmpeg-devel] [FFmpeg-cvslog] configure: use pkg-config for xlib/Xv
On Thu, Jul 15, 2021 at 04:28:02PM -0300, James Almer wrote: > On 7/15/2021 4:26 PM, Michael Niedermayer wrote: > > On Wed, Jul 14, 2021 at 10:32:24PM +, Timo Rothenpieler wrote: > > > ffmpeg | branch: master | Timo Rothenpieler | Wed > > > Jul 14 23:16:02 2021 +0200| [7ec7e6aa2d394d8d25472c55c5da2e44b0a60041] | > > > committer: Timo Rothenpieler > > > > > > configure: use pkg-config for xlib/Xv > > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7ec7e6aa2d394d8d25472c55c5da2e44b0a60041 > > > --- > > > > > > configure | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > breaks build on normal standard ubuntu here > > > > /usr/bin/ld: libavdevice/libavdevice.a(xv.o): undefined reference to symbol > > 'XShmDetach' > > //usr/lib/x86_64-linux-gnu/libXext.so.6: error adding symbols: DSO missing > > from command line > > collect2: error: ld returned 1 exit status > > Makefile:123: recipe for target 'ffmpeg_g' failed > > make: *** [ffmpeg_g] Error 1 > > > > "-lXext" is missing > > > > locate xv.pc > > /usr/lib/x86_64-linux-gnu/pkgconfig/xv.pc > > > > pkg-config --libs xv > > -lXv > > > > this is from: > > ii libxv-dev:amd64 > > 2:1.0.11-1amd64 > > X11 Video extension library (development headers) > > > > https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=libxv-dev > > says thats the latest > > > > Thanks > > Yes, I pushed a fix a few minutes ago. Can you confirm if it works for you? seems working for me thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec: add a parser flag to enable keyframe tagging heuristics
On Wed, Jul 14, 2021 at 11:33:59AM -0300, James Almer wrote:
> It will be used to allow parsers to be more liberal when tagging packets as
> keyframes.
>
> Signed-off-by: James Almer
> ---
> libavcodec/avcodec.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 8b97895aeb..8e3d888266 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2809,6 +2809,7 @@ typedef struct AVCodecParserContext {
> #define PARSER_FLAG_ONCE 0x0002
> /// Set if the parser has a valid file offset
> #define PARSER_FLAG_FETCHED_OFFSET0x0004
> +#define PARSER_FLAG_USE_KEYFRAME_HEURISTICS 0x0008
> #define PARSER_FLAG_USE_CODEC_TS 0x1000
This doesnt "feel" like the best solution to me
dont you think it would be better to export all information ?
the concept of a keyframe is a point at which decoding can begin
that really are at least 3 points
the point at which packets begin to be input into the decoder
the point at which the decoder is able to return some decoded
data which closely resembles the encoder input
and the point at which the decoder output matches 1:1 the output
of a decoder starting from frame 0
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: PGP signature
___
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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec: add a parser flag to enable keyframe tagging heuristics
On 7/15/2021 5:23 PM, Michael Niedermayer wrote:
On Wed, Jul 14, 2021 at 11:33:59AM -0300, James Almer wrote:
It will be used to allow parsers to be more liberal when tagging packets as
keyframes.
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 8b97895aeb..8e3d888266 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2809,6 +2809,7 @@ typedef struct AVCodecParserContext {
#define PARSER_FLAG_ONCE 0x0002
/// Set if the parser has a valid file offset
#define PARSER_FLAG_FETCHED_OFFSET0x0004
+#define PARSER_FLAG_USE_KEYFRAME_HEURISTICS 0x0008
#define PARSER_FLAG_USE_CODEC_TS 0x1000
This doesnt "feel" like the best solution to me
dont you think it would be better to export all information ?
The AVParser API is going to be removed at some point for something
better that works on packets rather than raw buffers, so ideally we
should not expand it too much, and leave more complex implementations
for later.
Adding a flag is the simplest way to fix this for now, until a proper
rework is done.
the concept of a keyframe is a point at which decoding can begin
that really are at least 3 points
the point at which packets begin to be input into the decoder
the point at which the decoder is able to return some decoded
data which closely resembles the encoder input
and the point at which the decoder output matches 1:1 the output
of a decoder starting from frame 0
All parsers save for h264 are currently only tagging packets containing
a coded bitstream that, when decoded, it fully resets the decoding state
and depends on no previously parsed data or state, which is what (most)
muxers expect. This approach here is making the h264 do the same by
default (in line with the decoder), to ensure some muxers don't wrongly
mark certain packets as sync samples, while letting others remain
liberal about it.
Ideally yes, we'd propagate more detailed information in some way, which
then the mp4 muxer can use to build sample groups for h264, hevc and
av1. But the existing AVParser API is not adequate for that.
Thanks
[...]
___
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".
___
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".
Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
On Thu, 2021-07-15 at 09:32 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Xiang, Haihao > > Sent: Thursday, 15 July 2021 09:56 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > d3d11va support, added mfxhdlpair > > > > On Thu, 2021-07-15 at 06:43 +, Soft Works wrote: > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Xiang, Haihao > > > > Sent: Thursday, 15 July 2021 07:43 > > > > To: ffmpeg-devel@ffmpeg.org > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling > > > > d3d11va support, added mfxhdlpair > > > > > > > > On Thu, 2021-07-15 at 03:49 +, Soft Works wrote: > > > > > > -Original Message- > > > > > > From: ffmpeg-devel On > > > > Behalf > > > > > > Of James Almer > > > > > > Sent: Thursday, 15 July 2021 05:21 > > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: > > > > > > enabling d3d11va support, added mfxhdlpair > > > > > > > > > > > > On 7/15/2021 12:10 AM, Soft Works wrote: > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: ffmpeg-devel On > > > > > > > > Behalf > > > > > > > > Of Xiang, Haihao > > > > > > > > Sent: Thursday, 15 July 2021 04:35 > > > > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: > > > > > > > > enabling d3d11va support, added mfxhdlpair > > > > > > > > > > > > > > > > On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote: > > > > > > > > > On 11/14/2020 1:49 PM, Max Dmitrichenko wrote: > > > > > > > > > > On Tue, Nov 3, 2020 at 7:47 PM Artem Galin > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Adding DX11 relevant device type checks and adjusting > > > > > > > > > > > callbacks with proper MediaSDK pair type support. > > > > > > > > > > > > > > > > > > > > > > Extending structure for proper MediaSDK pair type support. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Artem Galin . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Patchset obviously closes the gap of DirectX 11 support > > > > > > > > > > and already checked with several apps that use FFMPEG. > > > > > > > > > > > > > > > > > > > > Any particular review comments should be yet expected? > > > > > > > > > > > > > > > > > > > > Changes seem to be straight forward and incorporate prev. > > > > > > > > comments. > > > > > > > > > > > > > > > > > > > > thank in advance > > > > > > > > > > > > > > > > > > > > regards > > > > > > > > > > Max > > > > > > > > > > > > > > > > > > There are some issues pointed out by Soft Works related to > > > > > > > > > switching the default to DX11 breaking existing command > > > > > > > > > lines with DX9, plus an OpenCL<->QSV interop regression > > > > > > > > > this would introduce that according to him should be easy to > > > > > > > > > fix. > > > > > > > > > > > > > > > > > > If those are addressed, the set should be good. > > > > > > > > > > > > > > > > If we may apply > > > > > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2021- > > > > > > > > June/281778.html > > > > > > > > (qsvdec: add support for HW_DEVICE_CTX method) first, we > > > > > > > > should be able to use the common device stuff to initialize > > > > > > > > d3d11va device for QSV and needn't use child_device_type to > > > > > > > > specify child > > > > > > > > device. > > > > > > > > > > > > > > There's no doubt that the new method will be better, but the > > > > > > > point is not > > > > > > > > > > > > to break existing command lines. From my experience, ffmpeg > > > > > > usually avoids to break established command line patterns, which > > > > > > is a good thing > > > > > > > > imo. > > > > > > > > > > > > > > Anything more official than my perception? Please feel free to > > > > > > > chime in... ;-) > > > > > > > > > > > > That patch appears to attempt to maintain support for existing > > > > > > command lines for a deprecation period, something we've done > > > > > > before with other hwaccels like cuvid, so if it's really better, > > > > > > it's fine and > > > > > > > > acceptable. > > > > > > > > > > ^ > > > > > > > > > > Hi James, > > > > > > > > > > "That patch" that preserves compatibility doesn't exist yet. We > > > > > need to make sure that command lines using the '--child_device' > > > > > parameter will continue to work, while Haihao's patch will be the > > > > "future way": > > > > > > > > > > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device > > > > qsv@d3d11va > > > > > > > > > > The new behaviour that is introduced by this patch is that an > > > > > initialized hw device can now be applied to qsv decoders > > > > > (currently only to filter graphs and qsv encoders). > > > > > > > > '-init_hw_device qsv=qsv:hw,child_device=xxx' s
