Thanks a lot for chiming in, Richard :-)

On 11 May 2019 at 11:28, Richard Scobie wrote:

Frantisek Rysanek wrote:

...

50i). Maybe the VLC can somehow cope with that (perform rate conversion on the fly) but the vaapidevice plugin cannot. Maybe I should attach a TV as a second display and set the PC's HDMI frame refresh rate to 50 Hz.

I have not yet started down the vaapi path yet, (soon), but I believe you will need to set your display for 50Hz. See post #2 in this thread:

https://www.vdr-portal.de/forum/index.php?thread/132471-xserver-f%C3%BCr-vaa...

Will check that. Oh cool, that thread is stuffed with useful information. Und ich werde Deutsch mal wieder etwas üben. Anscheinend KLS selber hat mit demselben problem gekämpft :-) Meiner Weg wurde bereits beschritten.

...

Another issue is: how do I control the OSD on the vaapidevice output, if I only have a PC keyboard and mouse?

Keyboard control needs to be specified at compile time - on by default, see Make.config.template in the source package.

I have never used the keyboard, but I have assumed that when started for the first time, you are prompted for which keys you want mapped to which vdr function, when using a remote. Maybe this is not the case with the keyboard? See the "Remote Control Keys" entry in the command "man 5 vdr".

Thanks for the pointer. Yes, VDR, when started with vaapidevice, does ask me to press some keys on my remote to "detect the protocol". Except that I probably don't have a compatible remote for the mygica, or maybe the mygica "input device" in xinput does not count as a "LIRC remote", or I don't have lircd running, or its config is empty, or some such. Will need to check that. I can work on that later. The startup autodetector doesn't seem to respond to keyboard inputs. And I do have the source directory for VDR on my hdd, so I'm gonna check the compile-time config as well.

Frank

Dear gentlemen,

thanks for all your help with the setup so far...

Brief summary:

last night I got VDR+vaapidevice to properly start up for the first time. Full HD at 50p from T2 mux on my cheap old LCD TV, moving just right at 50 Hz, with the OSD now responding to my keyboard. The first impression with the default LCARS theme was pretty jaw-dropping: I went "wow this is stunning."

I appreciate a certain graphical style of the OSD, not necessarily bare bones nerdly ergonomic, but graphically pure and consistent in its simplicity. Very unlike the numerous tasteless high-color OSD's in major brand TV's :-) I can't help but thinking "this looks like some 2020's punk inspired by seventies aesthetics". Only now as I'm writing this message, I googled mostly by mistake what LCARS actually means. Gosh I wasn't that far off the mark :-DDD

As I got VDR to start, tried some plugins and generally gave it a test drive, immediately I started spotting... various technical consequences, and the number of follow-up questions in my head has kind of exploded :-) and I've spotted some rough edges and glitches, or maybe just config that I still need help with...

Namely, I may need help with audio - either I don't know how to configure that (in vaapidevice) or it's a bug...

Details (for others who may follow me):

Modelines and EDID and kernel command line and xorg.conf and all that jazz:

I've read your debate about transplanting EDID or just using a modeline, and how to massage that into a xorg.conf file. After a few iterations I have arrived at my own xorg.conf (see it attached) but let me start from the beginning.

I first noticed that xrandr seems to tell me, that the TV seems to claim in its EDID (obtained via HDMI) that it only supports full HD at up to 50i Hz, but not 50p. Just 30p and 24p were mentioned. Not sure if this is really what the TV says in its EDID, or if this is some misunderstanding down the road... anyway I've done this before, and I know that what the display is claiming in its EDID is not necessarily the whole truth, and on some occasions it makes sense to bend rules a bit, for various reasons.

Anyway the first thing I did: I fiddled a bit with the "video=" kernel cmdline arg (based on some past experience). Took a look in /sys/class/drm/card0* to see what names the different video interfaces had, and this is what I currently boot with:

video=eDP-1:e video=eDP-1:1280x1024@60 video=HDMI-A-2:e video=HDMI-A-2:1920x1080@50

(all of them on a single line in /etc/default/grub and hence also /boot/grub.conf )

As soon as I first tried the video=HDMI-A-2:1920x1080@50, the cheap Vestel TV obediently reported 1920x1080 50p in its OSD.

As my current test machine is a panel PC with a built-in LCD, and the TV is externally connected via HDMI, effectively I have a dual-monitor setup. Hence the two sets of video= parameters.

