Die kurze Antwort
Im lokalen Chrome-Versuch meldeten sechs Dateifälle ein Bild und erreichten das Ende. Ein ProRes-Fall erreichte ebenfalls das Ende, meldete aber null Bildmaße, null Videobilder und keinen Bild-Callback. Ein absichtlich gekürztes MP4 scheiterte trotz Containerprognose „maybe“. Prüfe Bild, Ton und Zielverarbeitung getrennt: Endung, Prognose und Ende der Medienzeitleiste schlossen die Videoprüfung nicht ab.
Das nimmst du mit
- Eine künstliche Quelle wurde zu acht verwandten Fällen, nicht zu acht unabhängigen Creator-Videos.
- Eine abgeschlossene Medienzeitleiste kann fehlende Bildhinweise verdecken.
- Verschobene MP4-Metadaten veränderten Startbeobachtungen, nicht die gespeicherten Paketinhalte.
Die Frage: Was belegt eine lokale Wiedergabeprüfung?
Ein Ablauf kann eine Datei annehmen, ihre Metadaten lesen und die Zeitleiste beenden, ohne das benötigte Zuschauerergebnis zu sichern. Wir prüften diese engeren Schritte mit eigenem künstlichem Material. Dafür brauchte es weder private Videos noch Konto oder bezahlten Anbieter. Kein Fall wurde auf LinkedIn hochgeladen; menschliches Verständnis wurde nicht gemessen.
Die Quelle zeigt vier Sekunden bewegtes Testmuster und 440-Hz-Ton, 480 × 270 Pixel bei 24 Bildern je Sekunde. Acht feste Fälle umfassen H.264/AAC-MP4 mit spätem Index, dessen Faststart-Kopie ohne Neucodierung, H.264 4:4:4, HEVC 10-Bit, VP9, AV1, ProRes und ein absichtlich auf die erste Hälfte gekürztes MP4. Letzteres ist eine beschädigte Prüfeingabe, kein gültiger Codecvergleich.
Fälle festlegen, Werkzeugfehler erhalten, ganze Matrix ausführen
Fallliste, Quellrezept und ursprüngliches Messprogramm wurden vor dem ersten Codierungsversuch gehasht. Dieser erzeugte alle acht Dateien, konnte aber Puppeteers fehlenden Standard-Chrome nicht starten. Der unvollständige Versuch bleibt erhalten. Danach wurde die Werkzeugänderung v1.1 für den vorhandenen Chrome-Browser eingefroren. Fälle, Codecargumente und Fristen blieben gleich. Browser oder Abhängigkeiten wurden nicht heruntergeladen.
Beide vollständigen korrigierten Läufe nutzten Node 24.21.0, FFmpeg 9.0.2, Puppeteer 25.15.0 und Chrome 156.0.8078.74 unter macOS/arm64. Jede Datei erhielt einen frischen isolierten Browserkontext mit stummer Wiedergabe. Lauf zwei kehrte die Versuchsreihenfolge um. Je Matrix gab es acht normale lokale Versuche und zwei zusätzliche gedrosselte MP4-Paarversuche: zehn je Lauf, zwanzig insgesamt. Das sind keine zwanzig Geräte oder unabhängigen Stichproben.
Alle acht Fälle mit beiden gewöhnlichen Versuchen
„Bildhinweise“ meint die protokollierten Maße, den ersten Bild-Callback, Bildzähler und das Ende. Die Bezeichnung beschreibt Messwerte, kein menschliches Qualitätsurteil. P08 ist absichtlich beschädigt und nicht zur Veröffentlichung gedacht. Vier zusätzliche gedrosselte Paarversuche stehen vollständig im CSV/Archiv.
| Originaldatei | Containerprognose | Bildmaße je Lauf | Gemeldete Bilder | Ergebnis beider Läufe |
|---|---|---|---|---|
| P01 · H.264/AAC, später MP4-Index | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Bildhinweise und Ende |
| P02 · Dasselbe Paketmaterial, MP4-Faststart | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Bildhinweise und Ende |
| P03 · H.264 4:4:4/AAC, MP4 | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Bildhinweise und Ende |
| P04 · HEVC 10-Bit/AAC, MP4 | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Bildhinweise und Ende |
| P05 · VP9/Opus, WebM | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Bildhinweise und Ende |
| P06 · AV1/Opus, WebM | maybe / maybe | 480 × 270 / 480 × 270 | 96 / 96 | Bildhinweise und Ende |
| P07 · ProRes/PCM, MOV | leer / leer | 0 × 0 / 0 × 0 | 0 / 0 | Ende ohne Bildhinweise |
| P08 · Absichtlich abgeschnittenes MP4 | maybe / maybe | 0 × 0 / 0 × 0 | 0 / 0 | Medienfehler |
Bildmeldungen neben dem Endereignis lesen
P01–P06 erreichten in beiden gewöhnlichen Versuchen das Ende und meldeten 480 × 270 Pixel, 96 Videobilder sowie einen ersten Bild-Callback. P07 ProRes erreichte vier Sekunden und ended, meldete aber beide Male 0 × 0 Bildmaße, 0 Videobilder und keinen Callback. Wegen stummer Wiedergabe wurde kein Ton angehört. Eine erfolgreiche Bildwiedergabe ist damit nicht belegt.
Unabhängig davon decodierte FFmpeg aus jeder der sieben unbeschädigten Dateien 96 Videobilder, auch aus ProRes. Die Aussage bleibt damit eng: Die Quelle enthielt decodierbares Video; der aufgezeichnete Browserweg meldete dafür kein Bild. Die beschreibende Tabellenbezeichnung verbindet protokollierte Signale. Sie ist weder wahrgenommene Qualitätsnote noch Aussage über alle Browser, Geräte oder Plattformen.
| Fälle mit beiden erhaltenen Läufen | Tatsächliche normale Wiedergabehinweise | Einordnung |
|---|---|---|
| P01–P06: sechs Fälle | Ende, Maße, 96 gemeldete Bilder und erster Callback | Bildhinweise in dieser Umgebung |
| P07: ein ProRes-Fall | Ende bei 4 s; 0 × 0; 0 Bilder; kein Callback | Ende ohne bestätigte Bildhinweise |
| P08: ein beschädigtes MP4 | Medienfehler 4; kein geladenes Bild | Beschädigter Fall erhalten, nicht entfernt |
Eine Containerprognose prüfte nicht die tatsächlichen Bytes
canPlayType wurde nur mit dem Container-MIME-Typ aufgerufen, ohne Codeczeichenfolge. MP4-Fälle lieferten „maybe“, auch die absichtlich abgeschnittene Datei. Diese meldete danach Medienfehler 4 und lud kein Bild. Die Prognose hatte keine vollständige brauchbare Datei untersucht oder bestätigt.
Für den ProRes-Fall war die QuickTime-MIME-Prognose leer. Seine Zeitleiste lief dennoch ohne protokollierte Bildhinweise weiter. Fasse Typvorhersage, Metadaten, playing, Bild-Callback und ended nicht zu einem grünen Zustand zusammen. CSV und Ereignisprotokolle erhalten die tatsächlichen Werte einschließlich fehlender Angaben.
Das kontrollierte Metadatenpaar änderte Startwerte, nicht Paketinhalte
P01 und P02 umfassen jeweils 287.147 Bytes. Die Hashwerte der gespeicherten Bild-/Tonpaketfolgen und der unabhängig decodierten Videobilder stimmen überein. Der MP4-Index moov beginnt beim späten Index an Byte 283.043, bei Faststart an Byte 32. Beide Dateien lieferten 96 decodierte Bilder. Verglichen wird Indexplatzierung, nicht die Abstimmung zweier verschiedener Encoder.
Bei der nominellen 64-KiB/s-Prüfung lag loadeddata über beide Läufe bei 972,5/990,8 ms für den späten Index und 534,3/621,8 ms für Faststart. Der Server forderte 4-KiB-Schreibvorgänge mit 62,5-ms-Timer und unterstützte Bytebereiche. Das sind lokale Beobachtungen, keine kalibrierte Internetgeschwindigkeit oder allgemeine Prozentverbesserung. Decoderstart, Zeitplanung, Zwischenspeicher außerhalb des isolierten Kontexts und Bereichsanfragen können mitwirken.
| Kontrollierte Eigenschaft | Später Index P01 | Faststart P02 |
|---|---|---|
| Dateibytes | 287.147 | 287.147 |
| moov-Position | 283.043 | 32 |
| Paketinhaltfolge | Gesicherter Hash | Derselbe Hash |
| Nominell gedrosseltes loadeddata, Lauf 1 | 972,5 ms | 534,3 ms |
| Nominell gedrosseltes loadeddata, Lauf 2 | 990,8 ms | 621,8 ms |
Die Grenzen zwischen Exportversuch und Plattformaussage erhalten
Alle acht Ausgabedatei-Hashes stimmten über beide vollständigen Codierungsläufe überein. Wiedergabezeiten nicht: Das erste normale P01-Ergebnis meldete 160 ms bis loadeddata, das zweite 14,4 ms. Bewahre beide statt des schnelleren Einzelwerts. Kleine lokale Dateien, künstliches Muster, verschiedene Codeceinstellungen und ein Rechner ergeben keine Rangliste tatsächlicher Kompressionseffizienz oder wahrgenommener Qualität.
Byte-Zwischenwerte bedeuten vom Server angebotene Bytes beim Eintreffen der loadeddata-Meldung, keine genau im Bildmoment beim Zuschauer empfangene Menge. Überlappende Bereichsanfragen können mehr als eine Dateigröße ergeben. Ein Bild-Callback prüft weder jedes Pixel noch Sprachbedeutung. LinkedIns eigene Hilfe warnt gesondert vor möglichem Upload mit scheiternder ProRes-Verarbeitung; dieser Plattformschritt wurde hier nicht untersucht.
Aus den vollständigen Belegen eine bessere Vorprüfung machen
Bewahre die Quelle, erkenne tatsächliche Spuren und prüfe die vollständige lokale Wiedergabe. Kontrolliere Bildmaße und sichtbaren Inhalt neben Zeitfortschritt, anschließend Ton, Untertitel und Schluss. Bei neuem Export werden geänderte Einstellung und neue Datei festgehalten. Nach echter Veröffentlichung wird der verarbeitete Beitrag gesondert geprüft.
Das Archiv enthält sämtliche Quellen/Ausgaben über eine Zuordnung zu Byte-Hashes, beide vollständigen Berichte, Befehle, Diagnosen, Paket-/Bildhashes, Programmcode und unvollständigen Werkzeugversuch. Nur bytegleiche Duplikate wurden zusammengeführt, keine Fehlerergebnisse entfernt. Nutze die versionierten Anweisungen und rechne mit umgebungsabhängigen Wiedergabewerten. Das sind eigene Dateibelege, keine Leserpräferenz, Barrierefreiheitszertifizierung oder Kundenwirkung.
Quellen & Produktinformationen
Produktangaben beziehen sich auf den Stand dieser Veröffentlichung. Externe Funktionen und Oberflächen können sich ändern.
