Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Saturday, November 26, 2022 3:36 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > On 11/25/2022 11:31 PM, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> James Almer > >> Sent: Saturday, November 26, 2022 2:01 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > support > >> P010 format > >> > >> On 11/25/2022 9:58 PM, Soft Works wrote: > >>> > >>> > -Original Message- > From: ffmpeg-devel On Behalf > Of > James Almer > Sent: Saturday, November 26, 2022 12:58 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > >> support > P010 format > > On 11/25/2022 8:51 PM, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf > >> Of > >> James Almer > >> Sent: Saturday, November 26, 2022 12:35 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > support > >> P010 format > >> > >> On 11/25/2022 8:26 PM, Dong, Ruijing wrote: > >>> [AMD Official Use Only - General] > >>> > >>> Will it make sense to accept P010 input, however encode to > h264 > >> 8bit? > >> > >> If it works (the encoder accepts the 10 bit input even if it > encodes > >> it > >> as 8bit), then i don't see why not. I assume it would also be > faster > >> than using swscale to convert said 10bit input to nv12 before > passing > >> that to the encoder. > >> > >> Removing support for a pixel format as input in an encoder > needs > >> a > >> reason other than "It's rarely used", more so when it's a > single > >> line. > >> It either needs to not work, or somehow get in the way of > >> further > >> improvements. > > > > Oh sorry, I noticed that there was a misunderstanding. > > > > When I said "It's rarely used", I didn't mean that as a > justification > > for the removal, it was meant as an explanation why none of the > > hwaccels has implemented it. > > > > softworkz > > Alright, then i'll repeat my question: Does it work? > >>> > >>> No. > >> > >> What does this encoder currently do when you feed it p010 input? > What > >> does it output? > > > > An error: > > > > > > 1. 10bit from HW context: > > > > > > [graph 0 video input from stream 0:0 @ 01dc301aeec0] w:3840 > h:2160 pixfmt:yuv420p10le tb:1/6 fr:6/1001 sar:1/1 > > [auto_scale_0 @ 01dc2362a700] w:iw h:ih flags:'' interl:0 > > [hwupload@f1 @ 01dc2944ef00] auto-inserting filter > 'auto_scale_0' between the filter 'graph 0 video input from stream > 0:0' and the filter 'hwupload@f1' > > [auto_scale_0 @ 01dc2362a700] w:3840 h:2160 fmt:yuv420p10le > sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 > > [AVHWDeviceContext @ 01dc444f9a00] D3D11 Init > > [AVHWDeviceContext @ 01dc444fab80] D3D11 Init > > [vpp_qsv@f2 @ 01dc22a3d880] VPP: input is video memory surface > > [vpp_qsv@f2 @ 01dc22a3d880] VPP: output is video memory surface > > [auto_scale_0 @ 01dc2362a700] w:3840 h:2160 fmt:yuv420p10le > sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 > > Last message repeated 2 times > > [h264_qsv @ 01dc161b6040] Using input frames context (format > qsv) with h264_qsv encoder. > > [h264_qsv @ 01dc161b6040] Encoder: input is video memory > surface > > [h264_qsv @ 01dc161b6040] Using the average variable bitrate > (AVBR) ratecontrol method > > [h264_qsv @ 01dc161b6040] Current pixel format is unsupported > > [h264_qsv @ 01dc161b6040] some encoding parameters are not > supported by the QSV runtime. Please double check the input > parameters. > > Error initializing output stream 0:0 -- Error while opening encoder > for output stream #0:0 - maybe incorrect parameters such as bit_rate, > rate, width or height > > [AVHWDeviceContext @ 01dc444f9a00] D3D11 Uninit > > [AVIOContext @ 01dc16197c80] Statistics: 0 bytes written, 0 > seeks, 0 writeouts > > [AVHWDeviceContext @ 01dc444fab80] D3D11 Uninit > > [AVIOContext @ 01dc161839c0] Statistics: 131146 bytes read, 2 > seeks > > Conversion failed! > > > > > > 2. 10bit from SW context: > > > > > > [graph 0 video input from stream 0:0 @ 019e915dee00] w:3840 > h:2160 pixfmt:yuv420p10le tb:1/6 fr:6/1001 sar:1/1 > > [auto_scale_0 @ 019ee99936c0] w:iw h:ih flags:'' interl:0 > > [format @ 019ee9993240] auto-inserting filter 'auto_scale_0' > between the filter 'Parsed_null_0' and the filter 'format' > > [auto_scale_0 @ 019ee99936c0] w:3840 h:2160 fmt:yuv420p10le > sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 > > Last message repeated 3 times
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format
On 11/25/2022 11:31 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Saturday, November 26, 2022 2:01 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 9:58 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Saturday, November 26, 2022 12:58 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:51 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Saturday, November 26, 2022 12:35 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:26 PM, Dong, Ruijing wrote: [AMD Official Use Only - General] Will it make sense to accept P010 input, however encode to h264 8bit? If it works (the encoder accepts the 10 bit input even if it encodes it as 8bit), then i don't see why not. I assume it would also be faster than using swscale to convert said 10bit input to nv12 before passing that to the encoder. Removing support for a pixel format as input in an encoder needs a reason other than "It's rarely used", more so when it's a single line. It either needs to not work, or somehow get in the way of further improvements. Oh sorry, I noticed that there was a misunderstanding. When I said "It's rarely used", I didn't mean that as a justification for the removal, it was meant as an explanation why none of the hwaccels has implemented it. softworkz Alright, then i'll repeat my question: Does it work? No. What does this encoder currently do when you feed it p010 input? What does it output? An error: 1. 10bit from HW context: [graph 0 video input from stream 0:0 @ 01dc301aeec0] w:3840 h:2160 pixfmt:yuv420p10le tb:1/6 fr:6/1001 sar:1/1 [auto_scale_0 @ 01dc2362a700] w:iw h:ih flags:'' interl:0 [hwupload@f1 @ 01dc2944ef00] auto-inserting filter 'auto_scale_0' between the filter 'graph 0 video input from stream 0:0' and the filter 'hwupload@f1' [auto_scale_0 @ 01dc2362a700] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 [AVHWDeviceContext @ 01dc444f9a00] D3D11 Init [AVHWDeviceContext @ 01dc444fab80] D3D11 Init [vpp_qsv@f2 @ 01dc22a3d880] VPP: input is video memory surface [vpp_qsv@f2 @ 01dc22a3d880] VPP: output is video memory surface [auto_scale_0 @ 01dc2362a700] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 Last message repeated 2 times [h264_qsv @ 01dc161b6040] Using input frames context (format qsv) with h264_qsv encoder. [h264_qsv @ 01dc161b6040] Encoder: input is video memory surface [h264_qsv @ 01dc161b6040] Using the average variable bitrate (AVBR) ratecontrol method [h264_qsv @ 01dc161b6040] Current pixel format is unsupported [h264_qsv @ 01dc161b6040] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [AVHWDeviceContext @ 01dc444f9a00] D3D11 Uninit [AVIOContext @ 01dc16197c80] Statistics: 0 bytes written, 0 seeks, 0 writeouts [AVHWDeviceContext @ 01dc444fab80] D3D11 Uninit [AVIOContext @ 01dc161839c0] Statistics: 131146 bytes read, 2 seeks Conversion failed! 2. 10bit from SW context: [graph 0 video input from stream 0:0 @ 019e915dee00] w:3840 h:2160 pixfmt:yuv420p10le tb:1/6 fr:6/1001 sar:1/1 [auto_scale_0 @ 019ee99936c0] w:iw h:ih flags:'' interl:0 [format @ 019ee9993240] auto-inserting filter 'auto_scale_0' between the filter 'Parsed_null_0' and the filter 'format' [auto_scale_0 @ 019ee99936c0] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 Last message repeated 3 times [h264_qsv @ 019ee9995dc0] Using device qd1 (type qsv) with h264_qsv encoder. [h264_qsv @ 019ee9995dc0] Encoder: input is system memory surface [h264_qsv @ 019ee9995dc0] Using the average variable bitrate (AVBR) ratecontrol method [h264_qsv @ 019ee9995dc0] Current pixel format is unsupported [h264_qsv @ 019ee9995dc0] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [AVIOContext @ 019ef62b4000] Statistics: 0 bytes written, 0 seeks, 0 writeouts [AVIOContext @ 019ee995abc0] Statistics: 131146 bytes read, 2 seeks Conversion failed! softworkz Alright, thanks for testing it. The commit message should mention the pixel format is being removed as it's
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Saturday, November 26, 2022 2:01 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > On 11/25/2022 9:58 PM, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> James Almer > >> Sent: Saturday, November 26, 2022 12:58 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > support > >> P010 format > >> > >> On 11/25/2022 8:51 PM, Soft Works wrote: > >>> > >>> > -Original Message- > From: ffmpeg-devel On Behalf > Of > James Almer > Sent: Saturday, November 26, 2022 12:35 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > >> support > P010 format > > On 11/25/2022 8:26 PM, Dong, Ruijing wrote: > > [AMD Official Use Only - General] > > > > Will it make sense to accept P010 input, however encode to h264 > 8bit? > > If it works (the encoder accepts the 10 bit input even if it > >> encodes > it > as 8bit), then i don't see why not. I assume it would also be > >> faster > than using swscale to convert said 10bit input to nv12 before > >> passing > that to the encoder. > > Removing support for a pixel format as input in an encoder needs > a > reason other than "It's rarely used", more so when it's a single > line. > It either needs to not work, or somehow get in the way of > further > improvements. > >>> > >>> Oh sorry, I noticed that there was a misunderstanding. > >>> > >>> When I said "It's rarely used", I didn't mean that as a > >> justification > >>> for the removal, it was meant as an explanation why none of the > >>> hwaccels has implemented it. > >>> > >>> softworkz > >> > >> Alright, then i'll repeat my question: Does it work? > > > > No. > > What does this encoder currently do when you feed it p010 input? What > does it output? An error: 1. 10bit from HW context: [graph 0 video input from stream 0:0 @ 01dc301aeec0] w:3840 h:2160 pixfmt:yuv420p10le tb:1/6 fr:6/1001 sar:1/1 [auto_scale_0 @ 01dc2362a700] w:iw h:ih flags:'' interl:0 [hwupload@f1 @ 01dc2944ef00] auto-inserting filter 'auto_scale_0' between the filter 'graph 0 video input from stream 0:0' and the filter 'hwupload@f1' [auto_scale_0 @ 01dc2362a700] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 [AVHWDeviceContext @ 01dc444f9a00] D3D11 Init [AVHWDeviceContext @ 01dc444fab80] D3D11 Init [vpp_qsv@f2 @ 01dc22a3d880] VPP: input is video memory surface [vpp_qsv@f2 @ 01dc22a3d880] VPP: output is video memory surface [auto_scale_0 @ 01dc2362a700] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 Last message repeated 2 times [h264_qsv @ 01dc161b6040] Using input frames context (format qsv) with h264_qsv encoder. [h264_qsv @ 01dc161b6040] Encoder: input is video memory surface [h264_qsv @ 01dc161b6040] Using the average variable bitrate (AVBR) ratecontrol method [h264_qsv @ 01dc161b6040] Current pixel format is unsupported [h264_qsv @ 01dc161b6040] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [AVHWDeviceContext @ 01dc444f9a00] D3D11 Uninit [AVIOContext @ 01dc16197c80] Statistics: 0 bytes written, 0 seeks, 0 writeouts [AVHWDeviceContext @ 01dc444fab80] D3D11 Uninit [AVIOContext @ 01dc161839c0] Statistics: 131146 bytes read, 2 seeks Conversion failed! 2. 10bit from SW context: [graph 0 video input from stream 0:0 @ 019e915dee00] w:3840 h:2160 pixfmt:yuv420p10le tb:1/6 fr:6/1001 sar:1/1 [auto_scale_0 @ 019ee99936c0] w:iw h:ih flags:'' interl:0 [format @ 019ee9993240] auto-inserting filter 'auto_scale_0' between the filter 'Parsed_null_0' and the filter 'format' [auto_scale_0 @ 019ee99936c0] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0 Last message repeated 3 times [h264_qsv @ 019ee9995dc0] Using device qd1 (type qsv) with h264_qsv encoder. [h264_qsv @ 019ee9995dc0] Encoder: input is system memory surface [h264_qsv @ 019ee9995dc0] Using the average variable bitrate (AVBR) ratecontrol method [h264_qsv @ 019ee9995dc0] Current pixel format is unsupported [h264_qsv @ 019ee9995dc0] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [AVIOContext @
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format
On 11/25/2022 9:58 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Saturday, November 26, 2022 12:58 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:51 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Saturday, November 26, 2022 12:35 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:26 PM, Dong, Ruijing wrote: [AMD Official Use Only - General] Will it make sense to accept P010 input, however encode to h264 8bit? If it works (the encoder accepts the 10 bit input even if it encodes it as 8bit), then i don't see why not. I assume it would also be faster than using swscale to convert said 10bit input to nv12 before passing that to the encoder. Removing support for a pixel format as input in an encoder needs a reason other than "It's rarely used", more so when it's a single line. It either needs to not work, or somehow get in the way of further improvements. Oh sorry, I noticed that there was a misunderstanding. When I said "It's rarely used", I didn't mean that as a justification for the removal, it was meant as an explanation why none of the hwaccels has implemented it. softworkz Alright, then i'll repeat my question: Does it work? No. What does this encoder currently do when you feed it p010 input? What does it output? If it does not, then that should have been mentioned in the patch as the reason why this is being done. For me it was clear, albeit a bit short. Anyway, I'll let Haihao, respond. Best, 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". ___ 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] lavc/qsvenc_h264: don't support P010 format
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Saturday, November 26, 2022 12:58 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > On 11/25/2022 8:51 PM, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> James Almer > >> Sent: Saturday, November 26, 2022 12:35 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > support > >> P010 format > >> > >> On 11/25/2022 8:26 PM, Dong, Ruijing wrote: > >>> [AMD Official Use Only - General] > >>> > >>> Will it make sense to accept P010 input, however encode to h264 > >> 8bit? > >> > >> If it works (the encoder accepts the 10 bit input even if it > encodes > >> it > >> as 8bit), then i don't see why not. I assume it would also be > faster > >> than using swscale to convert said 10bit input to nv12 before > passing > >> that to the encoder. > >> > >> Removing support for a pixel format as input in an encoder needs a > >> reason other than "It's rarely used", more so when it's a single > >> line. > >> It either needs to not work, or somehow get in the way of further > >> improvements. > > > > Oh sorry, I noticed that there was a misunderstanding. > > > > When I said "It's rarely used", I didn't mean that as a > justification > > for the removal, it was meant as an explanation why none of the > > hwaccels has implemented it. > > > > softworkz > > Alright, then i'll repeat my question: Does it work? No. > If it does > not, > then that should have been mentioned in the patch as the reason why > this > is being done. For me it was clear, albeit a bit short. Anyway, I'll let Haihao, respond. Best, 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] lavc/qsvenc_h264: don't support P010 format
On 11/25/2022 8:51 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Saturday, November 26, 2022 12:35 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:26 PM, Dong, Ruijing wrote: [AMD Official Use Only - General] Will it make sense to accept P010 input, however encode to h264 8bit? If it works (the encoder accepts the 10 bit input even if it encodes it as 8bit), then i don't see why not. I assume it would also be faster than using swscale to convert said 10bit input to nv12 before passing that to the encoder. Removing support for a pixel format as input in an encoder needs a reason other than "It's rarely used", more so when it's a single line. It either needs to not work, or somehow get in the way of further improvements. Oh sorry, I noticed that there was a misunderstanding. When I said "It's rarely used", I didn't mean that as a justification for the removal, it was meant as an explanation why none of the hwaccels has implemented it. softworkz Alright, then i'll repeat my question: Does it work? And I don't mean the encoder outputting a 10bit h264 stream, since you made it clear it doesn't, i mean accepting 10bit input in p010 pixel format and outputting a valid stream and not garbage. If it does, then there's no reason to remove this line. If it does not, then that should have been mentioned in the patch as the reason why this is being done. ___ 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] lavc/qsvenc_h264: don't support P010 format
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Saturday, November 26, 2022 12:35 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > On 11/25/2022 8:26 PM, Dong, Ruijing wrote: > > [AMD Official Use Only - General] > > > > Will it make sense to accept P010 input, however encode to h264 > 8bit? > > If it works (the encoder accepts the 10 bit input even if it encodes > it > as 8bit), then i don't see why not. I assume it would also be faster > than using swscale to convert said 10bit input to nv12 before passing > that to the encoder. > > Removing support for a pixel format as input in an encoder needs a > reason other than "It's rarely used", more so when it's a single > line. > It either needs to not work, or somehow get in the way of further > improvements. Oh sorry, I noticed that there was a misunderstanding. When I said "It's rarely used", I didn't mean that as a justification for the removal, it was meant as an explanation why none of the hwaccels has implemented it. 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] lavc/qsvenc_h264: don't support P010 format
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Saturday, November 26, 2022 12:25 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > On 11/25/2022 8:20 PM, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> James Almer > >> Sent: Friday, November 25, 2022 8:48 PM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > support > >> P010 format > >> > >> On 11/25/2022 3:03 PM, Soft Works wrote: > >>> > >>> > -Original Message- > From: ffmpeg-devel On Behalf > Of > Anton Khirnov > Sent: Friday, November 25, 2022 2:46 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Haihao Xiang > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > >> support > P010 format > > Why? > >>> > >>> It's rarely used. There's not even a hwaccel that can decode > this. > >> > >> The dxva2/d3d11 hwaccels seemingly do > > > > No, only for HEVC and VP9. Probably for AV1 as well in the near > future. > > Well, then that is a good reason to not remove support in this > encoder > for a pixel format that not only our software scaler can generate, > but > decoders using hwaccel backends can output too. That would be right when QSV would support it, but it doesn't, neither for decoding nor for encoding and there are no plans to implement it. I know this, because I had checked back with Intel on it, as I had been wondering about the existence of the MFX_PROFILE_AVC_HIGH10 constant, which is the profile for H.264 10bit encoding. It existed because an earlier version of MSDK had supported this, but only with their software implementations of H.264, never with HWA. And unlikely with ffmpeg as that constant has never been used there. Nvidia doesn't support it either. Neither decoding nor encoding. They don't even have a GUID constant mapping for the profile. https://www.ffmpeg.org/doxygen/3.2/nvEncodeAPI_8h_source.html (Line 151-) Best wishes, 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] lavc/qsvenc_h264: don't support P010 format
[AMD Official Use Only - General] We would like to add that in Mesa first to let vaapi path accept 10bit input and HW to convert it to 8bit if it makes sense to do so. Then get a chance to apply it to ffmpeg. Thanks Ruijing -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Friday, November 25, 2022 6:35 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:26 PM, Dong, Ruijing wrote: > [AMD Official Use Only - General] > > Will it make sense to accept P010 input, however encode to h264 8bit? If it works (the encoder accepts the 10 bit input even if it encodes it as 8bit), then i don't see why not. I assume it would also be faster than using swscale to convert said 10bit input to nv12 before passing that to the encoder. Removing support for a pixel format as input in an encoder needs a reason other than "It's rarely used", more so when it's a single line. It either needs to not work, or somehow get in the way of further improvements. > > Thanks, > Ruijing > > -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Friday, November 25, 2022 6:25 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > On 11/25/2022 8:20 PM, Soft Works wrote: >> >> >>> -Original Message- >>> From: ffmpeg-devel On Behalf Of >>> James Almer >>> Sent: Friday, November 25, 2022 8:48 PM >>> To: ffmpeg-devel@ffmpeg.org >>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support >>> P010 format >>> >>> On 11/25/2022 3:03 PM, Soft Works wrote: > -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Friday, November 25, 2022 2:46 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Haihao Xiang > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't >>> support > P010 format > > Why? It's rarely used. There's not even a hwaccel that can decode this. >>> >>> The dxva2/d3d11 hwaccels seemingly do >> >> No, only for HEVC and VP9. Probably for AV1 as well in the near future. > > Well, then that is a good reason to not remove support in this encoder for a > pixel format that not only our software scaler can generate, but decoders > using hwaccel backends can output too. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmp > eg.org%2Fmailman%2Flistinfo%2Fffmpeg-develdata=05%7C01%7Cruijing. > dong%40amd.com%7Cbcfc4e8b332b4a42691908dacf3d87e7%7C3dd8961fe4884e608e > 11a82d994e183d%7C0%7C0%7C638050160442866421%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > 0%7C%7C%7Csdata=8UN5OD1Yt2fmSkiHi4cLtnDryBlwpa8DF4Oi%2FMhjxPk%3D& > amp;reserved=0 > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmp > eg.org%2Fmailman%2Flistinfo%2Fffmpeg-develdata=05%7C01%7Cruijing. > dong%40amd.com%7Cbcfc4e8b332b4a42691908dacf3d87e7%7C3dd8961fe4884e608e > 11a82d994e183d%7C0%7C0%7C638050160442866421%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > 0%7C%7C%7Csdata=8UN5OD1Yt2fmSkiHi4cLtnDryBlwpa8DF4Oi%2FMhjxPk%3D& > amp;reserved=0 > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-develdata=05%7C01%7Cruijing.dong%40amd.com%7Cbcfc4e8b332b4a42691908dacf3d87e7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638050160442866421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8UN5OD1Yt2fmSkiHi4cLtnDryBlwpa8DF4Oi%2FMhjxPk%3Dreserved=0 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] avcodec/pictordec: Remove mid exit branch
On Fri, Nov 25, 2022 at 09:18:33PM +0100, Michael Niedermayer wrote:
> This causes the RLE decoder to exit before applying the last RLE run
> All images i tested with are unchanged, this makes the special case
> for handling the last run unused for non truncated images.
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pictordec.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/libavcodec/pictordec.c b/libavcodec/pictordec.c
> index 09229b94fd..27f5b96571 100644
> --- a/libavcodec/pictordec.c
> +++ b/libavcodec/pictordec.c
> @@ -246,8 +246,6 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
> *frame,
> run = bytestream2_get_le16(>g);
> val = bytestream2_get_byte(>g);
> }
> -if (!bytestream2_get_bytes_left(>g))
> -break;
>
> if (bits_per_plane == 8) {
> picmemset_8bpp(s, frame, val, run, , );
> --
> 2.17.1
ok
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
___
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/2] avcodec/pictordec: Check that the image fits in the input
On Fri, Nov 25, 2022 at 03:11:32PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2022-11-25 14:38:46) > > t On Fri, Nov 25, 2022 at 05:45:29PM +1100, Peter Ross wrote: > > > On Tue, Nov 22, 2022 at 11:56:51PM +0100, Michael Niedermayer wrote: > > > > Fixes: Timeout > > > > Fixes: > > > > 53438/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-5458939919859712 > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpe > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavcodec/pictordec.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/libavcodec/pictordec.c b/libavcodec/pictordec.c > > > > index 71bad40a0a..09229b94fd 100644 > > > > --- a/libavcodec/pictordec.c > > > > +++ b/libavcodec/pictordec.c > > > > @@ -162,6 +162,9 @@ static int decode_frame(AVCodecContext *avctx, > > > > AVFrame *frame, > > > > > > > > if (av_image_check_size(s->width, s->height, 0, avctx) < 0) > > > > return -1; > > > > +if (bytestream2_get_bytes_left(>g) < s->width * s->height / > > > > 65536 * 5) > > > > +return AVERROR_INVALIDDATA; > > > > > > how did you arrive at this formula? > > > > There are 2 coding modes, RLE and RAW > > I assume usable raw images will need around W*H and thus more than RLE > > RLE codes the most compressed runs by > > 1 byte for val (=marker) > > 1 byte run (=0) > > 2 bytes run > > 1 byte val > > thats 5 bytes and the maximum run we can code is 65535 > > > > The RLE decoder loop exits before applying the last RLE run and then > > there is a seperate piece of code after it that fills the last color to > > the end. Iam not sure why its done like that way but if i remove that > > mid exit the seperate code piece becomes unused for all images i have > > so it seems all RLE images are always fully coded with no special case > > at the end. > > Based on this iam guesing that my formula is correct for undamaged images > > but of course i could find one tomorrow that exploits the special end > > handling and breaks this formula > > and of course its very possible that i missed some other thing that changes > > this limit > > This should be written in a comment above the code then, otherwise all > future readers will be completely clueless. good idea. ok, patch looks good. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) 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] lavc/qsvenc_h264: don't support P010 format
On 11/25/2022 8:26 PM, Dong, Ruijing wrote: [AMD Official Use Only - General] Will it make sense to accept P010 input, however encode to h264 8bit? If it works (the encoder accepts the 10 bit input even if it encodes it as 8bit), then i don't see why not. I assume it would also be faster than using swscale to convert said 10bit input to nv12 before passing that to the encoder. Removing support for a pixel format as input in an encoder needs a reason other than "It's rarely used", more so when it's a single line. It either needs to not work, or somehow get in the way of further improvements. Thanks, Ruijing -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Friday, November 25, 2022 6:25 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:20 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Friday, November 25, 2022 8:48 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 3:03 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Anton Khirnov Sent: Friday, November 25, 2022 2:46 PM To: FFmpeg development discussions and patches Cc: Haihao Xiang Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format Why? It's rarely used. There's not even a hwaccel that can decode this. The dxva2/d3d11 hwaccels seemingly do No, only for HEVC and VP9. Probably for AV1 as well in the near future. Well, then that is a good reason to not remove support in this encoder for a pixel format that not only our software scaler can generate, but decoders using hwaccel backends can output too. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-develdata=05%7C01%7Cruijing.dong%40amd.com%7Cf449421fd89948ad96cc08dacf3c324b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638050154742304108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=xFeOvsaJw%2F9BlPifrqx33Pv8GurJ1N2lVyuUYHIOClo%3Dreserved=0 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". ___ 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] lavc/qsvenc_h264: don't support P010 format
[AMD Official Use Only - General] Will it make sense to accept P010 input, however encode to h264 8bit? Thanks, Ruijing -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Friday, November 25, 2022 6:25 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 8:20 PM, Soft Works wrote: > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> James Almer >> Sent: Friday, November 25, 2022 8:48 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support >> P010 format >> >> On 11/25/2022 3:03 PM, Soft Works wrote: >>> >>> -Original Message- From: ffmpeg-devel On Behalf Of Anton Khirnov Sent: Friday, November 25, 2022 2:46 PM To: FFmpeg development discussions and patches >>> de...@ffmpeg.org> Cc: Haihao Xiang Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't >> support P010 format Why? >>> >>> It's rarely used. There's not even a hwaccel that can decode this. >> >> The dxva2/d3d11 hwaccels seemingly do > > No, only for HEVC and VP9. Probably for AV1 as well in the near future. Well, then that is a good reason to not remove support in this encoder for a pixel format that not only our software scaler can generate, but decoders using hwaccel backends can output too. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-develdata=05%7C01%7Cruijing.dong%40amd.com%7Cf449421fd89948ad96cc08dacf3c324b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638050154742304108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=xFeOvsaJw%2F9BlPifrqx33Pv8GurJ1N2lVyuUYHIOClo%3Dreserved=0 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] lavc/qsvenc_h264: don't support P010 format
On 11/25/2022 8:20 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Friday, November 25, 2022 8:48 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format On 11/25/2022 3:03 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Anton Khirnov Sent: Friday, November 25, 2022 2:46 PM To: FFmpeg development discussions and patches Cc: Haihao Xiang Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format Why? It's rarely used. There's not even a hwaccel that can decode this. The dxva2/d3d11 hwaccels seemingly do No, only for HEVC and VP9. Probably for AV1 as well in the near future. Well, then that is a good reason to not remove support in this encoder for a pixel format that not only our software scaler can generate, but decoders using hwaccel backends can output too. ___ 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] lavc/qsvenc_h264: don't support P010 format
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Friday, November 25, 2022 8:48 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > On 11/25/2022 3:03 PM, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> Anton Khirnov > >> Sent: Friday, November 25, 2022 2:46 PM > >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> > >> Cc: Haihao Xiang > >> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't > support > >> P010 format > >> > >> Why? > > > > It's rarely used. There's not even a hwaccel that can decode this. > > The dxva2/d3d11 hwaccels seemingly do No, only for HEVC and VP9. Probably for AV1 as well in the near future. But not for H.264. Not for the 3 decoder GUIDs that ffmpeg supports.. https://www.ffmpeg.org/doxygen/5.1/dxva2_8c_source.html (Line 39-41) ...neither for any of the others which are known. I'm doing some comprehensive detection of HW capabilities, which includes enumerating DXVA2/DX11VA decoders and "render targets" (which map to color formats). I have a large collection of such detection logs and I've never seen any H.264 DXVA2/DX11VA decoder which would support 10bit decoding. Here's an example how it looks like for a system with contemporary Nvidia and Intel GPUs: "Detection Log", "Debug: Create DXGI Factory", "Debug: DXGI Factory created", "Debug: Detected 3 video adapters.", "Info: Adapter #0: 'NVIDIA Quadro RTX 4000' Id:7857 (Driver: , Vendor: 4318)", "Debug: Device successfully created", "Debug: VideoDevice successfully created", "Info: 86695f12-340e-4f04-9fd3-9253dd327460: DXVA2_ModeMPEG2and1_VLD MPEG-2 & MPEG-1 variable-length decoder - mpeg2video", "Info: ee27417f-5e28-4e65-beea-1d26b508adc9: DXVA2_ModeMPEG2_VLD MPEG-2 variable-length decoder - mpeg2video", "Info: 6f3ec719-3735-42cc-8063-65cc3cb36616: DXVA2_ModeMPEG1_VLD MPEG-1 variable-length decoder - mpeg1video", "Info: 1b81bea4-a0c7-11d3-b984-00c04f2e73c5: DXVA2_ModeVC1_D2010 VC-1 variable-length decoder (2010) - vc1", "Info: 1b81bea3-a0c7-11d3-b984-00c04f2e73c5: DXVA2_ModeVC1_D VC-1 variable-length decoder - vc1", "Info: 32fcfe3f-de46-4a49-861b-ac71110649d5: - ", "Info: d79be8da-0cf1-4c81-b82a-69a4e236f43d: DXVA2_ModeH264_VLD_Stereo_Progressive_NoFGT H.264 MVC variable-length decoder, stereo, progressive - h264", "Info: f9aaccbb-c2b6-4cfc-8779-5707b1760552: DXVA2_ModeH264_VLD_Stereo_NoFGT H.264 MVC variable-length decoder, stereo - h264", "Info: 1b81be68-a0c7-11d3-b984-00c04f2e73c5: DXVA2_ModeH264_E H.264 variable-length decoder, no film grain technology - h264", "Info: 5b11d51b-2f4c-4452-bcc3-09f2a1160cc0: DXVA2_ModeHEVC_VLD_Main H.265 variable-length decoder, Main profile - hevc", "Info: 107af0e0-ef1a-4d19-aba8-67a163073d13: DXVA2_ModeHEVC_VLD_Main10 H.265 variable-length decoder, Main 10 profile - hevc", "Info: 20bb8b0a-97aa-4571-8e99-64e60606c1a6: - ", "Info: 15df9b21-06c4-47f1-841e-a67c97d7f312: - ", "Info: efd64d74-c9e8-41d7-a5e9-e9b0e39fa319: DXVA2_ModeMPEG4pt2_VLD_Simple MPEG-4 Part 2 variable-length decoder, Simple profile - mpeg4", "Info: ed418a9f-010d-4eda-9ae3-9a65358d8d2e: DXVA2_ModeMPEG4pt2_VLD_AdvSimple_NoGMC MPEG-4 Part 2 variable-length decoder, Simple & Advanced profile, no GMC - mpeg4", "Info: 9947ec6f-689b-11dc-a320-0019dbbc4184: DXVA2_nVidia_MPEG4_ASP MPEG-4 Part 2 nVidia bitstream decoder - mpeg4", "Info: 33fcfe41-de46-4a49-861b-ac71110649d5: - ", "Info: 463707f8-a1d0-4585-876d-83aa6d60b89e: DXVA2_ModeVP9_VLD_Profile0 VP9 Profile 0 - vp9", "Info: a4c749ef-6ecf-48aa-8448-50a7a1165ff7: DXVA2_ModeVP9_VLD_10bit_Profile2 VP9 10 bit Profile 2 - vp9", "Info: dda19dc7-93b5-49f5-a9b3-2bda28a2ce6e: - ", "Info: 6affd11e-1d96-42b1-a215-93a31f09a53d: - ", "Info: 914c84a3-4078-4fa9-984c-e2f262cb5c9c: - ", "Info: 8a1a1031-29bc-46d0-a007-e9b092ca6767: - ", "Debug:DXVA2_ModeMPEG2and1_VLD - ColorFormat #0: NV12 => nv12", "Debug: Supported Resolutions: 160x120, 176x144, 320x240, 352x288, 720x480, 720x240, 720x576, 1280x720, 1920x1080, 2048x1024, 2048x1080, 3140x2160, 3680x1536, 3840x2160", "Debug: Unsupported Resolutions: 4096x2048, 4096x2160, 4096x2176, 7680x4320, 8192x4320, 8192x4352", "Debug: Max Resolution: 3840x2160", "Debug:DXVA2_ModeMPEG2and1_VLD - ColorFormat #1: Opaque420 => yuv420p", "Debug: Supported Resolutions: 160x120, 176x144, 320x240, 352x288, 720x480, 720x240, 720x576, 1280x720, 1920x1080, 2048x1024, 2048x1080, 3140x2160, 3680x1536, 3840x2160", "Debug: Unsupported Resolutions: 4096x2048, 4096x2160, 4096x2176, 7680x4320, 8192x4320, 8192x4352", "Debug: Max Resolution: 3840x2160", "Debug:DXVA2_ModeMPEG2_VLD - ColorFormat #0: NV12 => nv12", "Debug: Supported Resolutions: 160x120, 176x144, 320x240, 352x288, 720x480, 720x240, 720x576, 1280x720, 1920x1080, 2048x1024,
Re: [FFmpeg-devel] [PATCH v7 0/3] 32bps FLAC patches
On 10/11/22, Martijn van Beurden wrote: > Recently libFLAC gained the ability (first released in FLAC 1.4.0) > to create FLAC files containing 32-bit int PCM samples. To > keep complexity reasonable, the choice was made to limit residuals > to 32-bit integers, which the encoder must make sure of. In case > the encoder cannot find any predictor of which the residuals fit > this limit, it must default to using a verbatim subframe. Tests have > shown that this does not happen often (<0.1% of subframes on a > music corpus of various styles). See also discussion here: > https://github.com/ietf-wg-cellar/flac-specification/pull/148 > > These two patches implement decoding and encoding following this > format. > > Changes since v1: > fix copy-paste error in encoder, several invocations of > lpc_encode_choose_datapath used wrong parameters, making FATE fail as > compression was less than it should be > > Changes since v2: > Rebased decoder part as it didn't apply anymore > > Changes since v3: > Moved put_golomb part to flacenc.c (as it is now quite specific to FLAC) > and renamed put_sbits64 to put_sbits63 (and changed assert accordingly) > > Changes since v4: > Fix check of decoded_buffer_33bps malloc. Fix reading of wasted bits > for 33bps subframe. Add fate test > > Changes since v5: > Slimmed down 32 bps fate flac test from 2 to 1 input file. Replaced > -strict -2 with -strict experimental in fate and encoder warning. > > Changes since v6: > Deduplicated function bodies with preprocessor macros in both > encoder and decoder, declared variables in loop body where possible > and changed ff_ctz to ff_ctzll where necessary > > Martijn van Beurden (3): > libavcodec/flacdec: Implement decoding of 32 bit-per-sample PCM > libavcodec/flacenc: Implement encoding of 32 bit-per-sample PCM > fate/flac: Add test of 32 bps encoding/decoding > > libavcodec/flac.c | 4 +- > libavcodec/flacdec.c| 218 -- > libavcodec/flacenc.c| 480 +++- > libavcodec/get_bits.h | 12 + > libavcodec/mathops.h| 9 + > libavcodec/put_bits.h | 7 + > libavcodec/put_golomb.h | 14 -- > tests/fate/flac.mak | 4 + > 8 files changed, 602 insertions(+), 146 deletions(-) > > -- > 2.30.2 > If this is OK, 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".
[FFmpeg-devel] [PATCH] avcodec/pictordec: Remove mid exit branch
This causes the RLE decoder to exit before applying the last RLE run
All images i tested with are unchanged, this makes the special case
for handling the last run unused for non truncated images.
Signed-off-by: Michael Niedermayer
---
libavcodec/pictordec.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/pictordec.c b/libavcodec/pictordec.c
index 09229b94fd..27f5b96571 100644
--- a/libavcodec/pictordec.c
+++ b/libavcodec/pictordec.c
@@ -246,8 +246,6 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
*frame,
run = bytestream2_get_le16(>g);
val = bytestream2_get_byte(>g);
}
-if (!bytestream2_get_bytes_left(>g))
-break;
if (bits_per_plane == 8) {
picmemset_8bpp(s, frame, val, run, , );
--
2.17.1
___
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] lavc/qsvenc_h264: don't support P010 format
On 11/25/2022 3:03 PM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Anton Khirnov Sent: Friday, November 25, 2022 2:46 PM To: FFmpeg development discussions and patches Cc: Haihao Xiang Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format Why? It's rarely used. There's not even a hwaccel that can decode this. The dxva2/d3d11 hwaccels seemingly do, as does the qsv decoder. And being rarely used alone is not a reason to remove something. There needs to be some benefit to justify it (Simplifying maintenance, removing legacy code, etc). Also, p010 can be generated by swscale, and the only other software pixel format supported in this list is nv12, which is 8bit. If we remove p010, we would be making 10bit encodings not longer work with the output of software decoders as input, right? ___ 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] [PATCH] avfilter: add showcwt multimedia filter
Hello,
Patch attached.
From 68ef81098aebca9064f9c67e746476c39729e63b Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sat, 19 Nov 2022 19:01:23 +0100
Subject: [PATCH] avfilter: add showcwt multimedia filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 66 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/avf_showcwt.c | 558 ++
4 files changed, 626 insertions(+)
create mode 100644 libavfilter/avf_showcwt.c
diff --git a/doc/filters.texi b/doc/filters.texi
index ecf8dfa47a..5f35bd7e4e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -29274,6 +29274,72 @@ axisfile=myaxis.png:basefreq=40:endfreq=1
@end example
@end itemize
+@section showcwt
+
+Convert input audio to video output representing frequency spectrum
+linearly or logarithmically using Continuous Wavelet Transform and
+Morlet wavelet.
+
+The filter accepts the following options:
+
+@table @option
+@item size, s
+Specify the video size for the output. For the syntax of this option,
+check the @ref{video size syntax,,"Video size" section in the ffmpeg-utils manual,ffmpeg-utils}.
+Default value is @code{640x512}.
+
+@item rate, r
+Set the output frame rate. Default value is @code{25}.
+
+@item scale
+Set the frequency scale used. Can be @code{linear} or @code{log}.
+Default value is @code{linear}.
+
+@item min
+Set the minimum frequency that will be used in output.
+Default is @code{20} Hz.
+
+@item max
+Set the maximum frequency that will be used in output.
+Default is @code{2} Hz. The real frequency upper limit
+depends on input audio's sample rate and such will be enforced
+on this value when it is set to value greater than Nyquist frequency.
+
+@item logb
+Set the logarithmic basis for brightness strength when
+mapping calculated magnitude values to pixel values.
+Allowed range is from @code{0} to @code{1}.
+Default value is @code{0.0001}.
+
+@item deviation
+Set the frequency deviation.
+Lower values than @code{1} are more frequency oriented,
+while higher values than @code{1} are more time oriented.
+Allowed range is from @code{0} to @code{10}.
+Default value is @code{1}.
+
+@item pps
+Set the number of pixel output per each second in one row.
+Allowed range is from @code{1} to @code{1024}.
+Default value is @code{64}.
+
+@item mode
+Set the output visual mode. Allowed values are:
+
+@table @option
+@item magnitude
+Show magnitude.
+@item phase
+Show only phase.
+@item magphase
+Show combination of magnitude and phase.
+Magnitude is mapped to brightness and phase to color.
+@end table
+
+Default value is @code{magnitude}.
+
+@end table
+
@section showfreqs
Convert input audio to video output representing the audio power spectrum.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 66c754f1f5..2791b6a950 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -595,6 +595,7 @@ OBJS-$(CONFIG_APHASEMETER_FILTER)+= avf_aphasemeter.o
OBJS-$(CONFIG_AVECTORSCOPE_FILTER) += avf_avectorscope.o
OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o
OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o lswsutils.o lavfutils.o
+OBJS-$(CONFIG_SHOWCWT_FILTER)+= avf_showcwt.o
OBJS-$(CONFIG_SHOWFREQS_FILTER) += avf_showfreqs.o
OBJS-$(CONFIG_SHOWSPATIAL_FILTER)+= avf_showspatial.o
OBJS-$(CONFIG_SHOWSPECTRUM_FILTER) += avf_showspectrum.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 4909732002..3ff20e76ce 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -560,6 +560,7 @@ extern const AVFilter ff_avf_aphasemeter;
extern const AVFilter ff_avf_avectorscope;
extern const AVFilter ff_avf_concat;
extern const AVFilter ff_avf_showcqt;
+extern const AVFilter ff_avf_showcwt;
extern const AVFilter ff_avf_showfreqs;
extern const AVFilter ff_avf_showspatial;
extern const AVFilter ff_avf_showspectrum;
diff --git a/libavfilter/avf_showcwt.c b/libavfilter/avf_showcwt.c
new file mode 100644
index 00..c24efe3686
--- /dev/null
+++ b/libavfilter/avf_showcwt.c
@@ -0,0 +1,558 @@
+/*
+ * Copyright (c) 2022 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Friday, November 25, 2022 2:46 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Haihao Xiang > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support > P010 format > > Why? It's rarely used. There's not even a hwaccel that can decode this. 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".
[FFmpeg-devel] [PATCH 2/2] lavf: deprecate AVFMT_FLAG_AUTO_BSF
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 5 -
libavformat/options_table.h | 4 +++-
libavformat/version_major.h | 1 +
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ab7ce15faea..5611e012cc3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
API changes, most recent first:
+2022-12-xx - xx - lavf 59 - avformat.h
+ Deprecate AVFMT_FLAG_AUTO_BSF without replacement.
+
2022-11-xx - xx - lavu 57.43.100 - tx.h
Add AV_TX_FLOAT_DCT, AV_TX_DOUBLE_DCT and AV_TX_INT32_DCT.
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 1d97d56ac58..73628cdf2b7 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1357,7 +1357,10 @@ typedef struct AVFormatContext {
#endif
#define AVFMT_FLAG_FAST_SEEK 0x8 ///< Enable fast, but inaccurate seeks
for some formats
#define AVFMT_FLAG_SHORTEST 0x10 ///< Stop muxing when the shortest
stream stops.
-#define AVFMT_FLAG_AUTO_BSF 0x20 ///< Add bitstream filters as requested
by the muxer
+
+#if FF_API_AUTO_BSF
+#define AVFMT_FLAG_AUTO_BSF 0x20 ///< deprecated, does nothing
+#endif
/**
* Maximum number of bytes read from input in order to determine stream
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 83e6c6fb3cb..2b6d1b79955 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -52,7 +52,9 @@ static const AVOption avformat_options[] = {
{"nobuffer", "reduce the latency introduced by optional buffering", 0,
AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_NOBUFFER }, 0, INT_MAX, D, "fflags"},
{"bitexact", "do not write random/volatile data", 0, AV_OPT_TYPE_CONST, { .i64
= AVFMT_FLAG_BITEXACT }, 0, 0, E, "fflags" },
{"shortest", "stop muxing with the shortest stream", 0, AV_OPT_TYPE_CONST, {
.i64 = AVFMT_FLAG_SHORTEST }, 0, 0, E, "fflags" },
-{"autobsf", "add needed bsfs automatically", 0, AV_OPT_TYPE_CONST, { .i64 =
AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
+#if FF_API_AUTO_BSF
+{"autobsf", "deprecated, does nothing", 0, AV_OPT_TYPE_CONST, { .i64 =
AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
+#endif
{"seek2any", "allow seeking to non-keyframes on demuxer level when supported",
OFFSET(seek2any), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, D},
{"analyzeduration", "specify how many microseconds are analyzed to probe the
input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0,
INT64_MAX, D},
{"cryptokey", "decryption key", OFFSET(key), AV_OPT_TYPE_BINARY, {.dbl = 0},
0, 0, D},
diff --git a/libavformat/version_major.h b/libavformat/version_major.h
index 86af3ee4a5a..02cbc2bbaa7 100644
--- a/libavformat/version_major.h
+++ b/libavformat/version_major.h
@@ -48,6 +48,7 @@
#define FF_API_AVSTREAM_CLASS (LIBAVFORMAT_VERSION_MAJOR > 59)
#define FF_API_GET_END_PTS (LIBAVFORMAT_VERSION_MAJOR < 60)
#define FF_API_AVIODIRCONTEXT (LIBAVFORMAT_VERSION_MAJOR < 60)
+#define FF_API_AUTO_BSF (LIBAVFORMAT_VERSION_MAJOR < 61)
#define FF_API_R_FRAME_RATE1
--
2.35.1
___
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] [PATCH 1/2] lavf: stop honoring AVFMT_FLAG_AUTO_BSF
There should no longer be reason for the callers to disable this.
In-muxer bitstream filtering should be considered a part of the muxer
internals and invisible to the caller.
---
libavformat/internal.h | 5 +
libavformat/movenc.c| 5 +++--
libavformat/mux.c | 3 ++-
libavformat/options_table.h | 2 +-
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index ce837fefc76..e96bf4cc56d 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -186,6 +186,11 @@ typedef struct FFFormatContext {
* Contexts and child contexts do not contain a metadata option
*/
int metafree;
+
+/**
+ * Disable muxer-level bitstream filtering.
+ */
+int disable_bsf;
} FFFormatContext;
static av_always_inline FFFormatContext *ffformatcontext(AVFormatContext *s)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 064b5419721..a4dd8619dcc 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6829,6 +6829,7 @@ static int
mov_create_dvd_sub_decoder_specific_info(MOVTrack *track,
static int mov_init(AVFormatContext *s)
{
+FFFormatContext *const si = ffformatcontext(s);
MOVMuxContext *mov = s->priv_data;
int i, ret;
@@ -6875,9 +6876,9 @@ static int mov_init(AVFormatContext *s)
mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
FF_MOV_FLAG_DEFAULT_BASE_MOOF |
FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;
-if (mov->flags & FF_MOV_FLAG_EMPTY_MOOV && s->flags & AVFMT_FLAG_AUTO_BSF)
{
+if (mov->flags & FF_MOV_FLAG_EMPTY_MOOV) {
av_log(s, AV_LOG_VERBOSE, "Empty MOOV enabled; disabling automatic
bitstream filtering\n");
-s->flags &= ~AVFMT_FLAG_AUTO_BSF;
+si->disable_bsf = 1;
}
if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && mov->flags &
FF_MOV_FLAG_SKIP_SIDX) {
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 37fe19358de..fff500dd554 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1072,9 +1072,10 @@ const AVPacket *ff_interleaved_peek(AVFormatContext *s,
int stream)
static int check_bitstream(AVFormatContext *s, FFStream *sti, AVPacket *pkt)
{
+FFFormatContext *const si = ffformatcontext(s);
int ret;
-if (!(s->flags & AVFMT_FLAG_AUTO_BSF))
+if (si->disable_bsf)
return 1;
if (s->oformat->check_bitstream) {
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 86d836cfebb..83e6c6fb3cb 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -39,7 +39,7 @@ static const AVOption avformat_options[] = {
{"probesize", "set probing size", OFFSET(probesize), AV_OPT_TYPE_INT64, {.i64
= 500 }, 32, INT64_MAX, D},
{"formatprobesize", "number of bytes to probe file format",
OFFSET(format_probesize), AV_OPT_TYPE_INT, {.i64 = PROBE_BUF_MAX}, 0,
INT_MAX-1, D},
{"packetsize", "set packet size", OFFSET(packet_size), AV_OPT_TYPE_INT, {.i64
= DEFAULT }, 0, INT_MAX, E},
-{"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = AVFMT_FLAG_AUTO_BSF
}, INT_MIN, INT_MAX, D|E, "fflags"},
+{"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, INT_MIN,
INT_MAX, D|E, "fflags"},
{"flush_packets", "reduce the latency by flushing out packets immediately", 0,
AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_FLUSH_PACKETS }, INT_MIN, INT_MAX, E,
"fflags"},
{"ignidx", "ignore index", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_IGNIDX },
INT_MIN, INT_MAX, D, "fflags"},
{"genpts", "generate pts", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_GENPTS },
INT_MIN, INT_MAX, D, "fflags"},
--
2.35.1
___
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 0/3] 32bps FLAC patches
Op vr 11 nov. 2022 om 22:11 schreef Martijn van Beurden : > > Op vr 28 okt. 2022 om 22:13 schreef Martijn van Beurden : > > > > Op di 11 okt. 2022 om 19:24 schreef Martijn van Beurden : > > > > > > Recently libFLAC gained the ability (first released in FLAC 1.4.0) > > > to create FLAC files containing 32-bit int PCM samples. To > > > keep complexity reasonable, the choice was made to limit residuals > > > to 32-bit integers, which the encoder must make sure of. In case > > > the encoder cannot find any predictor of which the residuals fit > > > this limit, it must default to using a verbatim subframe. Tests have > > > shown that this does not happen often (<0.1% of subframes on a > > > music corpus of various styles). See also discussion here: > > > https://github.com/ietf-wg-cellar/flac-specification/pull/148 > > > > > > These two patches implement decoding and encoding following this > > > format. > > > > > > Changes since v1: > > > fix copy-paste error in encoder, several invocations of > > > lpc_encode_choose_datapath used wrong parameters, making FATE fail as > > > compression was less than it should be > > > > > > Changes since v2: > > > Rebased decoder part as it didn't apply anymore > > > > > > Changes since v3: > > > Moved put_golomb part to flacenc.c (as it is now quite specific to FLAC) > > > and renamed put_sbits64 to put_sbits63 (and changed assert accordingly) > > > > > > Changes since v4: > > > Fix check of decoded_buffer_33bps malloc. Fix reading of wasted bits > > > for 33bps subframe. Add fate test > > > > > > Changes since v5: > > > Slimmed down 32 bps fate flac test from 2 to 1 input file. Replaced > > > -strict -2 with -strict experimental in fate and encoder warning. > > > > > > Changes since v6: > > > Deduplicated function bodies with preprocessor macros in both > > > encoder and decoder, declared variables in loop body where possible > > > and changed ff_ctz to ff_ctzll where necessary > > > > > > Martijn van Beurden (3): > > > libavcodec/flacdec: Implement decoding of 32 bit-per-sample PCM > > > libavcodec/flacenc: Implement encoding of 32 bit-per-sample PCM > > > fate/flac: Add test of 32 bps encoding/decoding > > > > > > libavcodec/flac.c | 4 +- > > > libavcodec/flacdec.c| 218 -- > > > libavcodec/flacenc.c| 480 +++- > > > libavcodec/get_bits.h | 12 + > > > libavcodec/mathops.h| 9 + > > > libavcodec/put_bits.h | 7 + > > > libavcodec/put_golomb.h | 14 -- > > > tests/fate/flac.mak | 4 + > > > 8 files changed, 602 insertions(+), 146 deletions(-) > > > > > > > Hi all, > > > > With this email, I would like to renew the attention of the mailing > > list for these patches. > > > > Kind regards, Martijn van Beurden > > Ping Ping ___ 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] vulkan video
> On 19. Nov 2022, at 14:30, Lynne wrote: > > Nov 19, 2022, 11:48 by danieloberh...@googlemail.com: > >> Hello, reposting this from the user list as it seems it did not get any >> attention there and maybe is better suited here: >> >> I saw recently on phoronix that there was a vulkan video branch. >> Unfortunately that seems to have grown stale. Is there any chance vulkan >> video will make it into ffmpeg any time soon? I could also help if help is >> needed. We could really use that. >> >> Best >> >> Daniel >> > > I'm the one working on that. We'll have a new release in a month or so, which > coincides > with the Vulkan video spec being stabilized, so I'll finish the code and get > it merged. > The spec folks also want feedback too Oh, that’s very cool :) ___ 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] [PATCH v2 5/5] avcodec/x86/v210enc: remove unneeded instruction
--- libavcodec/x86/v210enc.asm | 1 - 1 file changed, 1 deletion(-) diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm index d3639cd440..daf5f2ab81 100644 --- a/libavcodec/x86/v210enc.asm +++ b/libavcodec/x86/v210enc.asm @@ -331,7 +331,6 @@ cglobal v210_planar_pack_8, 5, 5, 7+notcpuflag(avx512icl), y, u, v, dst, width vpternlogd m0, m1, m6, 0xd8 ; C?B:A ; merge and mask out bad bits from B %else pand m1, m6, m1 -pandn m0, m6, m0 porm0, m0, m1 %endif -- 2.38.0 ___ 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] [PATCH v2 4/5] avcodec/x86/v210enc: expand and correct comments
--- libavcodec/x86/v210enc.asm | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm index 552164a8be..d3639cd440 100644 --- a/libavcodec/x86/v210enc.asm +++ b/libavcodec/x86/v210enc.asm @@ -314,7 +314,7 @@ cglobal v210_planar_pack_8, 5, 5, 7+notcpuflag(avx512icl), y, u, v, dst, width movu ym1, [yq + 2*widthq] vinserti32x4 m1, [uq + 1*widthq], 2 vinserti32x4 m1, [vq + 1*widthq], 3 -vpermbm1, m2, m1 ; uyv0 yuy0 vyu0 yvy0 +vpermbm1, m2, m1 ; uyvx yuyx vyux yvyx %else movq xm0, [uq + 1*widthq]; uuxx movq xm1, [vq + 1*widthq]; vvxx @@ -325,10 +325,10 @@ cglobal v210_planar_pack_8, 5, 5, 7+notcpuflag(avx512icl), y, u, v, dst, width %endif CLIPUB m1, m4, m5 -pmaddubsw m0, m1, m3 -pslld m1, 4 +pmaddubsw m0, m1, m3 ; shift high and low samples of each dword and mask out other bits +pslld m1, 4 ; shift center sample of each dword %if cpuflag(avx512) -vpternlogd m0, m1, m6, 0xd8 ; C?B:A +vpternlogd m0, m1, m6, 0xd8 ; C?B:A ; merge and mask out bad bits from B %else pand m1, m6, m1 pandn m0, m6, m0 -- 2.38.0 ___ 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] [PATCH v2 3/5] avcodec/v210enc: add new 10-bit function for avx512 avx512icl
avx512 on Skylake-X (Xeon D-2123IT):
1.19x faster (970±91.2 vs. 817±104.4 decicycles) compared with avx2
avx512icl on Ice Lake (Xeon Silver 4316):
2.52x faster (1350±5.3 vs. 535±9.5 decicycles) compared with avx2
---
libavcodec/x86/v210enc.asm| 99 +++
libavcodec/x86/v210enc_init.c | 12 +
2 files changed, 111 insertions(+)
diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
index c2ad3d72c0..552164a8be 100644
--- a/libavcodec/x86/v210enc.asm
+++ b/libavcodec/x86/v210enc.asm
@@ -56,6 +56,36 @@ v210enc_8_permd: dd 0,1,4,5, 1,2,5,6
v210enc_8_mult: db 4, 0, 64, 0
v210enc_8_mask: dd 255<<12
+icl_perm_y: ; vpermb does not set bytes to zero when the high bit is set
unlike pshufb
+%assign i 0
+%rep 8
+db -1,i+0,i+1,-1 , i+2,i+3,i+4,i+5
+%assign i i+6
+%endrep
+
+icl_perm_uv: ; vpermb does not set bytes to zero when the high bit is set
unlike pshufb
+%assign i 0
+%rep 4
+db i+0,i+1,i+32,i+33 , -1,i+2,i+3,-1 , i+34,i+35,i+4,i+5 , -1,i+36,i+37,-1
+%assign i i+6
+%endrep
+
+icl_perm_y_kmask: times 8 db 0b_0110
+icl_perm_uv_kmask: times 8 db 0b0110_
+
+icl_shift_y: times 10 dw 2,0,4
+ times 4 db 0 ; padding to 64 bytes
+icl_shift_uv: times 5 dw 0,2,4
+ times 2 db 0 ; padding to 32 bytes
+ times 5 dw 4,0,2
+ times 2 db 0 ; padding to 32 bytes
+
+v210enc_10_permd_y: dd 0,1,2,-1 , 3,4,5,-1
+v210enc_10_shufb_y: db -1,0,1,-1 , 2,3,4,5 , -1,6,7,-1 , 8,9,10,11
+v210enc_10_permd_uv: dd 0,1,4,5 , 1,2,5,6
+v210enc_10_shufb_uv: db 0,1, 8, 9 , -1,2,3,-1 , 10,11,4,5 , -1,12,13,-1
+ db 2,3,10,11 , -1,4,5,-1 , 12,13,6,7 , -1,14,15,-1
+
SECTION .text
%macro v210_planar_pack_10 0
@@ -113,6 +143,75 @@ INIT_YMM avx2
v210_planar_pack_10
%endif
+%macro v210_planar_pack_10_new 0
+
+cglobal v210_planar_pack_10, 5, 5, 8+2*notcpuflag(avx512icl), y, u, v, dst,
width
+lea yq, [yq+2*widthq]
+add uq, widthq
+add vq, widthq
+neg widthq
+
+%if cpuflag(avx512icl)
+movu m6, [icl_perm_y]
+movu m7, [icl_perm_uv]
+kmovq k1, [icl_perm_y_kmask]
+kmovq k2, [icl_perm_uv_kmask]
+%else
+movu m6, [v210enc_10_permd_y]
+VBROADCASTI128 m7, [v210enc_10_shufb_y]
+movu m8, [v210enc_10_permd_uv]
+movu m9, [v210enc_10_shufb_uv]
+%endif
+movu m2, [icl_shift_y]
+movu m3, [icl_shift_uv]
+VBROADCASTI128 m4, [v210_enc_min_10] ; only ymm sized
+VBROADCASTI128 m5, [v210_enc_max_10] ; only ymm sized
+
+.loop:
+movu m0, [yq + widthq*2]
+%if cpuflag(avx512icl)
+movu ym1, [uq + widthq*1]
+vinserti32x8 zm1, [vq + widthq*1], 1
+%else
+movu xm1, [uq + widthq*1]
+vinserti128 ym1, [vq + widthq*1], 1
+%endif
+CLIPW m0, m4, m5
+CLIPW m1, m4, m5
+
+vpsllvw m0, m2
+vpsllvw m1, m3
+%if cpuflag(avx512icl)
+vpermb m0{k1}{z}, m6, m0 ; make space for uv where the k-mask
sets to zero
+vpermb m1{k2}{z}, m7, m1 ; interleave uv and make space for y
where the k-mask sets to zero
+%else
+vpermd m0, m6, m0
+pshufb m0, m7
+vpermd m1, m8, m1
+pshufb m1, m9
+%endif
+por m0, m1
+
+movu [dstq], m0
+add dstq, mmsize
+add widthq, (mmsize*3)/8
+jl .loop
+RET
+
+%endmacro
+
+%if ARCH_X86_64
+%if HAVE_AVX512_EXTERNAL
+INIT_YMM avx512
+v210_planar_pack_10_new
+%endif
+%endif
+
+%if HAVE_AVX512ICL_EXTERNAL
+INIT_ZMM avx512icl
+v210_planar_pack_10_new
+%endif
+
%macro v210_planar_pack_8 0
; v210_planar_pack_8(const uint8_t *y, const uint8_t *u, const uint8_t *v,
uint8_t *dst, ptrdiff_t width)
diff --git a/libavcodec/x86/v210enc_init.c b/libavcodec/x86/v210enc_init.c
index 6e9f8c6e61..44f22ca7fe 100644
--- a/libavcodec/x86/v210enc_init.c
+++ b/libavcodec/x86/v210enc_init.c
@@ -37,6 +37,12 @@ void ff_v210_planar_pack_10_ssse3(const uint16_t *y, const
uint16_t *u,
void ff_v210_planar_pack_10_avx2(const uint16_t *y, const uint16_t *u,
const uint16_t *v, uint8_t *dst,
ptrdiff_t width);
+void ff_v210_planar_pack_10_avx512(const uint16_t *y, const uint16_t *u,
+ const uint16_t *v, uint8_t *dst,
+ ptrdiff_t width);
+void ff_v210_planar_pack_10_avx512icl(const uint16_t *y, const uint16_t *u,
+ const uint16_t *v, uint8_t *dst,
+ ptrdiff_t width);
av_cold void ff_v210enc_init_x86(V210EncContext *s)
{
@@ -60,10 +66,16 @@ av_cold void ff_v210enc_init_x86(V210EncContext *s)
if (EXTERNAL_AVX512(cpu_flags)) {
s->sample_factor_8 = 2;
s->pack_line_8 = ff_v210_planar_pack_8_avx512;
[FFmpeg-devel] [PATCH v2 2/5] avcodec/x86/v210enc: replace register use with named register
--- libavcodec/x86/v210enc.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm index afac238ede..c2ad3d72c0 100644 --- a/libavcodec/x86/v210enc.asm +++ b/libavcodec/x86/v210enc.asm @@ -62,7 +62,7 @@ SECTION .text ; v210_planar_pack_10(const uint16_t *y, const uint16_t *u, const uint16_t *v, uint8_t *dst, ptrdiff_t width) cglobal v210_planar_pack_10, 5, 5, 4+cpuflag(avx2), y, u, v, dst, width -lea r0, [yq+2*widthq] +lea yq, [yq+2*widthq] add uq, widthq add vq, widthq neg widthq -- 2.38.0 ___ 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] [PATCH v2 1/5] checkasm/v210enc: test the entire width of 10-bit planar input arrays
--- tests/checkasm/v210enc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/checkasm/v210enc.c b/tests/checkasm/v210enc.c index 9942e08137..9fb8321c25 100644 --- a/tests/checkasm/v210enc.c +++ b/tests/checkasm/v210enc.c @@ -72,8 +72,10 @@ randomize_buffers(mask); \ call_ref(y0 + y_offset, u0 + uv_offset, v0 + uv_offset, dst0, width); \ call_new(y1 + y_offset, u1 + uv_offset, v1 + uv_offset, dst1, width); \ -if (memcmp(y0, y1, BUF_SIZE) || memcmp(u0, u1, BUF_SIZE / 2) || \ -memcmp(v0, v1, BUF_SIZE / 2) || memcmp(dst0, dst1, width * 8 / 3)) \ +if (memcmp(y0, y1, BUF_SIZE * sizeof(type)) \ +|| memcmp(u0, u1, BUF_SIZE * sizeof(type) / 2) \ +|| memcmp(v0, v1, BUF_SIZE * sizeof(type) / 2) \ +|| memcmp(dst0, dst1, width * 8 / 3)) \ fail(); \ bench_new(y1 + y_offset, u1 + uv_offset, v1 + uv_offset, dst1, width); \ } \ -- 2.38.0 ___ 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] [PATCH] libavcodec/qsvenc: enable Hyper Encode
0001-libavcodec-qsvenc-enable-Hyper-Encode.patch Description: 0001-libavcodec-qsvenc-enable-Hyper-Encode.patch ___ 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] [PATCH] avutil/tx: Use proper deallocator
May fix the FATE failures on x64 Windows here: https://fate.ffmpeg.org/report.cgi?slot=x86_64-msvc17-windows-native=20221125130443 Signed-off-by: Andreas Rheinhardt --- libavutil/tx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/tx.c b/libavutil/tx.c index c692239656..e25abf998f 100644 --- a/libavutil/tx.c +++ b/libavutil/tx.c @@ -857,7 +857,7 @@ av_cold int ff_tx_init_subtx(AVTXContext *s, enum AVTXType type, for (int i = 0; i < len; i++) sctx->map[tmp[i]] = i; -free(tmp); +av_free(tmp); } s->nb_sub++; -- 2.34.1 ___ 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] avcodec/pngdec: Mark damaged frames as finished
On 11/25/22, Andreas Rheinhardt wrote:
> Fixes the deadlock reported in ticket #10071.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/pngdec.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 8080094d65..f1cad26c52 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -1362,8 +1362,10 @@ exit_loop:
> return 0;
> }
>
> -if (percent_missing(s) > avctx->discard_damaged_percentage)
> -return AVERROR_INVALIDDATA;
> +if (percent_missing(s) > avctx->discard_damaged_percentage) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
>
> if (s->bits_per_pixel <= 4)
> handle_small_bpp(s, p);
> --
> 2.34.1
>
ok
> ___
> 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 1/2] avcodec/pictordec: Check that the image fits in the input
Quoting Michael Niedermayer (2022-11-25 14:38:46) > t On Fri, Nov 25, 2022 at 05:45:29PM +1100, Peter Ross wrote: > > On Tue, Nov 22, 2022 at 11:56:51PM +0100, Michael Niedermayer wrote: > > > Fixes: Timeout > > > Fixes: > > > 53438/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-5458939919859712 > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpe > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavcodec/pictordec.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/libavcodec/pictordec.c b/libavcodec/pictordec.c > > > index 71bad40a0a..09229b94fd 100644 > > > --- a/libavcodec/pictordec.c > > > +++ b/libavcodec/pictordec.c > > > @@ -162,6 +162,9 @@ static int decode_frame(AVCodecContext *avctx, > > > AVFrame *frame, > > > > > > if (av_image_check_size(s->width, s->height, 0, avctx) < 0) > > > return -1; > > > +if (bytestream2_get_bytes_left(>g) < s->width * s->height / 65536 > > > * 5) > > > +return AVERROR_INVALIDDATA; > > > > how did you arrive at this formula? > > There are 2 coding modes, RLE and RAW > I assume usable raw images will need around W*H and thus more than RLE > RLE codes the most compressed runs by > 1 byte for val (=marker) > 1 byte run (=0) > 2 bytes run > 1 byte val > thats 5 bytes and the maximum run we can code is 65535 > > The RLE decoder loop exits before applying the last RLE run and then > there is a seperate piece of code after it that fills the last color to > the end. Iam not sure why its done like that way but if i remove that > mid exit the seperate code piece becomes unused for all images i have > so it seems all RLE images are always fully coded with no special case > at the end. > Based on this iam guesing that my formula is correct for undamaged images > but of course i could find one tomorrow that exploits the special end > handling and breaks this formula > and of course its very possible that i missed some other thing that changes > this limit This should be written in a comment above the code then, otherwise all future readers will be completely clueless. -- Anton Khirnov ___ 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] lavc/qsvenc_h264: don't support P010 format
Why? -- Anton Khirnov ___ 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/2] avcodec/pictordec: Check that the image fits in the input
t On Fri, Nov 25, 2022 at 05:45:29PM +1100, Peter Ross wrote: > On Tue, Nov 22, 2022 at 11:56:51PM +0100, Michael Niedermayer wrote: > > Fixes: Timeout > > Fixes: > > 53438/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-5458939919859712 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpe > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/pictordec.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavcodec/pictordec.c b/libavcodec/pictordec.c > > index 71bad40a0a..09229b94fd 100644 > > --- a/libavcodec/pictordec.c > > +++ b/libavcodec/pictordec.c > > @@ -162,6 +162,9 @@ static int decode_frame(AVCodecContext *avctx, AVFrame > > *frame, > > > > if (av_image_check_size(s->width, s->height, 0, avctx) < 0) > > return -1; > > +if (bytestream2_get_bytes_left(>g) < s->width * s->height / 65536 * > > 5) > > +return AVERROR_INVALIDDATA; > > how did you arrive at this formula? There are 2 coding modes, RLE and RAW I assume usable raw images will need around W*H and thus more than RLE RLE codes the most compressed runs by 1 byte for val (=marker) 1 byte run (=0) 2 bytes run 1 byte val thats 5 bytes and the maximum run we can code is 65535 The RLE decoder loop exits before applying the last RLE run and then there is a seperate piece of code after it that fills the last color to the end. Iam not sure why its done like that way but if i remove that mid exit the seperate code piece becomes unused for all images i have so it seems all RLE images are always fully coded with no special case at the end. Based on this iam guesing that my formula is correct for undamaged images but of course i could find one tomorrow that exploits the special end handling and breaks this formula and of course its very possible that i missed some other thing that changes this limit thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf 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".
[FFmpeg-devel] [PATCH] avcodec/pngdec: Mark damaged frames as finished
Fixes the deadlock reported in ticket #10071.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/pngdec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 8080094d65..f1cad26c52 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1362,8 +1362,10 @@ exit_loop:
return 0;
}
-if (percent_missing(s) > avctx->discard_damaged_percentage)
-return AVERROR_INVALIDDATA;
+if (percent_missing(s) > avctx->discard_damaged_percentage) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
if (s->bits_per_pixel <= 4)
handle_small_bpp(s, p);
--
2.34.1
___
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 23/31] avformat/wtvenc: use av_dict_iterate
Marvin Scholz:
> ---
> libavformat/wtvenc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/wtvenc.c b/libavformat/wtvenc.c
> index 7e28b2082e..977e16c5a4 100644
> --- a/libavformat/wtvenc.c
> +++ b/libavformat/wtvenc.c
> @@ -670,12 +670,12 @@ static void write_table_entries_attrib(AVFormatContext
> *s)
> {
> WtvContext *wctx = s->priv_data;
> AVIOContext *pb = s->pb;
> -AVDictionaryEntry *tag = 0;
> +const AVDictionaryEntry *tag = 0;
>
> ff_standardize_creation_time(s);
> //FIXME: translate special tags (e.g. WM/Bitrate) to binary
> representation
> ff_metadata_conv(>metadata, ff_asf_metadata_conv, NULL);
> -while ((tag = av_dict_get(s->metadata, "", tag, AV_DICT_IGNORE_SUFFIX)))
> +while ((tag = av_dict_iterate(s->metadata, tag)))
> write_tag(pb, tag->key, tag->value);
>
> if (wctx->thumbnail.size) {
> @@ -698,11 +698,11 @@ static void
> write_table_redirector_legacy_attrib(AVFormatContext *s)
> {
> WtvContext *wctx = s->priv_data;
> AVIOContext *pb = s->pb;
> -AVDictionaryEntry *tag = 0;
> +const AVDictionaryEntry *tag = 0;
> int64_t pos = 0;
>
> //FIXME: translate special tags to binary representation
> -while ((tag = av_dict_get(s->metadata, "", tag, AV_DICT_IGNORE_SUFFIX)))
> {
> +while ((tag = av_dict_iterate(s->metadata, tag))) {
> avio_wl64(pb, pos);
> pos += metadata_header_size(tag->key) + strlen(tag->value)*2 + 2;
> }
We typically use NULL for NULL pointers.
- Andreas
___
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 07/31] avutil: use av_dict_iterate
Marvin Scholz:
> ---
> libavutil/opt.c| 12 ++--
> libavutil/tests/dict.c | 10 +-
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index a3940f47fb..0a909a8b22 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -1742,14 +1742,14 @@ void av_opt_free(void *obj)
>
> int av_opt_set_dict2(void *obj, AVDictionary **options, int search_flags)
> {
> -AVDictionaryEntry *t = NULL;
> +const AVDictionaryEntry *t = NULL;
> AVDictionary*tmp = NULL;
> int ret;
>
> if (!options)
> return 0;
>
> -while ((t = av_dict_get(*options, "", t, AV_DICT_IGNORE_SUFFIX))) {
> +while ((t = av_dict_iterate(*options, t))) {
> ret = av_opt_set(obj, t->key, t->value, search_flags);
> if (ret == AVERROR_OPTION_NOT_FOUND)
> ret = av_dict_set(, t->key, t->value, 0);
> @@ -2137,16 +2137,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
> case AV_OPT_TYPE_DICT: {
> AVDictionary *dict1 = NULL;
> AVDictionary *dict2 = *(AVDictionary **)dst;
> -AVDictionaryEntry *en1 = NULL;
> -AVDictionaryEntry *en2 = NULL;
> +const AVDictionaryEntry *en1 = NULL;
> +const AVDictionaryEntry *en2 = NULL;
> ret = av_dict_parse_string(, o->default_val.str, "=", ":", 0);
> if (ret < 0) {
> av_dict_free();
> return ret;
> }
> do {
> -en1 = av_dict_get(dict1, "", en1, AV_DICT_IGNORE_SUFFIX);
> -en2 = av_dict_get(dict2, "", en2, AV_DICT_IGNORE_SUFFIX);
> +en1 = av_dict_iterate(dict1, en1);
> +en2 = av_dict_iterate(dict2, en2);
> } while (en1 && en2 && !strcmp(en1->key, en2->key) &&
> !strcmp(en1->value, en2->value));
> av_dict_free();
> return (!en1 && !en2);
> diff --git a/libavutil/tests/dict.c b/libavutil/tests/dict.c
> index d053545f4d..8c05752ea7 100644
> --- a/libavutil/tests/dict.c
> +++ b/libavutil/tests/dict.c
> @@ -22,8 +22,8 @@
>
> static void print_dict(const AVDictionary *m)
> {
> -AVDictionaryEntry *t = NULL;
> -while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX)))
> +const AVDictionaryEntry *t = NULL;
> +while ((t = av_dict_iterate(m, t)))
> printf("%s %s ", t->key, t->value);
> printf("\n");
> }
> @@ -94,7 +94,7 @@ int main(void)
> if (av_dict_get(dict, NULL, NULL, 0))
> printf("av_dict_get() does not correctly handle NULL key.\n");
> e = NULL;
> -while ((e = av_dict_get(dict, "", e, AV_DICT_IGNORE_SUFFIX)))
> +while ((e = av_dict_iterate(dict, e)))
> printf("%s %s\n", e->key, e->value);
> av_dict_free();
>
> @@ -106,7 +106,7 @@ int main(void)
> printf("av_dict_set does not correctly handle NULL key\n");
>
> e = NULL;
> -while ((e = av_dict_get(dict, "", e, AV_DICT_IGNORE_SUFFIX)))
> +while ((e = av_dict_iterate(dict, e)))
> printf("'%s' '%s'\n", e->key, e->value);
> av_dict_free();
>
> @@ -122,7 +122,7 @@ int main(void)
> av_dict_set_int(, "12", 1, 0);
> av_dict_set_int(, "12", 2, AV_DICT_APPEND);
> e = NULL;
> -while ((e = av_dict_get(dict, "", e, AV_DICT_IGNORE_SUFFIX)))
> +while ((e = av_dict_iterate(dict, e)))
> printf("%s %s\n", e->key, e->value);
> av_dict_free();
>
This stops testing the old iterating pattern; instead it should
explicitly test that both patterns coincide.
- Andreas
___
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 02/31] fftools: use av_dict_get_string
Marvin Scholz:
> Instead of manually assembling the string, use av_dict_get_string
> which handles things like proper escaping too (even though it is
> not yet needed here).
> ---
> fftools/ffmpeg_filter.c | 31 +--
> 1 file changed, 13 insertions(+), 18 deletions(-)
>
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index b0c4c8ece3..29794fdc85 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -972,7 +972,7 @@ int configure_filtergraph(FilterGraph *fg)
>
> if (simple) {
> OutputStream *ost = fg->outputs[0]->ost;
> -char args[512];
> +char *args = NULL;
> const AVDictionaryEntry *e = NULL;
>
> if (filter_nbthreads) {
> @@ -985,26 +985,21 @@ int configure_filtergraph(FilterGraph *fg)
> av_opt_set(fg->graph, "threads", e->value, 0);
> }
>
> -args[0] = 0;
> -e = NULL;
> -while ((e = av_dict_get(ost->sws_dict, "", e,
> -AV_DICT_IGNORE_SUFFIX))) {
> -av_strlcatf(args, sizeof(args), "%s=%s:", e->key, e->value);
> -}
> -if (strlen(args)) {
> -args[strlen(args)-1] = 0;
> -fg->graph->scale_sws_opts = av_strdup(args);
> +if (av_dict_count(ost->sws_dict)) {
> +ret = av_dict_get_string(ost->sws_dict, , '=', ':');
> +if (ret < 0)
> +goto fail;
> +fg->graph->scale_sws_opts = args;
> +args = NULL;
It would be cleaner if you used a smaller scope for args (here and
below); or maybe just eliminate this variable here entirely by using
>graph->scale_sws_opts as destination for av_dict_get_string()?
> }
>
> -args[0] = 0;
> -e = NULL;
> -while ((e = av_dict_get(ost->swr_opts, "", e,
> -AV_DICT_IGNORE_SUFFIX))) {
> -av_strlcatf(args, sizeof(args), "%s=%s:", e->key, e->value);
> +if (av_dict_count(ost->swr_opts)) {
> +ret = av_dict_get_string(ost->swr_opts, , '=', ':');
> +if (ret < 0)
> +goto fail;
> +av_opt_set(fg->graph, "aresample_swr_opts", args, 0);
> +free(args);
Wrong deallocator.
> }
> -if (strlen(args))
> -args[strlen(args)-1] = 0;
> -av_opt_set(fg->graph, "aresample_swr_opts", args, 0);
> } else {
> fg->graph->nb_threads = filter_complex_nbthreads;
> }
___
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]lavc/codec_desc: Mark V210 as lossy
On Thu, 24 Nov 2022 at 22:51, Carl Eugen Hoyos wrote: > Hi! > > Our V210 encoder limits the written values, so do not mark the codec > as lossless. > > Please comment, Carl Eugen > Technically true so this patch is fine. Kieran ___ 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".