Next up was obviously the xorg.conf, as the Xserver obviously didn't buy the kernel's setup of the video ports... I've fumbled through several example configs of multi-monitor setups, collected across the interwebs... the ZaphodHeads turned out to be the wrong choice, but I found another config that results in a combined desktop without the Zaphod stuff. See my version attached. Note that each monitor is running in a different resolution and at a different refresh rate, yet it all works together very similar to the Windows style of multi-monitor operation.

I tried to infer some rules of how the Device and Screen and Monitor (and maybe Layout) sections link to each other, and I have to confess that some details are not yet clear to me, some example configs seem to suggest linking this or that way... I gave up on reading the X11 docs, in the end one of the "config styles" ultimately works for me :-) One of the points I was wondering about: does the naming of the monitors matter? Can I invent my own arbitrary names, or are they in fact predetermined? I've found notes such as this one: https://unix.stackexchange.com/questions/496696/multiple-monitors-on-l inux claiming that in fact the names are pretty much "set in stone" for my particular system. Such as, in my case: - the kernel (DRM) calls the devices eDP-1 and HDMI-A-2 - xrandr refers to them as eDP-1 and HDMI-2 - in the config file I have to call them eDP1 and HDMI2 And I didn't really investigate if the explicit mapping clause in my xorg.conf (rarely seen elsewhere) is necessary: Option "Monitor-eDP-1" "eDP1" Option "Monitor-HDMI-2" "HDMI2" ...or in fact, if it is correct and if it does actually do anything :-)

Fortunately this xorg.conf works for me. The possibility to have the VDR's stdout and all the other logs and config on one screen, and the VDR graphical output on another, that seems pretty useful when tuning things.

The relationships of the two screens develop during the boot process in an interesting way:

1) The BIOS mirrors the built-in eDP to the HDMI (if a monitor is attached) and probably sends the 5:4 video mode to the HDMI TV as well, becase I can see the BIOS POST welcome screen stretched across the whole horizontal dimension of the 16:9 TV.

2) I didn't tell Grub about multiple displays, so the BIOS mirror+stretch setup remains active well into the early stages of Linux kernel boot

3) once the kernel's video drivers (DRM+KMS) kick in, the TV starts to report the video mode specified at the kernel command line - and suddenly the letters (the font) assumes identical proportions on the 5:4 and 16:9 screens, and apparently the built-in 5:4 screen gets blitted to the upper left corner of the 16:9 TV, including later the graphical Ubuntu boot-splash.

4) once the boot reaches the GDM (X-winlogon), the kernel cmdline video modes still hold true (including 50p Hz on the HDMI), but the logon dialog only appears on the built-in display.

5) after logon to X, the modes change - apparently only now the xorg.conf kicks in. That's what I observed while my X config was not yet finished, and the HDMI picked 24 or 30 or 60 Hz based on momentaneous mood :-) Obviously once the xorg.conf "settled in", the external HDMI now runs in full HD at 50p Hz, the way I need it.

6) if I tried CTRL+Alt+F3 for a text-mode console, I would get correctly shaped letters (normal proportions) across the whole HDMI wide screen :-)

I know a bit about the internal block schematic of modern Intel IGP's (at least as far as signal chain routing and picture scaling / cloning goes) so the various variants are not at all surprising to me. The IGP is capable of a number of different setups.

I have noticed that if the TV is not connected to the HDMI port of the PC at BIOS POST, the port does not become available to the kernel. Apparently. At the same time, the TV does not pull at the HDMI "presence detect" (or hot plug detect?) pin until it is told to = you have to start the TV and tell it to use the HDMI input (at which point it starts counting down, saying "no signal") and only then start the PC = it's a bit of fun to persuade the two boxes to accept each other on HDMI. For production use, I could switch the TV into "hotel mode" and force HDMI as a primary input, or I could solder a pull-up to the "presence detect" pin in the HDMI on the motherboard, or maybe both :-) Note that the DDC bus (in the HDMI this is still an i2c) is independent of the "presence detect" pin, i.e. the presence of a monitor being attached on a port is not detected via DDC (i2c) and not depending on DDC (i2c) even being operational.

Note that a simple mode line was enough in my case to force the desired video mode. Along the way, I have copied the edid.bin to /lib/firmware as suggested by various sources, and I did check with edid-decode that the desired mode was in there... but in the end I did not have to refer to that EDID block in my xorg.conf.

