Jump to content

Edit:2023 ähnliches Problem mit hoher Datenrate und 422 // Kein Sender in 4k/UHD läuft bei mir fehlerfrei ... genaue Beschreibung


marcello64

Recommended Posts

Hast du auch schon verschiedene Audio Decoder ausprobiert? Ich kann das hier mit dem LAV Audio glaube ich reproduzieren, mit dem AC3 Filter ( http://www.ac3filter.net/  ) hingegen nicht. Vielleicht könntest du den mal ausprobieren? Sieht imho verdächtig nach einem Problem auf der Audio-Seite aus (was einen erheblichen Einfluss auf die Videowiedergabe hat).

 

Ansonsten gehts dann die Tage weiter ...

 

 

Link to comment

Hier läuft das Sample unter Windows 10 flüssig und fehlerfrei mit DVBViewer Pro, Custom EVR, LAV DXVA2 native und NVIDIA GT 1030, wenn ich die Puffergröße in der DVBSource.ini hochsetze (HEVCBufferSize=64 mindestens). Mit der Standardgröße 16 (kb) ruckelt es, mitunter nur Standbild.

 

Mit dem Lentoid unter Windows 8.1 Farbverfälschungen und starkes Ruckeln bei hoher CPU-Last. Da ist nichts zu gewinnen.

Link to comment

Habe eben den AC3-Filter soeben installiert, aber keine Änderung. Bei den anderen beiden funktionierenden Programmen nutze ich aber auch für Audio komplett LAV.

Link to comment
3 minutes ago, Griga said:

Hier läuft das Sample unter Windows 10 flüssig und fehlerfrei mit DVBViewer Pro, Custom EVR, LAV DXVA2 native und NVIDIA GT 1030, wenn ich die Puffergröße in der DVBSource.ini hochsetze (HEVCBufferSize=64 mindestens). Mit der Standardgröße 16 (kb) ruckelt es, mitunter nur Standbild.

 Ja Griga, bei mir auch. Das Abspielen der Aufnahme von Transedit funktioniert in allen Variationen fehlerfrei ... aber nicht die Echtzeit-Wiedergabe. HEVCBufferSize habe ich auch ab 512  und ohne alle Möglichkeiten durchprobiert.

Link to comment

Grüße ausm Ghetto bla blah..

 

vor 3 Stunden schrieb Griga:

Hier läuft das Sample unter Windows 10 flüssig und fehlerfrei mit DVBViewer Pro, Custom EVR, LAV DXVA2 native und NVIDIA GT 1030, wenn ich die Puffergröße in der DVBSource.ini hochsetze (HEVCBufferSize=64 mindestens). Mit der Standardgröße 16 (kb) ruckelt es, mitunter nur Standbild.

 

Mit dem Lentoid unter Windows 8.1 Farbverfälschungen und starkes Ruckeln bei hoher CPU-Last. Da ist nichts zu gewinnen.

 

Hier läuft das Sample unter Windows 10 nicht ganz flüssig und fehlerfrei mit DVBViewer Pro 611, Custom EVR, LAV DXVA2 native und NVIDIA GTx960. Beachte den Fisch der direkt auf den Schwamm zuschwimmt, da gibt es bei mir 3 kurze Sprünge - EGAL was in HEVCBufferSize= (0-1024 probiert) steht. Und zwar nur dann wenn DVBV mit dem Video gestartet wurde per Drag.n.drop.

1 Sprung - sec 9 (Schreibblock)

3 Sprünge - sec 16-18 (Fisch + Schwamm)

 

Springt man nach den Rucklern per timeline zurück läufts glatt. Na ja ein schwaches Indiz aber immerhin eines. MPC-HC mit LAV kanns hier ohne alle Ruckler.

Spielt mans im DVBV mit LAV Splitter statt DVBSource läufts ebenfalls immer glatt.

 

Link to comment

..dann das Sample durch TSDoctor2 geschickt, nix geschnitten oder eingestellt, einfach wieder raus als Türkall.ts - läuft nun auch mit DVBSource ohne Ruckler. Leider ist TSDoc nicht allzu mitteilsam was er macht dennoch hier sein reparatur.log, obs hilft?


 

Spoiler

 

Opening file I:\Downloads\Türksat 2A3A 42.0°E 10980 V 07-24 20-19-04.ts

OS: Windows 10 Build 16299 x64
OS language    : DE
Appl. language : German
TSDoctor.exe V 2.0.97 (Build 041BEE)
Instance     : 0
System memory: 15,94 GB / Free: 12,06 GB
Used memory  : 209,93 MB
NVIDIA GeForce GTX 960 (DISPLAY1) nvldumd.dll 23.21.13.9077
CPU type     : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
CPU count    : 8
CPU usage    : 5%
Resolution   : 3840 x 2160 (32Bit) 144 DPI
Monitors     : 1
Supported TS source filter found  : TS Doctor FileSource (on)
Supported splitter filter found   : Haali Media Splitter, LAV Splitter
Supported audio filter found      : LAV Audio Decoder
Supported Mpeg video filter found : LAV Video Decoder, CyberLink Video/SP Decoder
Supported H264 video filter found : LAV Video Decoder, CyberLink Video Decoder (PDVD12), CyberLink Video Decoder (PDVD Generic), Microsoft DTV-DVD Video Decoder
Supported video renderer found    : Video Renderer, Haali Video Renderer, Enhanced Video Renderer

Channel database : 6362 channels, 7 satellites [Thor 0.8°W, Astra 19.2°E, Astra 23.5°E, Astra 28.2°E, Astra 4.9°E, Hellas Sat 39°E, Hotbird 13°E]
Teletext database: 280 channels, version 17.8.27

File size: 212918272
Packets  : 1132544

Found 1 fill packets at end
Broadcast standard selected: DVB
Broadcast standard detected: DVB
PES WARNING: PID 13BF DataAlignmentIndicator = 0

4855  (12F7): 95%  = H265 Video (PES_StreamID E0 = Video_Stream_0) {00000001} [PCR,PTS]
8191  (1FFF): 4%   = NULL
5055  (13BF): 0%   = AAC Audio (PES_StreamID C0 = Audio_Stream_0) {56E21336} [PTS][PESLength]
4955  (135B): 1%   = E-AC3 Audio (PES_StreamID BD = Private_Stream_1) {0B7701FF} [PTS][PESLength]
0     (0000): 0%   = PAT
1     (0001): 0%   = CAT
4755  (1293): 0%   = PMT
17    (0011): 0%   = SDT,BAT,ST

 

Selecting PMT with PID 4755 (1293) at position 00000524
CRC OK!

0.
  stream_type              : 36 = ITU-T Rec. H.265 and ISO/IEC 23008-2 (Ultra HD video) in a packetized stream
  elementary_pid           : 4855 (12F7)
  ES_info_length           : 0

1.
  stream_type              : 6 = ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data (E-AC3)
  elementary_pid           : 4955 (135B)
  ES_info_length           : 4

2.
  stream_type              : 15 = ISO/IEC 13818-7 Audio with ADTS transport syntax (AAC ADTS)
  elementary_pid           : 5055 (13BF)
  ES_info_length           : 5

PCR PID is 4855 (12F7)

searching for channel: SID=16300, TID=30801, VPID=4855

service_id $3FAC = TRT 4K

First video PTS is 6031927984 18:37:01.422
Last video PTS  is 6037543984 18:38:03.822

First PCR  is 1809553548300 18:37:00.502
Last PCR  is 1811242030234 18:38:03.038
Duration of video stream is 5628273 00:01:02.536
Video PCR to PTS difference -819 ms
4955  (135B): Delay to video stream = -625ms
5055  (13BF): Delay to video stream = -435ms

PID allocation
V :4855  (12F7)#####################################################################################################
  :8191  (1FFF)####################################################################################################.
A :5055  (13BF)####################################################################################################.
A :4955  (135B)####################################################################################################.
  :0     (0000)#.##.##.#######.##..#.##.##.##.##.##.##########.##.##.##.##.##.##.##.##.#######.##.##.##.##.##.##.##.
  :1     (0001).............#..#..#...............#..#..#...............#..#...............#..#..#...............#..
  :4755  (1293).##.##.##########.##.##.##.##.##.##.##.##.####.##.##.##.##.##.##.##.##.##########..#.##.##.##.##.##..
  :17    (0011)...............#........................................#..................#.........................

Video format: H265 (HEVC) 3840x2160p/AR=16:9/50 fps/Main 10@5.1
Colorimetry : 4:2:0
First I-Frame not found !!!
Use instead first I-Frame PTS at 18:37:01.422 [00:00:00.000]

AC3 6 channels: 18 times
Audio stream 1: EAC3 5.1 48000Hz (DEU)
AAC 2 channels: 18 times
Audio stream 2: HE-AAC/LC 2.0 48000Hz (DEU)
WMP12 PMT patch: AC3 is first in stream
WMP12 PMT patch: AC3 is first in PMT
Commercial search options: VA

No cutting

WMP12 PMT patch: AC3 is first in stream
WMP12 PMT patch: AC3 is first in PMT

Cut in  at PCR: 00:00:00.000 (18:37:00.502)
Cut out at PCR: 00:01:02.536 (18:38:03.038)
First packet  : 00000480
Last packet   : 001147FF
Using current PCR as start PCR

Starting at packet 00000480 PCR: 00:00:00.037 (18:37:00.539)
Ending at packet 001147FF PCR: 00:01:02.536 (18:38:03.038)
PES WARNING: For PID 12F7 DVB/ATSC unconform PES formating detected: ControlBitsPTS,ControlBitsPTS2,ControlBitsDTS

File sizes:
            I:\Downloads\Türkall.ts 199.144 KB [CRC=E19D47B0]
Cutted packets at the beginning: 1105
Cutted packets at the end: 1
Discarded packets (not needed): 46958

PID stream sizes
$12F7:     196.455 KB
$135B:       2.009 KB
$13BF:         642 KB

PID stream average bitrates
$12F7: 25,5 Mbps
$135B: 261,2 Kbps
$13BF: 83,4 Kbps

ERRORS : 0
WARNINGS : 1

Speed: 0,8 MBytes/sec
Duration: 00:04:21

 

 

Link to comment
11 hours ago, nuts said:

müssen wir doch mal versuchen die Echtzeitbedingungen mit dem Testfile nachzustellen. 

 

Live-Simulation: Im DVBViewer Senderlisten-Editor einen neuen TS Stream-Eintrag erstellen, als Adresse den lokalen Dateipfad eintragen und den Sender anwählen. So ist das Problem nachvollziehbar.

 

Ein genauer Blick auf die DVBSource-Eigenschaftsseite zeigt die Ursache: Es gibt keine Video-Zeitstempel (PTS) bzw. der DVBViewer Filter zeigt keine an. Im TransEdit Analyzer -> Hex Viewer sind jedoch welche im PES Header vorhanden. Woran es fehlt, zeigt schließlich die Header Info-Funktion:

 

Zwischenablage01.png

 

In die Zeitstempel werden gemäß ISO-Spezifikationen ein paar Marker-Bits mit einem bestimmten Wert als Fehler-Schutzmechanismus eingestreut. Wenn sie nicht stimmen, ist davon auszugehen, dass die Zeitstempel verfälscht wurden. Deshalb verwirft sie der DVBViewer Filter. Am Fehlen der Video-Zeitstempel wiederum scheitert die Kombination LAV Video Decoder plus EVR Custom unter Live-Timingbedingungen. Ein korrekter Video/Audio-Sync ist so generell nicht erzielbar.

 

Das erinnert an Zeiten, als Derrick mich regelmäßig mit irgendwelchen pathologischen Streams (Feeds) beschäftigt hielt....

 

Link to comment

P.S. Der TS Doctor hat es auch entdeckt:

 

3 hours ago, craig_s said:

PES WARNING: For PID 12F7 DVB/ATSC unconform PES formating detected: ControlBitsPTS,ControlBitsPTS2,ControlBitsDTS

 

Wahrscheinlich sind die Zeitstempel als solche trotzdem korrekt. Der DVBViewer Filter nimmt es da jedoch sehr genau. Würde er es anders halten, gäbe es womöglich bei anderen Gelegenheiten Probleme. Und nein, ich werde keine Konfigurationsmöglichkeit für die Berücksichtigung der Marker Bits einbauen... das muss an der Quelle gefixt werden, nämlich bei TRT 4k.

 

Link to comment
8 hours ago, Griga said:

Live-Simulation: Im DVBViewer Senderlisten-Editor einen neuen TS Stream-Eintrag erstellen, als Adresse den lokalen Dateipfad eintragen und den Sender anwählen. So ist das Problem nachvollziehbar.

 

 

Feine Sache.

 

7 hours ago, Griga said:

Wahrscheinlich sind die Zeitstempel als solche trotzdem korrekt. Der DVBViewer Filter nimmt es da jedoch sehr genau.

 

Ich hätte jetzt fast geschrieben, deutsche Korinthenkacker-Genauigkeit ,aber ich lasse es, da ich i.d.R. selbst so bin.

Aber trotzdem kann man das auch anders sehen. Für mich ist das, wie schon geschrieben, immer eine Frage des Vergleichs. Ich bin der Meinung, wenn andere das hinkriegen, sollte es doch demjenigen auch gelingen und es macht wenig Sinn, immer andere dafür verantwortlich zu machen und die Zeit damit zu verbringen, anstatt an einer Lösung zu basteln. Wenn man anders denkt, wird es sowieso nüscht. Die Leute, die etwas nutzen wollen, werden immer nur vergleichen, wo etwas funktioniert und wo nicht und keine tiefgehende Analyse machen.

 

Meistens sind die Standalone-Receiver empfindlicher als TV-Programme am PC, aber auch die haben damit keine Probleme. Ich habe es an drei unterschiedlichen UHD-Boxen ausprobiert. Also 5/6 der getesteten Varianten waren fehlerfrei erfolgreich.

 

8 hours ago, Griga said:

Das erinnert an Zeiten, als Derrick mich regelmäßig mit irgendwelchen pathologischen Streams (Feeds) beschäftigt hielt....

 

Ich kann mir schon Horsts angeblich pathologische Feeds hinsichtlich des DVBViewers vorstellen, die gibt es heute in h.264 auch noch. Pathologisch sind die m.M.n. nicht, bloß ein My abseits von dem, was der DVBViewer verlangt. Ich schätze 96-97/100 von den Feeds, die ich einlese, funktionieren im DVBViewer, die restlichen nicht. War schon immer so.

 

7 hours ago, nuts said:

Auch der LAV Filter (Decoder) nimmt es da wohl ziemlich genau, aber dagegen ist erstmal nichts einzuwenden. 

 

Dass es nicht am LAV liegt, obwohl er ja auch ein bisschen pedantisch genau sein soll, wurde doch schon besprochen. Er funktioniert an anderer Stelle.

 

Vermutlich habt ihr auch türkische Kundschaft, nur mal so am Rande. Für mich kein Drama, wenn auch schade, solange es bei dieser Ausnahme bleibt.

 

Und die BitDepthChroma/BitDepthLuma-Anzeige in der Source machbar oder nicht (gewollt)? Wäre sicher auch für andere interessant.

 

 

Link to comment

Mit Veränderungen, die den A/V Sync betreffen muss man gerade am Computer besonders vorsichtig sein.

Das klappt dann ggf. an dieser Stelle und führt in anderen Fällen zu ungewünschten und  unauffindbaren Effekten (A/V Drift etc.).

Ich bin da eher auch dafür sich an die Spezifikationen zu halten, wobei es natürlich interessant wäre wie die anderen Programme diesen Fall behandeln?

Ein Augen- und Ohren Vergleich mit anderer Software hilft überhaupt nicht, da du (ich natürlich auch nicht) die Risiken und Nebenwirkungen nicht kennst und auch nicht abschätzen kannst.

 

Was man mal noch probieren könnte: Läuft es mit dem madVR Videorenderer besser?

https://forum.doom9.org/showthread.php?t=146228

 

Letztendlich können auch die Sync-Mechanismen der EVR Renderer ungünstige auf die "Live-Timingbedingungen" einwirken.

 

P.S. Vielleicht hilft es @nevcairiel zu dem Thema zu befragen?

 

Link to comment
28 minutes ago, marcello64 said:

Ich bin der Meinung, wenn andere das hinkriegen, sollte es doch demjenigen auch gelingen

 

Tröstlich ist, dass auch ProgDVB- und DVBDream-Foren von solchen Meinungen nicht verschont bleiben. Nur wird da gerne der DVBViewer zum Vergleich herangezogen, gemäß der simplen Anwender-Logik: Wenn Programm A das hinkriegt und Programm B nicht, muss Programm B wohl was falsch machen.

 

Viele Anwender verstehen nicht, dass jede Herangehensweise/Strategie insbesondere beim "error concealment" Vor- und Nachteile hat, und sind nicht in der Lage, über den engen Horizont ihres Setups und ihres Bedarfs hinauszudenken. Was sich in Fall A als günstig erweist, kann in Fall B von Nachteil sein. Ich habe bereits mehr als einmal etwas im DVBViewer/DM abgeändert, weil es bei einem Anwender nicht richtig lief, und nach dem nächsten Release kamen dann die aus der Änderung resultierenden Probleme bei X anderen Anwendern zum Vorschein...

 

Link to comment

Ich konnte mir schon denken, welche Reaktion jetzt von dir kommt. Dann lass dir gesagt sein, dass ich sehr wohl über mein großes Setup hinaus schaue im Gegensatz zu dir/euch. Da ich von - bis aber alles abdecken kann, kann ich sehr wohl gewisse Dinge einschätzen.

Ihr habt nur Astra im Auge. Aber die Satellitenwelt ist vielfältiger, das ist ja das gute. Es kann auch nicht so schwierig sein - vielleicht irre ich mich aber - eine kleine Satellitendrehanlage sein Eigen zu nennen, wenn man ein Programm weltweit vertreibt, um über den Astra-Tellerrand zu schauen.

 

Ich kann aber schon die Meinung nachvollziehen, dass bei einer Korrektur wiederum an anderer Stelle Probleme auftreten könnten. Aber nur Versuch macht bekanntlich klug. Deshalb gibt es ja auch Beta-Versionen.

 

Eine Antwort auf die perspektivische Bit-Anzeige in der DVBSource hast du noch nicht gegeben. Aber okay, geschenkt.

 

 

51 minutes ago, nuts said:

Was man mal noch probieren könnte: Läuft es mit dem madVR Videorenderer besser?

 

Hi nuts,

 

danke. Den hatte ich schon mal testweise in Betrieb, aber leider keine Besserung damit, da es ja ein Programm-Problem ist und vermutlich an nichts anderen liegt, obwohl das von Anfang an unterstellt wurde.

 

Im Gegensatz zu Grigas sarkastischer Bemerkung, was die anderen Programme angeht, sage ich mal, dass DVB Dream auch öfters zickig ist (mehr als der DVBViewer) und auch mal abkackt. Probleme bei der Darstellung von Kanälen mit vermeintlich kruden Daten hat es aber kaum.

 

Der user nevcairiel war das letzte Mal 2015 hier aktiv. Was soll der bewirken? Noch einmal ... wenn es an anderer Stelle funktioniert, warum soll es dann am LAV liegen. Für einen Nicht-Programmierer nicht so recht nachvollziehbar.

 

 

1 hour ago, nuts said:

wobei es natürlich interessant wäre wie die anderen Programme diesen Fall behandeln?

 

Ja, genau darum geht es eigentlich.

 

 

Link to comment
11 minutes ago, marcello64 said:

Ihr habt nur Astra im Auge.

 

Du hast keine Ahnung, was bei der DVBViewer-Programmierung alles zu berücksichtigen ist und was wir alles im Auge haben (müssen). Mal direkt gesagt: In der Hinsicht kannst du nicht mitreden.

 

12 minutes ago, marcello64 said:

wobei es natürlich interessant wäre wie die anderen Programme diesen Fall behandeln?

 

Diverse Programme verzichten wahrscheinlich auf die Überprüfung der Marker Bits bzw. lassen dem Sender die Fehler durchgehen. Wozu soll man sich auch an technische Standards halten...

 

Im Anhang ein kleines Plugin - ein schnell zusammengezimmerter Abkömmling des Stream Patcher Plugins. Es patcht gnadenlos die Video/Audio/Teletext PES Header eines jeden im DVBViewer/DMS empfangenen TV/Radioprogramms auf die richtigen Marker Bits,  egal ob sie falsch oder bereits richtig sind. Bei richtiger Anwendung sind dann auch Aufnahmen ISO-konform.

 

Das Plugin hat kein UI, taucht also nicht im Plugins-Menü auf. Es gelten die üblichen Regeln für DVBViewer / DMS Plugins - mehr dazu im Wiki. Die Benutzung erfolgt auf eigenes Risiko.

 

PatchMarkerBits.zip

  • Like 1
Link to comment
22 minutes ago, Griga said:

Du hast keine Ahnung, was bei der DVBViewer-Programmierung alles zu berücksichtigen ist und was wir alles im Auge haben (müssen). Mal direkt gesagt: In der Hinsicht kannst du nicht mitreden.

 

Da hast du vollkommen Recht, was die Programmierung angeht - habe auch nie etwas anderes behauptet. Es ging meinerseits um die Empfangsmöglichkeiten und um das Testen was geht und was nicht.

 

Ansonsten funktioniert dein Plugin auf Anhieb, mit allen Rendereren. Danke. Ist vielleicht auch bei anderen Kanälen hilfreich und kann ja jeder Zeit wieder deaktiviert werden.

Edited by marcello64
Link to comment
23 minutes ago, marcello64 said:

Es ging meinerseits um die Empfangsmöglichkeiten

 

Mir auch. Abgesehen von DVB-T/C: Hast du dich schon mal mit ISDB befasst (japanischer Standard, auch in Afrika und Südamerika verwendet), einschließlich Untertiteln mit japanischen Schriftzeichen? Oder mit ATSC (USA, Mexico, Korea)? Soviel zu "Ihr habt nur Astra im Auge"... wenn sich alle Anbieter an internationale Standards halten würden, wären alle Sat-Positionen auf gleiche Weise empfangbar. Ob Astra oder TürkSat oder NilSat oder HispaSat wäre egal.

 

Es gibt aber immer wieder Ausreißer, die sich nicht an die Regeln halten, das ist das Problem. TRT 4k verletzt sehr grundlegende Regeln (ISO/IEC 13818-1), die allgemein für alle Empfangsarten bzw. Transportströme mit Video/Audiodaten gelten, d.h. wenn ich da etwas ändere, wirkt das quasi globalgalaktisch...

 

Link to comment
4 hours ago, marcello64 said:

Der user nevcairiel war das letzte Mal 2015 hier aktiv. Was soll der bewirken? Noch einmal ... wenn es an anderer Stelle funktioniert, warum soll es dann am LAV liegen. Für einen Nicht-Programmierer nicht so recht nachvollziehbar.

Nur zur Info, es handelt sich hierbei um den Entwickler von LAV.

Link to comment
3 hours ago, Griga said:

Es gibt aber immer wieder Ausreißer, die sich nicht an die Regeln halten, das ist das Problem. TRT 4k verletzt sehr grundlegende Regeln (ISO/IEC 13818-1), die allgemein für alle Empfangsarten bzw. Transportströme mit Video/Audiodaten gelten, d.h. wenn ich da etwas ändere, wirkt das quasi globalgalaktisch...

 

Mit dem entfernbaren Patch oder Plugin ist doch einigen geholfen. Allen kannst du es eh nicht recht machen; mir würde schon Europa reichen ?, da die Kanäle der anderen genannten Kontinente hier kaum empfangbar sind und da diejenigen bzw. ein großer Teil aus Fernost, Afrika oder Asien sich massenhaft rühmt, gecrackte DVBViewer-Versionen zu nutzen -  ich schrieb es schon einmal. Das Problem scheint aber nicht behebbar zu sein; geht ja anderen ja auch so.

 

 

39 minutes ago, spachti said:

Nur zur Info, es handelt sich hierbei um den Entwickler von LAV.

 

Ja spachti, ich habe auch gesucht und gefunden, bloß dass LAV nicht ursächlich verantwortlich dafür war/ist.

Link to comment
  • 10 months later...

Hallo,

 

alle Jahre wieder ... vielleicht hat Griga noch mal Lust darauf zu schauen. Ist ein UHD-Schnipsel einer Sportübertragung, der wieder nicht konform zu sein scheint. Sonst hat der PatchMarkerBits solche Fehler ausgeglichen. Dieses Mal nicht.

Die PatchMarkerBits-DLL habe ich nach wie vor im Pluginverzeichnis des Programmordners und nicht im Pluginverzeichnis des Config-Ordners. War doch richtig?

 

173 MB Test-File

 

MfG

Link to comment

Wies aussieht hast du ein Xenon am werkeln. Beim LAV Video Filter lass mal alles an GraKa beschleunigung weg und lass den Prozessor alles erledigen. Alles auf none einstellen beim LAV. Bei mir hats funktioniert. Die Prozessor last erhöht sich auf 50-60% aber es läuft ruckelfrei. (Ryzen 1800x)

Link to comment

Hallo,

 

ja das stimmt, ich habe einen Xeon am werkeln. Ich werde testen. Morgen kommt das Feed noch einmal. Kannst du mir mal erklären, worin das Problem beim Xenon liegt?

Edited by marcello64
Link to comment
15 hours ago, marcello64 said:

Ist ein UHD-Schnipsel einer Sportübertragung, der wieder nicht konform zu sein scheint.

 

Sowohl der Video- als auch der Audio-Stream enthalten eine Riesenmenge Diskontinuitäten, wie man leicht mit dem TransEdit Analyzer feststellen kann. Schon von daher ist das kaum abspielbar.

 

P.S. Selbst wenn man die TS Verpackung entfernt, damit die Diskontinuitäten ignoriert, den reinen Audio Elementary Stream herausholt und ihn als MP2-Datei abspielt, hört man nur Digital Noise. Der Dateiinhalt ist schlicht hochgradig kaputt, warum auch immer...

 

Edited by Griga
Ergänzung
Link to comment

Ja Griga, ich hatte auch mit TransEdit Analyzer vorher die vielen Diskontinuitäten gesehen und hoffte doch, dass dein Patch das wie bei den kruden UHD-Übertragungen im vorigen Jahr bereinigen kann. Das war es ja ähnlich, aber die Fehleranzahl erheblich geringer. Im DVBViewer hatte ich Pixelmatch und in DreamDVB zwar ein Bild, aber Ruckler und teilweise Zeitlupen- und Standbilder. Dann habe ich mal nur mit dem TSReader mitgeschnitten, da war im Anschluss das Abspielbild dem Anschein nach fehlerfrei. Diese Aufnahme habe ich dann mit einem Tool mit möglichst Originalparametern in mp4 gewandelt und dies läuft jetzt auch auf der Dreambox zumindest sicht- und hörbar fehlerfrei.

 

Original-TSReader-Aufnahme-UHD-71Mbits-466 MB

 

in-4:2:0-konvertietes-MP4-File-1,2 GB

 

Was ich nicht verstehe ist, dass el34 oben schreibt mein zerhacktes erstes Test-File fehlerfrei zum Abspielen mit deaktivierter GPU-Unterstützung gebracht zu haben. Oder ich habe ihn falsch verstanden. Außerdem noch mal die Frage, was könnte der Xenon für eine negative Rolle spielen? Jedenfalls klingt das so. Oder ist eher gemeint, dass der Xenon das auch ohne GPU-Unterstützung schaffen könnte/müsste?

 

 

Link to comment
On 6/3/2019 at 4:09 PM, marcello64 said:

ich hatte auch mit TransEdit Analyzer vorher die vielen Diskontinuitäten gesehen und hoffte doch, dass dein Patch das wie bei den kruden UHD-Übertragungen im vorigen Jahr bereinigen kann.

 

Da fehlen einfach massenhaft Daten. Die kann kein Patch wie auch immer herbeizaubern. Kaputt ist kaputt. Welche Meinung soll man dazu noch haben?

 

Link to comment

Ich meinte nicht das erste komplett kaputte File, sondern das: Original-TSReader-Aufnahme-UHD-71Mbits-466 MB

 

Das hatte ich mit dem TSReader aufgenommen und abspielen lässt es sich bspw. mit dem Media Player Classic und anderen fehlerfrei. Wenn ich die Datei in TransEdit ziehe, startet sie, aber das Abspielen ist verlangsamt und ab und zu ruckelt es. Ich habe jetzt auch erst gesehen, dass bei TransEdit-Version der Costum-Renderer nicht mit in der Preview-Auswahl ist. Hat das eine Bewandtnis?

 

 

Link to comment
On 6/8/2019 at 10:44 PM, marcello64 said:

Ich meinte nicht das erste komplett kaputte File, sondern das: Original-TSReader-Aufnahme-UHD-71Mbits-466 MB

 

Das Problem bei der Aufnahme ist ein ungewöhnliches HEVC-Profil: Range Extensions Profile Level 5.1, soweit ich das herausfinden konnte. Die Header Info-Funktion des TransEdit Analyzers kann das noch nicht anzeigen - habe ich erst vor kurzem ergänzt.

 

Bei dem Profil werden HEVC-Features verwendet, die Decoder eventuell nicht beherrschen. Das gilt eindeutig für den Lentoid und den Cyberlink-Decoder, mit denen ich eine softwaremäßige Dekodierung probiert habe, ebenso für den Hardware-Decoder meiner Geforce GT 1030. FFmpeg basierte Decoder kriegen es (softwaremäßig) hin. Dazu gehört auch der LAV Video Decoder, der jedoch in der 32-Bit-Version zu langsam ist.

 

On 6/8/2019 at 10:44 PM, marcello64 said:

Ich habe jetzt auch erst gesehen, dass bei TransEdit-Version der Costum-Renderer nicht mit in der Preview-Auswahl ist. Hat das eine Bewandtnis?

 

Der Custom EVR dient vor allem der Darstellung des DVBViewer OSDs und wird in TransEdit nicht benötigt.

 

Link to comment
vor 2 Stunden schrieb Griga:

 

Das Problem bei der Aufnahme ist ein ungewöhnliches HEVC-Profil: Range Extensions Profile Level 5.1, soweit ich das herausfinden konnte. Die Header Info-Funktion des TransEdit Analyzers kann das noch nicht anzeigen - habe ich erst vor kurzem ergänzt.

 

Bei dem Profil werden HEVC-Features verwendet, die Decoder eventuell nicht beherrschen. Das gilt eindeutig für den Lentoid und den Cyberlink-Decoder, mit denen ich eine softwaremäßige Dekodierung probiert habe, ebenso für den Hardware-Decoder meiner Geforce GT 1030. FFmpeg basierte Decoder kriegen es (softwaremäßig) hin. Dazu gehört auch der LAV Video Decoder, der jedoch in der 32-Bit-Version zu langsam ist.

 

 

Der Custom EVR dient vor allem der Darstellung des DVBViewer OSDs und wird in TransEdit nicht benötigt.

 

 

Der MainConcept HEVC Dekoder (Softwaredekodierung) zeigt Bilder, nur ist mein Rechner viel zu langsam.

Link to comment
  • 1 month later...

Ich habe noch etliche solcher Aufnahmen, die sich im DVBViewer nicht in Echtzeit halbwegs fehlerfrei darstellen bzw. aufnehmen lassen. Die Aufnahmen des TSReader sind dagegen immer brauchbar und lassen sich auch im DVBViewer  manchmal wie bei diesem Schnipsel korrekt, manchmal aber nur stark verlangsamt einer Zeitlupe ähnelnd darstellen.

 

Fehlerhafte Aufnahme DVBViewer

 

Fehlerfreie Aufnahme TSReader

 

GPU ist nach wie vor eine GTX 1080 und CPU ein Xeon E5-1650 v4 3600 MHz.

 

Link to comment

Sind beide Aufnahmen mit dem selben DVB-Gerät/Tuner durchgeführt worden? Falls ja, lief bei beiden gleichzeitig die Wiedergabe? Das könnte den Unterschied ausmachen...

 

P.S. Ich lösche hier mal zwei "persönliche" Anmerkungen raus, die nichts zur Klärung der Sachlage beitragen... :)

 

