Fairly easy to reproduce with glxgears
.
This could be caused by some of the recent changes to the heuristics or maybe to nvenc itself:
It would be nice to add a save-to-file feature to the video encoders. Then we can see if the stream is corrupt or not.
(SAVE_VIDEO_FRAMES
only records individual frames - which is also useful, for other use cases)
Here's what the client shows (seen with both h264 and h265 streams):
2018-11-20 21:30:45,463 client @13.635 Error: avcodec error decoding 9008 bytes of h265 data: 2018-11-20 21:30:45,464 client @13.635 'unknown format returned' 2018-11-20 21:30:45,464 client @13.635 frame 10 2018-11-20 21:30:45,464 client @13.636 decoder state: 2018-11-20 21:30:45,464 client @13.636 decoder_height = 320 2018-11-20 21:30:45,464 client @13.636 encoding = h265 2018-11-20 21:30:45,464 client @13.636 colorspace = YUV444P 2018-11-20 21:30:45,465 client @13.636 actual_colorspace = YUV444P 2018-11-20 21:30:45,465 client @13.636 height = 300 2018-11-20 21:30:45,465 client @13.636 decoder_width = 320 2018-11-20 21:30:45,465 client @13.636 width = 300 2018-11-20 21:30:45,465 client @13.637 version = 58, 18, 100 2018-11-20 21:30:45,465 client @13.637 formats = GBRP, RGB, YUV420P, BGRA, BGRX, ARGB, YUV422P, XRGB, YUV444P 2018-11-20 21:30:45,466 client @13.637 frames = 10 2018-11-20 21:30:45,467 client @13.637 type = avcodec 2018-11-20 21:30:45,467 client @13.637 Error: decode failed on 9008 bytes of h265 data 2018-11-20 21:30:45,467 client @13.637 300x300 pixels using avcodec 2018-11-20 21:30:45,467 client @13.638 frame options: 2018-11-20 21:30:45,467 client @13.638 quality=99 2018-11-20 21:30:45,468 client @13.638 encoding=h265 2018-11-20 21:30:45,468 client @13.638 pts=399 2018-11-20 21:30:45,468 client @13.638 frame=10 2018-11-20 21:30:45,468 client @13.638 csc=YUV444P 2018-11-20 21:30:45,468 client @13.638 speed=47
Sometimes with much higher frame numbers.
r21056 adds the ability to record video streams, ie:
XPRA_SAVE_VIDEO_STREAMS=1 xpra start ...
Playing back the streams with mplayer works fine, but does show some warnings for h265:
No pts value from demuxer to use for frame! pts after filters MISSING V:-9223372036854775808.0 0/ 0 ??% ??% ??,?% 0 0
Because those streams lack any container, ffmpeg is unable to play them.
The missing pts may be a red herring: some h264 streams I've generated also trigger the mplayer warnings but play back fine in the client.
It might be useful to save the codec metadata with the stream (possibly all in the filename?), so we can reproduce the problem with our decoder code, but without requiring the whole client. ie: a simple command line tool would only need the file + codec, window size, csc mode.
ignore missing picture
The real cause is probably missing picture in access unit
.
The patch above allows us to continue anyway by hacking the "options" dictionary and adding the "delayed" flag to it when we don't get any picture data from the decoder. Effectively ignoring the error and pretending we knew this would be a "delayed" frame.
Proper solutions:
Similar reports:
I can't reproduce this anymore.
If it happens again, we may want to add a way to export the nvenc encoder internal state as a client_options so we can then dump it when we encounter those broken frames.
I can reproduce this bug with glxgears on an Ubuntu 18.04 host/macOS client
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2051