I've also found a recipe on how to insert a new mode into the xrandr mode table, using just the xrandr command, and select the mode for my HDMI output. That did not work out. Apparently I was able to insert the modeline (or at least allocate a name for the mode) but the last command failed to force the HDMI video port to run along that modeline.

The material coming out of our DVB-T and T2 muxes, and how VDR copes with that:

Let me re-cap that the PC is a Panel PC machine with a Skylake-U i5 = dual-core with HT = 4 threads in hardware, Intel IGP capable of HEVC.

In my last message to this mailing list, I have complained that the video would "stutter", repeat a couple frames every now and then, probably to compensate for a faster frame rate of the display (at that time the HDMI output was clocked at 60 Hz). And indeed the 50p Hz frame rate on the HDMI port did help!

In one particular mux that's got a pretty good signal and CNR, I have two programs that are transmitted in HD HEVC, 1920x1080@50p . Obviously I was pretty curious about those two.

My tests were initially hampered by the fact that at the moment I got the display to work properly, one of the channels was broadcasting some coarse and ugly cartoon (the animation was naturally pretty jagged) and the other one was transmitting some ugly old SD content upscaled to full HD 50p - so it was hard to judge the quality. But later I had an opportunity to watch quality material on both those HD channels. One had an american movie, that fortunately was not a scaled-up NTSC, but rather was HD content either delivered in full HD at 50 Hz from production, or was processed by a good quality frame rate converter... the picture was detailed and the motion was smooth as silk. The other one switched to some live moderators doing some silly jests in a studio - and again that footage (or maybe live broadcasting) was smooth as silk.

Under some conditions, I've also seen the full HD picture stutter a bit. I kept waiting for sequences with some long, continuous smooth motion in the picture. I have identified that one cause to the stuttering is, if I click the VAAPI window on the HDMI output, which brings it from full screen to "maximized mode with a window decoration" (the title bar and buttons in the upper right corner) so that the picture must be scaled down into a slightly smaller "viewport". I assume that the scaling causes the mild stutter. If I let the VDR (vaapidevice plugin) run full screen, the "locally caused" stuttering is not there.

On one of the channels, I have also noticed one piece of material that was in full HD resolution (highly detailed and sharp) but would stutter. It was a trailer/teaser for some upcoming gardening show, with drone-based long sweeping takes of someone's garden = an outdoor scene with smooth continuous motion. And my idea is, that the footage was taken at a 30 Hz or 60 Hz frame rate and rate-converted in some cheap way (or they tried to dispatch the 60Hz material straight, not sure if this is technically possible in their studio). When I saw that teaser for the third time, it was clear to me that here it's the material being broadcast that has a problem. Then came a cut to the live moderators and "motion smoothness" was back to normal...

Apart from full HD at 50p Hz I have two or three other formats coming out of the muxes: - 960x540 HEVC (QHD) at 50p Hz from DVB-T2 - 720x576 H264 (SD) at 50i Hz from DVB-T - 720x576 MPEG2 (SD) at 50i Hz from DVB-T

The 960x540 at 50p seems to stutter a tiny little bit... possibly because it needs to be scaled up to the full HD screen. Or possibly the U.S. TV show material has passed through so many stages of scaling and temporal interpolation that it would look shakey on anything :-)

The MPEG2 SD streams at 50i Hz clearly show signs of missing deinterlacing in the VAAPI. I'm attaching a photo. This is certainly not a bug in the VDR nor vaapidevice, more like a possible deficiency in the vaapi. Actually only some part of the footage is showing the "interlacing mismatch artifacts". Especially fresh live studio broadcasts, where the chain is probably interlaced end to end. Other contributions do NOT show the "interlacing mismatch artifacts". This is curious. That footage probably comes from a non-interlaced source, which was not properly converted to interlaced format including spatial and temporal interpolation. Thus, the playback is actually more like 25p SD I've actually seen one "election advertisement" consisting of two parts, where some talking heads do not exhibit the "interlacing artifacts", but an animation following some "footage with actual humans" does exhibit strong artifacts :-)

The SD streams encoded in H264 and transported by DVB-T, nominally at 50i, do not exhibit any "missing deinterlacing" artifacts. Again possibly the footage was originally not interlaced, so the broadcast is more like 25p.

