Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line artefacts in 1080p (HEVC, German DVB-T2) in window mode #94

Closed
mighty-p opened this issue Mar 11, 2018 · 4 comments
Closed

Line artefacts in 1080p (HEVC, German DVB-T2) in window mode #94

mighty-p opened this issue Mar 11, 2018 · 4 comments

Comments

@mighty-p
Copy link

I detected another issue that was not present for me with the old softhddevice/pesintta code before the rename to vaapidevice.

For DVB-T2 channels which are broadcast here in HEVC with 1080p resolution, in windowed mode, there are line artefacts in the picture. They disappear in fullscreen. Also in windowed mode, when I resize the window, sometimes they appear, sometimes they disappear (until I resize again the window). The problem does not happen with channels in other resolutions such as 1080i, 720p or SDTV. Only 1080p seems affected.

vaapidevice-artefacts-in-1080phevc

@9000h
Copy link
Contributor

9000h commented Mar 11, 2018

I do have not seen that here, could be the mix of software you have.
I suggest to use a really new "pre 3.5 ffmpeg" version.

@mighty-p
Copy link
Author

mighty-p commented Mar 11, 2018

I now also tried the latest ffmpeg snapshot (from http://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2). With this, the problem here is gone, but in turn, the image is not scaled anymore (i.e. in windowed mode, I only see the upper left extract of the 1080p image). I believe with that ffmpeg version, simply no post-processing happens for this resolution/codec, which triggers again the issue that apparently current vaapidevice does not apply scaling when no post-processing happens (see #86).

@mighty-p
Copy link
Author

Since the original issue is only reproducible with ffmpeg 3.4.2, but not with 3.3.2 and also not with current snapshot, I will close this issue here. It seems to be an ffmpeg issue.

@9000h
Copy link
Contributor

9000h commented Mar 11, 2018

as long as there is no known workaround ffmpeg 3.4.2 should be avoided :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants