From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_h264: don't support P010 format
Date: Fri, 25 Nov 2022 23:35:32 -0300
Message-ID: <aad88d44-870c-b248-54b7-87213605faef@gmail.com> (raw)
In-Reply-To: <DM8P223MB0365E772BCEAE1FC6DCF92D6BA119@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
On 11/25/2022 11:31 PM, Soft Works wrote:
>
>
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> 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 <ffmpeg-devel-bounces@ffmpeg.org> 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 <ffmpeg-devel-bounces@ffmpeg.org> 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 @ 000001dc301aeec0] w:3840 h:2160 pixfmt:yuv420p10le tb:1/60000 fr:60000/1001 sar:1/1
> [auto_scale_0 @ 000001dc2362a700] w:iw h:ih flags:'' interl:0
> [hwupload@f1 @ 000001dc2944ef00] 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 @ 000001dc2362a700] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x0
> [AVHWDeviceContext @ 000001dc444f9a00] D3D11 Init
> [AVHWDeviceContext @ 000001dc444fab80] D3D11 Init
> [vpp_qsv@f2 @ 000001dc22a3d880] VPP: input is video memory surface
> [vpp_qsv@f2 @ 000001dc22a3d880] VPP: output is video memory surface
> [auto_scale_0 @ 000001dc2362a700] 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 @ 000001dc161b6040] Using input frames context (format qsv) with h264_qsv encoder.
> [h264_qsv @ 000001dc161b6040] Encoder: input is video memory surface
> [h264_qsv @ 000001dc161b6040] Using the average variable bitrate (AVBR) ratecontrol method
> [h264_qsv @ 000001dc161b6040] Current pixel format is unsupported
> [h264_qsv @ 000001dc161b6040] 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 @ 000001dc444f9a00] D3D11 Uninit
> [AVIOContext @ 000001dc16197c80] Statistics: 0 bytes written, 0 seeks, 0 writeouts
> [AVHWDeviceContext @ 000001dc444fab80] D3D11 Uninit
> [AVIOContext @ 000001dc161839c0] Statistics: 131146 bytes read, 2 seeks
> Conversion failed!
>
>
> 2. 10bit from SW context:
>
>
> [graph 0 video input from stream 0:0 @ 0000019e915dee00] w:3840 h:2160 pixfmt:yuv420p10le tb:1/60000 fr:60000/1001 sar:1/1
> [auto_scale_0 @ 0000019ee99936c0] w:iw h:ih flags:'' interl:0
> [format @ 0000019ee9993240] auto-inserting filter 'auto_scale_0' between the filter 'Parsed_null_0' and the filter 'format'
> [auto_scale_0 @ 0000019ee99936c0] 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 @ 0000019ee9995dc0] Using device qd1 (type qsv) with h264_qsv encoder.
> [h264_qsv @ 0000019ee9995dc0] Encoder: input is system memory surface
> [h264_qsv @ 0000019ee9995dc0] Using the average variable bitrate (AVBR) ratecontrol method
> [h264_qsv @ 0000019ee9995dc0] Current pixel format is unsupported
> [h264_qsv @ 0000019ee9995dc0] 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 @ 0000019ef62b4000] Statistics: 0 bytes written, 0 seeks, 0 writeouts
> [AVIOContext @ 0000019ee995abc0] 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 unsupported, then.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2022-11-26 2:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-24 5:22 Xiang, Haihao
2022-11-25 13:45 ` Anton Khirnov
2022-11-25 18:03 ` Soft Works
2022-11-25 19:47 ` James Almer
2022-11-25 23:20 ` Soft Works
2022-11-25 23:25 ` James Almer
2022-11-25 23:26 ` Dong, Ruijing
2022-11-25 23:34 ` James Almer
2022-11-25 23:46 ` Dong, Ruijing
2022-11-25 23:51 ` Soft Works
2022-11-25 23:57 ` James Almer
2022-11-26 0:58 ` Soft Works
2022-11-26 1:00 ` James Almer
2022-11-26 2:31 ` Soft Works
2022-11-26 2:35 ` James Almer [this message]
2022-11-26 2:54 ` Soft Works
2022-11-28 1:57 ` Xiang, Haihao
2022-11-25 23:47 ` Soft Works
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aad88d44-870c-b248-54b7-87213605faef@gmail.com \
--to=jamrial@gmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git