From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 105277] ffmpeg using radeonsi vaapi on Polaris21 RX560 creates
h264 steams not playable by gstreamer & hw players
Date: Tue, 27 Feb 2018 20:20:04 +0000
Message-ID:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1450459529=="
Return-path:
Received: from culpepper.freedesktop.org (culpepper.freedesktop.org
[131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id C29196E078
for ; Tue, 27 Feb 2018 20:20:04 +0000 (UTC)
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============1450459529==
Content-Type: multipart/alternative; boundary="15197628040.f001.28556"
Content-Transfer-Encoding: 7bit
--15197628040.f001.28556
Date: Tue, 27 Feb 2018 20:20:04 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
https://bugs.freedesktop.org/show_bug.cgi?id=3D105277
Bug ID: 105277
Summary: ffmpeg using radeonsi vaapi on Polaris21 RX560 creates
h264 steams not playable by gstreamer & hw players
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel@lists.freedesktop.org
Reporter: hojuruku@gmail.com
QA Contact: dri-devel@lists.freedesktop.org
Created attachment 137664
--> https://bugs.freedesktop.org/attachment.cgi?id=3D137664&action=3Dedit
Royalty free big buck bunny 30 second video file corrupted by mesa-git ;)
This ticket relates to a comment on a closed bug:
https://bugs.freedesktop.org/show_bug.cgi?id=3D104920#c3
Hardware required to replicate: RX560,
sys-kernel/linux-firmware-20180213::gentoo, ATOM BIOS: 113-C98121-M01,
amd-staging latest kernel & mesa-git.
There is some corruption when creating mkv,mp4 or any container in
ffmpeg/ffmpeg-git using vaapi to encode. When I used libx264 with exactly t=
he
same settings as the encoder (no bframes, constrained baseline etc) the con=
tent
is playable on hardware players and gstreamer, however when vaapi is used to
use the encoding the content is scrambled on hardware players (TCL TV) and
gstreamer's qtdemux can not parse the stream. vlc's player always skips the
first two frames too.
The error exists regardless of the scale filter, I was originally testing on
much higher bitrate source material.
Sample video file used:
https://download.blender.org/peach/bigbuckbunny_movies/
What works with gstreamer/totem & hw players (x264 not relating to mesa)
ffmpeg-git -hwaccel vaapi -hwaccel_output_format vaapi -t 30 -i
big_buck_bunny_720p_surround.avi -vf
scale_vaapi=3Dw=3D1366:h=3D768,hwdownload,format=3Dnv12 -c:v libx264 -b:v 2=
000k
-coder:v 0 -bf 0 -profile:v baseline -level 3.1 -c:a aac -ac 2 -b:a 128k -ar
48000 -movflags +faststart -x264-params opencl x264test.mp4
What doesn't:
ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -t 30 -i big_buck_bunny_720p_surround.avi -vf
scale_vaapi=3Dw=3D1366:h=3D768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -pro=
file:v
constrained_baseline -movflags +faststart -quality:v 0 -level:v 3.1 -coder:v
cavlc -c:a aac -ab 128k -ar 48000 -ac 2 vaapitest.mp4
Comparing the output of ffprobe -show_format -show_streams shows the files =
are
nearly identical.
diff x264test.txt vaapitest.txt=20
27,28c27,28
< is_avc=3Dtrue
< nal_length_size=3D4
---
> is_avc=3Dfalse
> nal_length_size=3D0
37c37
< bit_rate=3D2142956
---
> bit_rate=3D2153505
102c102
< filename=3Dx264test.mp4
---
> filename=3Dvaapitest.mp4
109,110c109,110
< size=3D8535782
< bit_rate=3D2274540
---
> size=3D8575301
> bit_rate=3D2285071
I am using amd-gpu-staging-next from 2 days ago 4.15-rc4 after the old
powerplay cleanup commit, and mesa-git from today.
--=20
You are receiving this mail because:
You are the assignee for the bug.=
--15197628040.f001.28556
Date: Tue, 27 Feb 2018 20:20:04 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated
| Bug ID |
105277
|
| Summary |
ffmpeg using radeonsi vaapi on Polaris21 RX560 creates h264 s=
teams not playable by gstreamer & hw players
|
| Product |
Mesa
|
| Version |
git
|
| Hardware |
Other
|
| OS |
All
|
| Status |
NEW
|
| Severity |
normal
|
| Priority |
medium
|
| Component |
Drivers/Gallium/radeonsi
|
| Assignee |
dri-devel@lists.freedesktop.org
|
| Reporter |
hojuruku@gmail.com
|
| QA Contact |
dri-devel@lists.freedesktop.org
|
Created attachment 137664 [details]
Royalty free big buck bunny 30 second video file corrupted by mesa-git ;)
This ticket relates to a comment on a closed bug:
https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D104920#c3
Hardware required to replicate: RX560,
sys-kernel/linux-firmware-20180213::gentoo, ATOM BIOS: 113-C98121-M01,
amd-staging latest kernel & mesa-git.
There is some corruption when creating mkv,mp4 or any container in
ffmpeg/ffmpeg-git using vaapi to encode. When I used libx264 with exactly t=
he
same settings as the encoder (no bframes, constrained baseline etc) the con=
tent
is playable on hardware players and gstreamer, however when vaapi is used to
use the encoding the content is scrambled on hardware players (TCL TV) and
gstreamer's qtdemux can not parse the stream. vlc's player always skips the
first two frames too.
The error exists regardless of the scale filter, I was originally testing on
much higher bitrate source material.
Sample video file used:
https:/=
/download.blender.org/peach/bigbuckbunny_movies/
What works with gstreamer/totem & hw players (x264 not relating to mesa)
ffmpeg-git -hwaccel vaapi -hwaccel_output_format vaapi -t 30 -i
big_buck_bunny_720p_surround.avi -vf
scale_vaapi=3Dw=3D1366:h=3D768,hwdownload,format=3Dnv12 -c:v libx264 -b:v 2=
000k
-coder:v 0 -bf 0 -profile:v baseline -level 3.1 -c:a aac -ac 2 -b:a 128k -ar
48000 -movflags +faststart -x264-params opencl x264test.mp4
What doesn't:
ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -t 30 -i big_buck_bunny_720p_surround.avi -vf
scale_vaapi=3Dw=3D1366:h=3D768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -pro=
file:v
constrained_baseline -movflags +faststart -quality:v 0 -level:v 3.1 -coder:v
cavlc -c:a aac -ab 128k -ar 48000 -ac 2 vaapitest.mp4
Comparing the output of ffprobe -show_format -show_streams shows the files =
are
nearly identical.
diff x264test.txt vaapitest.txt=20
27,28c27,28
< is_avc=3Dtrue
< nal_length_size=3D4
---
> is_avc=3Dfalse
> nal_length_size=3D0
37c37
< bit_rate=3D2142956
---
> bit_rate=3D2153505
102c102
< filename=3Dx264test.mp4
---
> filename=3Dvaapitest.mp4
109,110c109,110
< size=3D8535782
< bit_rate=3D2274540
---
> size=3D8575301
> bit_rate=3D2285071
I am using amd-gpu-staging-next from 2 days ago 4.15-rc4 after the old
powerplay cleanup commit, and mesa-git from today.
You are receiving this mail because:
- You are the assignee for the bug.
=
--15197628040.f001.28556--
--===============1450459529==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==
--===============1450459529==--