Re: A couple of noob questions on VDR + vaapidevice (output plugin)

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

_______________________________________________
vdr mailing list
[email protected]
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

May 12 11:26:39 plechovka vdr: [3586] VAAPI: audio: 'noop' output module used
May 12 11:26:39 plechovka vdr: [3586] VAAPI: audio:  44100Hz supports 0 0 0 0 0 0 0 0 channels
May 12 11:26:39 plechovka vdr: [3586] VAAPI: audio:  48000Hz supports 0 0 0 0 0 0 0 0 channels
May 12 11:26:39 plechovka vdr: [3586] VAAPI: audio: 192000Hz supports 0 0 0 0 0 0 0 0 channels
...and then later...
May 12 11:26:49 plechovka vdr: [3596] VAAPI-ERROR: audio: 2 channels unsupported

Section "Monitor"
  Identifier    "eDP1"
  Option	"LeftOf" "HDMI2"
  Option	"DPMS" "false"
EndSection

Section "Monitor"
  Identifier    "HDMI2"
  Modeline      "1920x1080_50" 141.50  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync
  Modeline      "1920x1080_60" 173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
  Modeline      "1920x1080_24" 63.00  1920 1976 2160 2400  1080 1083 1088 1098 -hsync +vsync
  Option	"PreferredMode" "1920x1080_50"
  Option	"RightOf" "eDP1"
  Option	"DPMS" "false"
EndSection

Section "Screen"
  Identifier    "Screen0"
  Device        "Device0"
  Monitor       "HDMI2"
  DefaultDepth   24
  SubSection   "Display"
    Depth       24
    #Modes      "1920x1080_50" "1920x1080_60" "1920x1080_24"
  EndSubSection
EndSection

Section "Device"
  Identifier    "Device0"
  Driver        "intel"
  BusID		"0:2:0"
  Option 	"Monitor-eDP-1" "eDP1"
  Option	"Monitor-HDMI-2" "HDMI2"
  Option        "TearFree" "true"
EndSection

[   20.646459] snd_hda_codec_realtek hdaudioC0D0: ALC662 rev1: SKU not ready 0x411111f0
[   20.646915] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC662 rev1: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
[   20.646917] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   20.646918] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[   20.646918] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[   20.646919] snd_hda_codec_realtek hdaudioC0D0:    dig-out=0x1e/0x0
[   20.646919] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[   20.646920] snd_hda_codec_realtek hdaudioC0D0:      Front Mic=0x19
[   20.646921] snd_hda_codec_realtek hdaudioC0D0:      Rear Mic=0x18
[   20.646922] snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
[   20.743970] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input18
[   20.744022] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input19
[   20.744068] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input20
[   20.744131] input: HDA Intel PCH Line Out Front as /devices/pci0000:00/0000:00:1f.3/sound/card0/input21
[   20.744225] input: HDA Intel PCH Line Out Surround as /devices/pci0000:00/0000:00:1f.3/sound/card0/input22
[   20.744274] input: HDA Intel PCH Line Out CLFE as /devices/pci0000:00/0000:00:1f.3/sound/card0/input23
[   20.744317] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input24
[   20.744363] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input25
[   20.744409] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input26
[   20.744469] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input27
[   20.744513] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input28
[   20.744556] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input29