Link to comment

Die Aufnahmen sind unmittelbar hintereinander gemacht worden. Nichts lief jeweils parallel, das Feed war fta ... ich hätte es mal mit TransEdit testen sollen, da es ja fta war - da habe ich in dem Moment nicht dran gedacht. Das Feed war "nur" 8 bit und 4:2:0 und nicht 16APSK, deshalb wunderte mich, dass es auch da mit dem Viewer solche Probleme gab. Bei 10 bit 4:2:2 und hoher Datenrate streiken auch einige Videoschnittprogramme, bei 8 bit aber nicht. Die hohe Datenrate bliebe dann als Hauptverursacher übrig.

 

Im TSReader hatte ich den Stream zum VLC-Player an, im DVBViewer logischerweise die Wiedergabe ... ich wollte ja eigentlich gucken und testen.

 

Ich könnte das nächste Mal zudem im Viewer, nachdem ich kurz das zerhackte Bild sehe, die Wiedergabe deaktivieren und dann aufnehmen. Ich glaube aber nicht so recht, dass es daran liegt. Aber ich teste.

 

 

Link to comment

Ich habe jetzt mal bei der gleichen Übertragung mit dem DVBViewer mit Wiedergabe-Aus geschaut und aufgezeichnet. Hat sich nichts verändert. Bild vertikal vermatscht. Was auffällt ist, dass zu Beginn des Einschaltens die ersten  Sekunden okay sind. Erst dann fängt der vertikale Matsch an.

 

TSReader, DreamDVB und VLC lassen sich fehlerfrei ansehen und aufnehmen. Das ist eine einfache 8 Bit-DVB-S2/h.264-Aufnahme in 4:2:0. Kein UHD/HEVC. Der einzige Unterschied zu funktionierenden Aufnahmen ist die hohe Symbol- und Datenrate. An etwas anderem kann es jetzt fast nicht mehr liegen. Das sollte doch behoben werden können?

 

DVBViewer-Wiedergabe-AUS-Fehler

 

Fehlerfrei TSReader

 

DVBDream fehlerfrei

 

VLC-Aufnahme fehlerfrei

Link to comment

Verwenden tue ich die TBS 6903/6983/Prof 8000. Die Symbolrate der Pferderennen war jedes Mal 40.000. Was ich dir per PN geschickt habe war SR 17.000, das erste hier verlinkte

SR 30.000.

 

Feste Transponderdaten kann ich dir nicht geben, das es sich um Feeds handelt. Manchmal aber über Tage mit den gleichen Parametern. 3w bspw. erfordert relativ große Antennen, mindestens 180, besser größer ... das wirst du nicht empfangen können.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...