There's also some MPEG decoding bug, which I believe looks like something between the vaapidevice and VAAPI. The T2 programs at full HD or QHD, encoded in HEVC, those are played just fine. The SD encoded in H264 also plays back just fine. But: there's a problem with the old MPEG2 content coming out of DVB-T. I have noticed that if I switch from non-MPEG2 content to an MPEG2 program, it works fine - until I switch to another MPEG2 program. At which point something goes awry and I get just junk on the display (with a correct VDR OSD). To recover from the bug, it takes a switch to some non-MPEG2 program (which is displayed correct) and then back to an MPEG2-compressed program, to get healthy MPEG2 decoding again.

The MPEG2 decoding bug is possibly related to this: https://github.com/pesintta/vdr-plugin-vaapidevice/issues/121 I haven't tried the "speedupdown-patch" yet... not sure if this is not too long past. I may try it in a few days. I have taken steps to make sure that this is not down to the IGP overheating, or the Mygica overheating, or a ground loop noise between the PC and my existing TV equipment (via the protective earth and HDMI and coax GNDs) - no, not likely.

Other than that... both the missing deinterlacing feature and the decoding bug apparently only hamper the old MPEG2 material that comes out of DVB-T. That in fact does not bother me. If I build an HTPC for DVB-T2, in a year or earlier there won't be any DVB-T with MPEG2 to receive anymore. Probably just HEVC, and that works fairly fine.

I was also wondering if I could make the QHD 540p material play back smoother. And my idea is, that I could leave that scaling up to the TV. But for that, I'd have to configure the HDMI output to the 540p native video mode. (Per analogiam, to have the LCD TV deinterlace 576i for me, I'd have to configure that mode on the HDMI.) An additional modeline or two are certainly no problem, but I'd have to reconfigure the output differently for each TV program... VDR does not support that. And I'm wondering if VDR's OSD scaling would cope with that ;-) Just a crazy fruitless idea.

One last note that bothers me a bit: I can't seem to configure audio output from the vaapidevice VDR plugin. I have some onboard HDA codec (Realtek/ALC something), and the kernel also reports that it knows about the HDMI audio, again attached via the HDA bus PCI interface in the PCH. I have configured X via the ubuntese configuration dialog to use HDMI audio as the default device, and I can hear the test sounds. But not the vaapidevice audio. In the logs, I can see a note that VAAPI has chosen the "noop" output device. Go figure. I'm attaching some log snippets. I've looked at the docs of vaapidevice, tried something via the environment variable, and I also tried configuring a passthrough via the config file, but neither achieved anything. Any suggestions welcome.

I have extended the keyboard config example from KLS to contain keys for volume +/- . Found the key definitions in the Wiki or something. That works, the volume control bar in the OSD responds, it's maxed out, but I still cannot hear anything.

Other than that, the femon and wirbelscan plugins work fine. Initially, with the channels.conf obtained from w_scan/w_scan2, I had a problem that the EPG/INFO data wouldn't work. Once I learned how the Wirbelscan works, I left just one program defined in the initial channels.conf, and let Wirbelscan re-populate the channels list for me. Now I have EPG for all the programs :-)

The EPG texts have correct eastern-Latin character set on all the channels. And even the OSD speaks correct Czech for the most part. This is incredible. Maybe I'm missing a "tabular-style" EPG sheet (time horizontally, programs vertically) but I cannot always get everything I want, certainly not for free...

And that's probably all for today. Thanks for your attention :-)

Frank

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: hevc_540p_plays_well.jpg Date: 12 May 2019, 15:59 Size: 34520 bytes. Type: JPEG-image

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: hevc_1080p_plays_well.jpg Date: 12 May 2019, 16:02 Size: 43896 bytes. Type: JPEG-image

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: mpeg2_576i_breaks_on_program_change.jpg Date: 12 May 2019, 15:50 Size: 45096 bytes. Type: JPEG-image

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: mpeg2_576i_deinterlacing_defunct.jpg Date: 12 May 2019, 15:47 Size: 307607 bytes. Type: JPEG-image

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: mpeg2_576i_signal_good__playback_garbage.jpg Date: 12 May 2019, 15:51 Size: 137617 bytes. Type: JPEG-image

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: vdr_syslog_audio.txt Date: 12 May 2019, 12:20 Size: 465 bytes. Type: Text

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: 20-intel.conf Date: 12 May 2019, 13:49 Size: 972 bytes. Type: Unknown

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: dmesg_audio.txt Date: 12 May 2019, 12:05 Size: 2059 bytes. Type: Text

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information ----------- File: h264_576i_plays_well.jpg Date: 12 May 2019, 15:49 Size: 54048 bytes. Type: JPEG-image