Opened 3 years ago
Last modified 16 months ago
#2051 reopened enhancement
nvenc produces invalid stream
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | critical | Milestone: | 2.5 |
Component: | encodings | Version: | 4.0.x |
Keywords: | Cc: | m.j.lbach@… |
Description
Fairly easy to reproduce with glxgears
.
This could be caused by some of the recent changes to the heuristics or maybe to nvenc itself:
- nvenc changelog
- r21050 damage events accounting
- r21047 region merging code changes
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)
Attachments (3)
Change History (11)
comment:1 Changed 3 years ago by
Status: | new → assigned |
---|
comment:2 Changed 3 years ago by
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.
comment:3 Changed 3 years ago by
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.
comment:4 Changed 3 years ago by
Priority: | major → critical |
---|
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:
- disable h265 with nvenc (looks like this does not occur with h264)- easy
- make sure that nvenc always includes a picture - not sure how, maybe we need to turn off b-frames (support added recently apparently) or detect when they're used and add the "delayed" tag
- clean up the patch an continue when the data is missing..
comment:5 Changed 3 years ago by
comment:6 Changed 3 years ago by
Resolution: | → needinfo |
---|---|
Status: | assigned → closed |
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.
comment:7 Changed 2 years ago by
Cc: | m.j.lbach@… added |
---|---|
Resolution: | needinfo |
Status: | closed → reopened |
Version: | 2.4.x → 4.0.x |
I can reproduce this bug with glxgears on an Ubuntu 18.04 host/macOS client
Changed 2 years ago by
Attachment: | xpra_info.txt added |
---|
Changed 2 years ago by
Attachment: | xpra_bug.txt added |
---|
comment:8 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2051
Here's what the client shows (seen with both h264 and h265 streams):
Sometimes with much higher frame numbers.