- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am developing screen capture App using QSV and ffmpeg
My app create MP4(h.264) file well,
but when I play Mp4 file..the result is bad .. like below
Did I do something wrong or setup up Encoding parameters , VPP parameters badly?
Anyone help me please..
Here is Result of System Analyzer
=================================================================
Intel(R) Media Server Studio 2016 R2 - System Analyzer (64-bit)
The following versions of Media SDK API are supported by platform/driver
[opportunistic detection of MSDK API > 1.19]:
Version Target Supported Dec Enc
1.0 HW Yes X X
1.0 SW Yes X X
1.1 HW Yes X X
1.1 SW Yes X X
1.2 HW Yes X X
1.2 SW Yes X X
1.3 HW Yes X X
1.3 SW Yes X X
1.4 HW Yes X X
1.4 SW Yes X X
1.5 HW Yes X X
1.5 SW Yes X X
1.6 HW Yes X X
1.6 SW Yes X X
1.7 HW Yes X X
1.7 SW Yes X X
1.8 HW Yes X X
1.8 SW Yes X X
1.9 HW Yes X X
1.9 SW Yes X X
1.10 HW Yes X X
1.10 SW Yes X X
1.11 HW Yes X X
1.11 SW Yes X X
1.12 HW Yes X X
1.12 SW Yes X X
1.13 HW Yes X X
1.13 SW Yes X X
1.14 HW Yes X X
1.14 SW Yes X X
1.15 HW Yes X X
1.15 SW Yes X X
1.16 HW Yes X X
1.16 SW Yes X X
1.17 HW Yes X X
1.17 SW Yes X X
1.18 HW Yes X X
1.18 SW Yes X X
1.19 HW Yes X X
1.19 SW Yes X X
Graphics Devices:
Name Version State
Intel(R) HD Graphics 530 20.19.15.4483 Active
NVIDIA Quadro M2000M 21.21.13.7699 Active
System info:
CPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
OS: Microsoft Windows 10 Pro
Arch: 64-bit
Installed Media SDK packages (be patient...processing takes some time):
Intel(R) Media SDK 2016 R2
Installed Media SDK DirectShow filters:
Installed Intel Media Foundation Transforms:
Intel(R) Hardware M-JPEG Decoder MFT : {00C69F81-0524-48C0-A353-4DD9D54F9A6E}
Intel(R) Hardware VP8 Sync Decoder MFT : {451E3CB7-2622-4BA5-8E1D-44B3C41D0924}
Intel(R) Hardware VP8 Decoder MFT : {6D856398-834E-4A89-8EE5-071BB3F58BE4}
Intel(R) Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF471}
Intel(R) Hardware H265 Encoder MFT : {BC10864D-2B34-408F-912A-102B1B867B6C}
Analysis complete... [press ENTER]
==================================================================================
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kim,
How can i fix this problem on 6th Intel CPU fundamentally??
I am not sure but I feel its ok to have different pitch value on different hardware/driver. We just need to be careful while copying frames between buffers using pitch value.
Let me know how you are copying raw frames into vpp buffer. Are you copying complete frame in one go (like doing memcpy of full buffer in a single call) or are you copying frames row by row (one row in a single memcpy call)?
If you are doing single memcpy of complete buffer in one call then it is wrong. Do row by row memcpy using source and destination pitch.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kim,
By seeing your output image, it looks like you are using incorrect width of capture frames.
What is your screen resolution? Make sure you are using pitch value correctly when processing raw frame buffer for encoding.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for replay Ramashankar.
I am using 1920 x 1080 and wondering how can I fix pitch value?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In addition,
When I debug , Figured out that row pitch of real image(raw frame) is 7680 (1920 * 4)
but, pmfxSurfacesVPPIn[nVPPSurfIdx]->Data.Pitch value is "7808"
Is it skylake driver bug?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kim,
Is it skylake driver bug?
It may or may not be a bug, but one thing for sure is that you need to copy your raw frame in vpp surface by using source pitch as 7680 and destination pitch as 7808, that is after copying 7680 bytes, move your source buffer by 7680 and destination buffer by 7808. It should solve your issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Ramashankar!
I debugged with same source on my LaptopPC(4th intel CPU)
the result is that row pitch of real image(raw frame) is 7680
and pmfxSurfacesVPPIn[nVPPSurfIdx]->Data.Pitch value is 7680 as well.
output mp4 file is working well!
what is diffrence between 4th Intel CPU and 6th Intel CPU???
As you said pitch value may be a cause..
How can i fix this problem on 6th Intel CPU fundamentally??
P.S Actually I get pitch value by using IDirect3DSurface9::LockRect method.. it returns pitch value "7808"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kim,
How can i fix this problem on 6th Intel CPU fundamentally??
I am not sure but I feel its ok to have different pitch value on different hardware/driver. We just need to be careful while copying frames between buffers using pitch value.
Let me know how you are copying raw frames into vpp buffer. Are you copying complete frame in one go (like doing memcpy of full buffer in a single call) or are you copying frames row by row (one row in a single memcpy call)?
If you are doing single memcpy of complete buffer in one call then it is wrong. Do row by row memcpy using source and destination pitch.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ramashankar,
I found that I am not using pitch value But, just using frame copy like..
"memcpy(pSurface->Data.B, fSource, h * w * 4)"
this function is called just before encoding..
and I checked raw data after memcpy()
for example..
=======================================================
memcpy(pSurface->Data.B, fSource, h * w * 4);
bmp file is fine...
after that it called runFrameVPPAsync method...and I can't debug anymore..because it's library method..
Thx for your reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ramashankar,
Yes..you are right
I have to data copy row by row
Finally, I resolved this problem !!
Thank you very much and Happy new year!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kim,
Great to hear that your issue is resolved.
As a general practice, always do raw frame buffer copy row by row using source and destination pitch value. It will work on all hardware/devices/driver, inspite of any pitch value.
Happy New Year to you too :)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page