[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 4013 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

            Bug ID: 98278
           Summary: Corrupted videos VA-API HW encoding radeonsi
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: neatnoise@gmail.com
        QA Contact: dri-devel@lists.freedesktop.org

Hello,

There is an issue in hardware encoding using radeonsi driver and VA-API. It
happens when 2 encoding software - gstreamer and avconf are used. Generated
output videos are corrupted, full of green and purple colors. There is no error
in the terminal output.

There is no problem in HW decoding, it generates valid output.
I've tried to use omx HW acceleration, but gstreamer couldn't even initialize
gst-omx plugin.

Generated video: https://www.youtube.com/watch?v=XJlWCdgB4Lc

gst command: LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 -e ximagesrc
display-name=:0 use-damage=0 startx=0 starty=0 endx=1919 endy=1079 ! multiqueue
! video/x-raw,format=BGRx,framerate=60/1 ! vaapipostproc format=i420 !
video/x-raw,format=I420,framerate=60/1 ! multiqueue ! vaapih264enc bitrate=3000
dct8x8=true ! h264parse ! multiqueue ! matroskamux name=muxer muxer. !
progressreport name=Rec_time ! filesink location=test.mp4

glxinfo:
OpenGL renderer string: Gallium 0.4 on AMD BONAIRE (DRM 2.46.0 / 4.8.1-1-ARCH,
LLVM 4.0.0)
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel
(git-b7d9677)

kernel driver: radeon

vainfo:
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

omx:
 Scanning directory /usr/lib/bellagio/

 Scanning library /usr/lib/bellagio/libomxclocksrc.so
Component OMX.st.clocksrc registered with 0 quality levels
  Specific role OMX.st.clocksrc registered

 Scanning library /usr/lib/bellagio/libomx_mesa.so
Component OMX.mesa.video_decoder registered with 0 quality levels
  Specific role OMX.mesa.video_decoder.mpeg2 registered
  Specific role OMX.mesa.video_decoder.avc registered
  Specific role OMX.mesa.video_decoder.hevc registered
Component OMX.mesa.video_encoder registered with 0 quality levels
  Specific role OMX.mesa.video_encoder.avc registered

 Scanning library /usr/lib/bellagio/libomxvideosched.so
Component OMX.st.video.scheduler registered with 2 quality levels
  Specific role OMX.st.video.scheduler registered

 Scanning library /usr/lib/bellagio/libomxaudio_effects.so
Component OMX.st.volume.component registered with 2 quality levels
  Specific role OMX.st.volume.component registered
Component OMX.st.audio.mixer registered with 1 quality levels
  Specific role OMX.st.audio.mixer registered

 6 OpenMAX IL ST static components in 4 libraries succesfully scanned

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 5440 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 553 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #1 from Tom <neatnoise@gmail.com> ---
mpv, vlc players show constant errors every .5 sec:

[ffmpeg/video] h264: illegal short term buffer state detected
V: 00:00:01 / 00:00:16 (10%) Dropped: 20
[ffmpeg/video] h264: illegal short term buffer state detected
V: 00:00:01 / 00:00:16 (10%) Dropped: 20
[ffmpeg/video] h264: illegal short term buffer state detected
V: 00:00:01 / 00:00:16 (10%) Dropped: 20

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1315 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 945 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #2 from Christoph Haag <haagch@frickel.club> ---
I'm just a user, so take this with a grain of salt, but I found that radeon
with vaapi only works with the nv12 color format and produces something broken
like this with i420.

The last time I tried it, vaapipostproc format=nv12 did not work, so I had to
do the color space conversion on the CPU with videoconvert.

Here is a pipeline that last worked for me:

gst-launch-1.0 ximagesrc display-name=:0 use-damage=0 startx=0 starty=0
endx=1919 endy=1079 ! videoconvert ! video/x-raw,framerate=60/1,format=NV12 !
vaapih264enc ! h264parse ! matroskamux ! filesink location=output.avi

Can't really test right now because it hangs my GPU, but I see it saves one
frame that has this vertically doubled image too, with correct colors though.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1718 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1058 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #3 from Tom <neatnoise@gmail.com> ---
(In reply to Christoph Haag from comment #2)
> I'm just a user, so take this with a grain of salt, but I found that radeon
> with vaapi only works with the nv12 color format and produces something
> broken like this with i420.
> 
> The last time I tried it, vaapipostproc format=nv12 did not work, so I had
> to do the color space conversion on the CPU with videoconvert.
> 
> Here is a pipeline that last worked for me:
> 
> gst-launch-1.0 ximagesrc display-name=:0 use-damage=0 startx=0 starty=0
> endx=1919 endy=1079 ! videoconvert ! video/x-raw,framerate=60/1,format=NV12
> ! vaapih264enc ! h264parse ! matroskamux ! filesink location=output.avi
> 
> Can't really test right now because it hangs my GPU, but I see it saves one
> frame that has this vertically doubled image too, with correct colors though.

Tested, it produces similar corrupted video.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1932 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 274 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #4 from Andy Furniss <adf.lists@gmail.com> ---
Since recentish mesa change you have to set the env

VAAPI_DISABLE_INTERLACE=1

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1045 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 381 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #5 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Andy Furniss from comment #4)
> Since recentish mesa change you have to set the env
> 
> VAAPI_DISABLE_INTERLACE=1

You will still need to feed the encoder NV12 as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 631 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #6 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Andy Furniss from comment #5)
> (In reply to Andy Furniss from comment #4)
> > Since recentish mesa change you have to set the env
> > 
> > VAAPI_DISABLE_INTERLACE=1
> 
> You will still need to feed the encoder NV12 as well.

Though I420 will work, it may be better to let gstreamer convert the BGRx as it
may be faster than letting the driver do it. The driver will just use C
gstreamer may (or may not) use SIMD.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1535 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #7 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Andy Furniss from comment #6)
> (In reply to Andy Furniss from comment #5)
> > (In reply to Andy Furniss from comment #4)
> > > Since recentish mesa change you have to set the env
> > > 
> > > VAAPI_DISABLE_INTERLACE=1
> > 
> > You will still need to feed the encoder NV12 as well.
> 
> Though I420 will work, it may be better to let gstreamer convert the BGRx as
> it may be faster than letting the driver do it. The driver will just use C
> gstreamer may (or may not) use SIMD.

LOL fail post, to clarify, the driver will not convert BGRx to anything (would
be a nice feature if the GPU could do it).

If you tell gstreamer to convert BGRx to I420 then the driver will just change
it to nv12 using CPU C code, so you may as well tell gstreamer to convert to 
NV12 in the first place.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1986 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 2018 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #8 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Tom from comment #1)
> mpv, vlc players show constant errors every .5 sec:
> 
> [ffmpeg/video] h264: illegal short term buffer state detected
> V: 00:00:01 / 00:00:16 (10%) Dropped: 20
> [ffmpeg/video] h264: illegal short term buffer state detected
> V: 00:00:01 / 00:00:16 (10%) Dropped: 20
> [ffmpeg/video] h264: illegal short term buffer state detected
> V: 00:00:01 / 00:00:16 (10%) Dropped: 20

If your gstreamer is the latest, they have changed the default profile from
baseline to high which tries to use b-frames, but they are not yet
supported/working.

I don't think dct8x8=true will do anything, though I could be wrong.

I notice your command used matroskamux, which is good, but you call the file
mp4 - it will likely ignpre that and make mkv. For screen recording with
gstreamer I would avoid mp4 as when you stop it it hasn't for me finalized
properly = unplayable file. Maybe I am just crap with gstreamer and control c
is not the best way to stop it!

Something like this should work, though 3Mbit will be way too low if much is
happening when recording recording 1080p60, cqp may be a better choice - but
then it will potentially use far more bits and everything may grind to a halt
(by default) when Linux does one of its all stopping flushes to disk (though
there are workarounds)

Pasted from notes, not intended to be better that anything else, just an
example - could/should be improved as needed (eg. how to use 709 for CSC as
players will tend to assume 1080p is 709.

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 endy=1079
! queue ! videoconvert ! video/x-raw,framerate=60/1,format=NV12  ! queue !
vaapih264enc rate-control=cbr bitrate=3000 ! video/x-h264,profile=baseline !
h264parse ! matroskamux ! filesink location=out.mkv

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2880 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 581 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #9 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Christoph Haag from comment #2)
> I'm just a user, so take this with a grain of salt, but I found that radeon
> with vaapi only works with the nv12 color format and produces something
> broken like this with i420.

There was a bug with I420 that reversed U and V, but that's fixed now - though
NV12 is still the format the enc needs so where you have a choice is best.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1428 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1046 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #10 from Tom <neatnoise@gmail.com> ---
(In reply to Andy Furniss from comment #9)
> (In reply to Christoph Haag from comment #2)
> > I'm just a user, so take this with a grain of salt, but I found that radeon
> > with vaapi only works with the nv12 color format and produces something
> > broken like this with i420.
> 
> There was a bug with I420 that reversed U and V, but that's fixed now -
> though NV12 is still the format the enc needs so where you have a choice is
> best.

Thank you Andy for explanation. After setting env var VAAPI_DISABLE_INTERLACE
video looks correctly. You're right about video format it should be mkv. I'll
experiment more with this and I'll try to get smoother motion in videos. In
metadata I can see that videos are 60 fps but for my eyes they look like 30
fps. Maybe X11 frames are not captured efficiently. Thank you again for help
with resolving it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1948 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 419 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

Tom <neatnoise@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1231 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1802 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #11 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Tom from comment #10)

> Thank you Andy for explanation. After setting env var
> VAAPI_DISABLE_INTERLACE video looks correctly. You're right about video
> format it should be mkv. I'll experiment more with this and I'll try to get
> smoother motion in videos. In metadata I can see that videos are 60 fps but
> for my eyes they look like 30 fps. Maybe X11 frames are not captured
> efficiently. Thank you again for help with resolving it.

The CPU X11 grabbing and NV12 conversion are quite expensive and single
threaded.

On my old Phenom II x4 3.4GHz CPUs forced to perf (cpufreq) I get about 69 fps
testing like -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 endy=1079
num-buffers=1000 ! queue ! videoconvert !
video/x-raw,framerate=100/1,format=NV12  ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:14.408948605

1000/14.408948605 = 69.4

You could extend the test to include encode to fakesink and see what you get.

I would try cqp (default 26) as well as cbr.

If you can do the first test OK but not with encode maybe start playing with
forcing GPU to high rather than auto.

Also omx may be a bit faster if you can get that to work - it should, what is
in your /etc/xdg/gstomx.conf?

omx doesn't work properly with cbr. You can control cqp as needed, plus
b-frames work with omx maybe "free" for bonaire (but will be x2 slower with
more recent GPUs than yours).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2732 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1972 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #12 from Christoph Haag <haagch@frickel.club> ---
Thanks for your tips, quite some new information for me.

I am using this pipeline now:
gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 startx=0 starty=0
endx=1919 endy=1079 ! multiqueue ! video/x-raw,format=BGRx,framerate=60/1 !
videoconvert ! video/x-raw,format=NV12,framerate=60/1 ! multiqueue !
vaapih264enc rate-control=cqp bitrate=5000 ! video/x-h264,profile=baseline !
h264parse ! multiqueue ! matroskamux name=muxer. ! progressreport name=Rec_time
! filesink location=output.mkv

This one runs nicely and doesn't cause GPU hangs.


Are we using this bug report to talk about omx too?

This is my equivalent omx pipeline:
gst-launch-1.0 -e ximagesrc display-name=:0 use-damage=0 startx=0 starty=0
endx=1919 endy=1079 ! multiqueue ! video/x-raw,format=BGRx,framerate=60/1 !
videoconvert ! video/x-raw,format=NV12,framerate=60/1 ! multiqueue ! omxh264enc
control-rate=2 target-bitrate=11000000 ! h264parse ! multiqueue ! matroskamux
name=muxer. ! progressreport name=Rec_time ! filesink location=output.mkv

omxregister-bellagio produces a broken ~/.omxregister for me, but it really
only needs to be a text file with two lines:

/usr/lib/bellagio/libomxvideosched.so
/usr/lib/bellagio/libomx_mesa.so

Sometimes (?) the gst-omx plugin is blacklisted. Check with gst-inspect-1.0 |
grep omx whether there is something. If not, delete
~/.cache/gstreamer-1.0/registry.x86_64.bin and try again.

That's all I know about reasons omx may not be working.


For the performance, there is a chance you're also affected by bug 97075. Try
running
vblank_mode=0 glxgears
and then starting the encoding. Make sure it's really not throttled to 60 fps.
Either it improves the performance of the hardware encoder a lot or it does
nothing.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2957 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 744 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #13 from Andy Furniss <adf.lists@gmail.com> ---
Good tips on OMX, in the past (maybe because I had gstomx.conf in the wrong
place) I've seen it randomly stop working because my browser tried to use
gstreamer.

For Christoph on Polaris10 you may sometime hit this dual instance issue with
vaapi -

https://bugs.freedesktop.org/show_bug.cgi?id=98005

I notice your first example above is slightly wrong should be cbr

rate-control=cqp bitrate=5000

While OMX may appear to work with cbr IME it doesn't work properly = you don't
end up getting the rate you asked for other than by luck.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1771 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 863 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #14 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Andy Furniss from comment #13)

> While OMX may appear to work with cbr IME it doesn't work properly = you
> don't end up getting the rate you asked for other than by luck.

While testing with just one sample is probably not the best thing - I just
revisited this and it does seem to work as long as bitrate isn't too high max
85M.

Though I have vague memories of thinking it was OK before and then it went
inconsistent.

It could be because OMX does less/different setup of the h/w compared to vaapi
WRT rate control/hrd stuff (I have see this by adding printfs) and when testing
vaapi and omx some stated get carried over between the two.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1761 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 760 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #15 from Andy Furniss <adf.lists@gmail.com> ---
(In reply to Andy Furniss from comment #14)

> While testing with just one sample is probably not the best thing - I just
> revisited this and it does seem to work as long as bitrate isn't too high
> max 85M.

It seems that cbr with omx doesn't work with dual instance (cards newer or =
TONGA). though the file sizes were OK up to a point the quality was terrible,
with corruption.

Maybe bonaire will be OK, but another difference between omx and vaapi is the
latter has cabac on (for me using TONGA). This is better, though you can hack
it on for omx.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1661 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98278] Corrupted videos VA-API HW encoding radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 651 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98278

--- Comment #16 from Tom <neatnoise@gmail.com> ---
I use AUR package in arch for gst-omx and it fails to initialize. I can see
that other people have the same problem. It is quite old package though
(2015-11-08). I think that I'd have to try get fresh source and compile it by
myself.

gst-inspect-1.0 /usr/lib/gstreamer-1.0/libgstomx.so
Could not load plugin file: File "/usr/lib/gstreamer-1.0/libgstomx.so" appears
to be a GStreamer plugin, but it failed to initialize

gst-omx 1.2.0-1  (2015-11-08 03:09)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1476 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel