den Doc für die Zukunft rüsten..

Begonnen von Mam, April 02, 2019, 10:11:38

« vorheriges - nächstes »

Mam

...nein, ich rede nicht mal wieder von 64Bit Version, Scheffe wird früh genug merken, wenn Mikrosoft dasselbe wie Apple macht und den 32Bit Apps die Luft abdreht.

Mir gehts um die Erkennung/Verarbeitung von aktuellen Formaten (guckst Du Anhang 1)

Der Doc liest die Datei gnädigerweise schon mal ein, aber, was er da zu lesen glaubt, ist leider im Moment grober Unfug  :o

Das Video ist nicht, wie irrtümlich angezeigt, HDR10, sondern Dolby Vision. Über die Tonspuren brauchen wir nicht wirklich reden, nur eine (die 5te von 29) ist wirklich "German", alles andere ist was anderes.

Offensichtlich fehlt da die Dolby Vision Erkennung, Du solltest es wie bei VLC nachtragen:
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -163,6 +163,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {

     { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */
     { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */
+    { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby Vision derived from hev1 */
+                                                     /* dvh1 is handled within mov.c */

     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
@@ -185,6 +187,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
     { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */
     { AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422 produced by FCP */
     { AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2 AVC-LongG */
+    { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby Vision derived from avc1 */
+    { AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby Vision derived from avc3 */

     { AV_CODEC_ID_VP8,  MKTAG('v', 'p', '0', '8') }, /* VP8 */
     { AV_CODEC_ID_VP9,  MKTAG('v', 'p', '0', '9') }, /* VP9 */

Achtung! wie man sieht, gibt es zwei verschiedene Dolby Vision Kennungen! Beide sind in freier Wildbahn im Umlauf.
(Wenns an Samples mangelt, sag Bescheid, aber wie Du siehst, sind es fast 80Gb, das könnte dann schon mal ein paar Minütchen dauern...)

Cypheros

Das Problem mit Dolby Vision ist, dass es im Video-Stream eingebettet ist und ich zur Zeit noch keine Infos habe, wo genau der Indikator zu finden ist. Ich nehme an, dass er in einer SEI steckt, die ich aber im Moment noch nicht auswerte.
Dolby Vision ist ein Addon, wenn ich die Specs richtig verstanden habe. Für alle Geräte, die kein Dolby können, ist noch alternativ HDR10 vorhanden. Darum sollte die Anzeige mit HDR10 schon korrekt sein.

Mam

#2
Zitat von: Cypheros am April 02, 2019, 17:23:40
Ich nehme an, dass er in einer SEI steckt, die ich aber im Moment noch nicht auswerte.
Ich dachte, mein Quote aus der VLC-Source wäre klar gewesen?
Das ist ein Tag im Stream. bzw. 2 verschiedene Tags, je nach Format. Stream gucken, Tagliste extrahieren, mehr wissen  ;D
"dvhe" für 265 Codecs
"dva1" für AVC/264 Codecs

(Heißt wohl "d"olby "v"ision "he" H265 Extension bzw "a1" H264 Extension)

Ich nehme mal stark an, wir werden in freier Wildbahn nur die dvhe Variante finden)

Cypheros

Das aus dem VLC-Sources ist die interne Beschreibung des Stream-Typs. Beim Transportstream wird das anders gehandhabt.
Hab Dir ne Mehl mit den Specs von Dolby geschickt.

ZitatWhen an MPEG-2 Registration Descriptor is used to provide the
unique identification for the Dolby Vision stream, the
format_identifier shall be set to 0x444F5649 ("DOVI"), as shown in
Table 3-1; which contains the descriptor structure for context and
convenience of the reader.
...
The following sections specify how the stream_type parameter shall be
set and which elementary stream descriptor shall be inserted in the PMT
for each of the PID carrying Dolby Vision stream.



Mam

Zitat von: Cypheros am April 02, 2019, 18:37:24
Das aus dem VLC-Sources ist die interne Beschreibung des Stream-Typs. Beim Transportstream wird das anders gehandhabt.
Hab Dir ne Mehl mit den Specs von Dolby geschickt.

Ich würde das nicht "Specs" nennen, eher "Wunschdenken". Die Doc setzt voraus, dass die Sender spezielle (und damit inkompatible) PIDs benutzen um das Dolby Format zu verbreiten.
Das kostet natürlich extra Lizenzgebühren und erfordert Updates an allen Receivern.
Ich gehe mal davon aus, dass da die Welt nicht mitspielt und das Ganze eine Totgeburt ist.

Die andere Variante (die, die in dem "Sample" drin ist, was Du bald hast) besteht aus harmlosen Tags, die in einen normalen H265 Stream eingebettet sind. Decoder, die den Tag nicht kennen, überspringen ihn einfach, NICHTS passiert. Das "normal Format" ist HDR 10, die Dolby Zusatzinfos verschieben nur den Schwarzpunkt und die Farbansätze, aber in "bescheidenem Umfang". Für diesen Kram braucht man keinen extra PID, und keine Änderungen an vorhandenen Decodern. Ist quasi ein "nicht-essentielles-Bonusformat".
(und dieser Ansatz erscheint mit deutlich sympathischer, 4k hat schon genug Chaos angerichtet, wenn es wirklich irgendwann man Mainstream werden will, wird es dringend Zeit für kompatible Formate. Der Heimanwender hasst es, wenn der Bildschirm schwarz bleibt, weil irgendein Teil der Wiedergabekette gerade mal wieder einen Schluckauf hat)

Cypheros

Hinzu kommt, dass die benötigte Rechenleistung bei der Farbverschiebung für DV höher ist (12bit statt 10bit) als bei den anderen Verfahren. Viele HDR-fähige Sony-Fernseher haben nicht genug Power trotz Dolby Vision Lizenz und benötigen ein Wiedergabegerät, das die Signalaufbereitung für DV übernehmen kann (Low Latency HDMI-Modus). Es gibt aber so gut wie keine Wiedergabe-Geräte, die das können.


www.cypheros.de