Bist du sicher, dass VDR GetVideoSize() aufruft und nicht ein anderes Plugin, z.B. ein Skin?
Du hast Recht. Skinnopacity macht den Aufruf, weil es wissen muss, in welchem Seitenverhältnis es das das Videobild in seinem OSD-Fenster darstellen soll. Den Aufruf habe ich bei replay wohl deshalb nicht gesehen, weil ich da nie die Menütaste gedruckt habe und so nie ein OSD-Aufruf kam.
Bezüglich des base class-Aufrufes: siehe z.B. dvbsddevice:
void cDvbSdFfDevice::GetVideoSize(int &Width, int &Height, double &VideoAspect)
{
if (fd_video >= 0) {
video_size_t vs;
if (ioctl(fd_video, VIDEO_GET_SIZE, &vs) == 0) {
Width = vs.w;
Height = vs.h;
switch (vs.aspect_ratio) {
default:
case VIDEO_FORMAT_4_3: VideoAspect = 4.0 / 3.0; break;
case VIDEO_FORMAT_16_9: VideoAspect = 16.0 / 9.0; break;
case VIDEO_FORMAT_221_1: VideoAspect = 2.21; break;
}
return;
}
else
LOG_ERROR;
}
cDevice::GetVideoSize(Width, Height, VideoAspect);
}
Display More
dvbhddevice hat die gleiche letzte Zeile in der Funktion. Bei rpihddevice und sämtlichen softhd*-Plugins fehlt es.
Wenn ich es richtig verstehe, soll es Aufgabe des Ausgabeplugins sein, das Seitenverhältnis zu ermitteln um
- ein richtiges Seitenverhältnis bei der Skalierung auf die Bildschirmgröße vorzunehmen (also z.B. 720x576 nicht-anamorphes Vollbild nicht bildschirmfüllend auf 1920x1080 auszugeben, sondern Balken links und rechts einzufügen)
- ggf. anamorph ausgestrahlte Sendungen (das dürfte nur bei mpeg2 720x576 eine Rolle spielen) richtig zu behandeln. (Die Größe ist immer 720x576, aber bei 16:9 wird das Bild seitlich gestaucht und muss dann entweder mit eingefügten Balken dargestellt werden oder - wenn der Bildschirm 16:9 ist - in die Breite gezogen werden. Denkbar wäre auch, nur ein Widescreen-flag zu setzen und die richtige Darstellung dem TV zu überlassen - das setzt aber die Hardware-Fähigkeit voraus, WSS-bits zu übertragen.)
- auf Anforderung über GetVideoSize einem Plugin die Größe und das Seitenverhältnis mitzuteilen.
Diese Beschreibungen aus device.h verwirren mich nun, weil der Unterschied nicht deutlich wird:
virtual void SetVideoDisplayFormat(eVideoDisplayFormat VideoDisplayFormat);
///< Sets the video display format to the given one (only useful
///< if this device has an MPEG decoder).
///< A derived class must first call the base class function!
///< NOTE: this is only for SD devices. HD devices shall implement their
///< own setup menu with the necessary parameters for controlling output.
virtual void SetVideoFormat(bool VideoFormat16_9);
///< Sets the output video format to either 16:9 or 4:3 (only useful
///< if this device has an MPEG decoder).
///< NOTE: this is only for SD devices. HD devices shall implement their
///< own setup menu with the necessary parameters for controlling output.
Display More
Worum es mir aber eigentlich geht:
Das Seitenverhältnis kann sich während einer laufenden Sendung ändern. Das sieht man bei den Privatsendern Super RTL, RTL up und RTL Nitro in SD öfters, da diese zwischendurch immer mal wieder alte Shows zeigen, die damals noch in 4:3 produziert wurden. Es reicht also nicht, Größe und Seitenverhältnis einmalig beim Playmode-Wechsel zu ermitteln, sondern die Videodaten müssen ständig geprüft werden. Das Seitenverhältnis kann zumindest bei mpeg2 recht einfach aus dem sequence header ermittelt werden. Bei h264 ist das offenbar nur aufwändiger über die SPS Daten möglich. Für h264 und HEVC kann man in der Regel zwar unterstellen, dass das Seitenverhältnis immer 16:9 ist. aus. RTL Nitro strahlt in SD z.B. 960x540 mit 16:9-Kennung aus. Nun habe ich aber eine h264-Aufnahme in 720x576 mit 4:3-Kennung...
Es scheint, als wenn vdr Breite, Höhe und Seitenverhältnis in remux.c (z.B. void cH264Parser::ParseSequenceParameterSet) bereits selbst ermittelt. Deshalb frage ich mich, ob es nicht der richtige Weg wäre, wenn vdr dem Ausgabeplugin diese Daten mit übermitteln würde, statt es jedem Ausgabeplugin zu überlassen, die Angaben aus den angelieferten Daten wieder mühsam selbst zu ermitteln.
