216 replies to this topic

[mrbeam]

Worden de nieuwsuitzendingen van deze zenders ondertiteld?

Hoef ik niet uren te zoeken naar programma's die worden ondertiteld, zodat ik het makkelijker kan reproduceren?

Edited by mrbeam, 24 March 2014 - 14:42.

[mrbeam]

Na wat zoeken gevonden.

Op txt 201 en volgend staat een rode "t" achter elk programma wat wordt ondertiteld.

[doglover]

Ja ze worden ondertiteld, maar Nieuwsuitzendingen zijn geen goede uitzendingen om het synchroon lopen van de ondertitles te beoordelen.  Behalve dan in het eerste overzicht van de nieuwslezer, wanneer hij/zij de hoofdpunten aankondigd.

 

Willy

[WanWizard]

Ik denk dat hier op een enorme manier op verschillende momenten langs elkaar gepraat wordt. Dus maar even terug naar de basis:

 

Er zijn twee soorten van subtitles: DVB subtitles, die in de vorm van een bitmap worden verzonden, en Teletext subtitles. Van beide kun je in een uitzending verschillende smaken hebben.

 

DVB subtitles kunnen uitsluitend door Enigma zichtbaar gemaakt worden, via de subtitle functie (subtitle knop, audio-geel, of geel-geel, afhankelijk van de box). Voor teletekst subtitles heb je twee mogelijkheden. Op de ouderwetse manier, door naar teletekst te gaan, en in teletekst te kiezen voor pagina 888. Of wederom via de subtitle functie. In het eerste geval worden de teletekst subtitles verwerkt door de tuxtxt plugin, in het tweede geval door Enigma zelf.

 

Alle features die in de image zitten ten aanzien van delay en zo werken uitsluitend op de Enigma versie, tuxtxt heeft daar geen flauw benul van en doet daar niks mee.

 

Nu terug naar de discussie van vandaag.

 

Ik vraag nadrukkelijk naar wat je precies doet. Dan heb je het eerst over teletekst (waarbij het me niet duidelijk is welk van beide methodes je gebruikt, wat je precies doet, wat je verwacht dat er gebeurd, en wat er werkelijk gebeurd), en later heb je het over DVB subtitles (want is compleet andere techniek is). En vervolgens geef je een lijstje kanalen waarop het mis zou gaan, maar op deze kanalen zijn helemaal geen DVB subtitles aanwezig (die worden in NL/BE zelden of nooit gebruikt).

 

Vervolgens zeg je dat het op VTM wel werkt, en daarvan had ik al gezegd dat ik had vernomen dat M7 al met de zenders aan tafel zit, en dat VTM daar het probleem al had opgelost, en dat dit voor de anderen in de komende maanden gaat gebeuren, dus dat men er mee bezig is.

 

En dan blijf jij volharden dat OpenPLi hier een partij in is?

 

Als je zo'n opname in detail bekijkt, dan zie je gewoon dat er bij teletekst geen enkele vorm van timestamp wordt uitgezonden. Dat het live werkt, komt simpelweg omdat ze worden getoond op het moment dat ze binnen komen, en dat is toevallig blijkbaar (meestal) wel ok. Als je een opname afspeelt, dan is er een forse buffer, die het probleem van async aanleveren van de data vs sync afspelen moet oplossen (variatie in disk snelheid bv). Dit betekent dat de teletekst data veel te vroeg beschikbaar is, en aangezien er geen timestamps zijn, het afspelen ook te vroeg start. Hoe erg is afhankelijk van een aantal factoren, waarvan de grootte van de buffer er eentje is. VLC leest waarschijnlijk de file op een andere manier in, of werkt misschien met meerdere buffers, zodat het probleem daar minder zichtbaar is. Maar het is er wel.

 

Dat gezegd hebbende: de enige juiste oplossing is dus de teletekst subtitles voorzien van een correcte timestamp. En dat kan maar op 1 plaats gebeuren, namelijk op de plaats waar ze worden gegenereerd. Ze kunnen er achteraf niet worden bijverzonnen.

 

VTM is de eerste die deze boodschap heeft gesnapt, nu de rest nog.

[doglover]

Het niet gesynched zijn van de TT ondertitels is momenteel zichtbaar bij opnemen en afspelen van de opgenomen file.  Of ook zichtbaar bij gebruik van de timeshift functie.  Bij "live" kijken zijn de ondertitels correct.

 

1.  VTM HD is OK,  VTM SD is niet OK net als éénHD/SD, Canvas HD/SD, en Vier niet correct zijn.

2.  Bij History HD worden de normale Nederlandse ondertitels verstuurd als DVB.  Deze vertonen dezelfde fout als de TT - p888 ondertitels op éénHD/SD, Canvas HD/SD, VTM SD en Vier.

Dit zijn dus geen ondertitles voor doven en slechthorenden maar de gewone ondertitels.

 

Ik begrijp niet wat hier niet duidelijk aan  is.

 

Willy

Edited by doglover, 24 March 2014 - 18:07.

[WanWizard]

Het is me nog niet duidelijk op welke manier je naar TT subtitles kijkt.

 

Ik vermoed via teletekst, en dan pagina 888 kiezen. En daar valt niks mee te doen, en welk delay je ook instelt, die werken daar niet. Dus: teletekst vergeten, maar ze via de subtitle knop (of geel-geel, of audio-geel) selecteren. Je kunt in de setup die dingen stylen zoals je ze hebben wilt. En je kunt een delay instellen, waarmee je opnames wellicht wel (iets beter) bekeken kunnen worden.

 

Voor wat betreft het synchroon zijn live maar niet via een opname: daar heb ik net al van uitgelegd hoe dat komt. En wie dat op moet lossen.

 

Ik begrijp heel goed dat dit vervelend voor je is, maar ik snap niet zo goed wat je nu van ons verwacht dat we daaraan gaan doen?

[Rob van der Does]

Neem me niet kwalijk zeg: Willy heeft herhaaldelijk aangegeven dat het gaat om TT-ondertitels via de ondertitel knop.

[doglover]

Ik begrijp heel goed dat dit vervelend voor je is, maar ik snap niet zo goed wat je nu van ons verwacht dat we daaraan gaan doen?

 

Wat verwacht ik van OpenPli:

 

Via de ondertitel knop:

 

Hier is een voorziening voor het corrigeren van de timing in stappen van 0.5 sec.  Deze voorziening werkt niet op deze ondertitels.  Dit heb ik reeds herhaaldelijk aangegeven.

Kan OpenPli dit wel werkende maken.

 

Ontbreken van Timestamps:

 

Er wordt steeds gerefereerd naar het ITV probleem, want dat zou gelijkaardig geweest zijn.

Hiervoor is een oplossing bedacht.  Staat met zoveel woorden in de bijdragen in de discussie.

Waarom, kan dat dan niet voor dit probleem?

 

Duidelijk?

 

Natuurlijk verwacht ik niet je timestamps kunt bijzetten in de stream.  Dat moet ergens anders gebeuren.  Dat begrijp ik ook.

 

Willy

 

PS: En als het niet duidelijk was, ik kijk ondertitels via de ondertitel knop, niet via tuxtxt, want die zijn niet om aan te zien.

Edited by doglover, 24 March 2014 - 18:31.

[jeanclaude]

laat ik Willy even bijtreden : hij heeft al meermaals met handen en voeten duidelijk gemaakt wat het probleem is. Rechtstreeks zijn de ondertitels in synchro, neem de stream op en bekijk deze later en de ondertitels zijn niet meer in synchro, en dit spelleke duurt nu al méér dan een jaar (vroeger waren ze ook live "uit synchro", de laatste tijd werkt dit beter).

we begrijpen ook het probleem, er zijn geen timestamps.

Nogthans worden de ondertitels door bepaalde players wél correct getoond, bvb VLC. Bij PLi via geel-geel of via tuxtext 888 niet.

We begrijpen ook dat de ideale oplossing eigenlijk van de content providers zou moeten komen, of van m7, maar daar lopen we van het kastje naar de muur en krijgen we enkel de raadgeving om de recorder te resetten.

Misschien komt het ooit goed, de Britse onder andere zenders leren ons dat het mogelijk is, maar het ziet er wel naar uit dat we hier nog een tijdje moeten naar wachten.

 

daarom Willy's vraag aan het PLi team of hier nu echt geen "eigen" oplossing voor mogelijk is. Jullie hebben al delays voorzien die inwerken op "live" ondertitels, waarom kan er geen delay gemaakt worden voor het afspelen van opnames. Ik hoor allerlei redenen waarom het niet werkt "geen timestamps", "grote buffers", "async data" en zo meer, maar ik geen enkele reden waarom zo'n delay niet mogelijk is of waarom er niemand van PLi zich aan waagt. En als het technisch inderdaad niet zou mogelijk zijn, bon, dan moeten we maar wachten tot wanneer de content providers of m7 met een oplossing komen, we weten ook wel dat jullie geen tovenaars zijn.

 

een PLi oplossing om dit zééééér irritant probleem op te lossen zou bij veel gehoorgestoorden bijzonder dankbaar onthaald worden.

[ROMAN]

Dat is het nadeel van een kleine doelgroep. Er zijn maar heel weinig mensen die nederlandstalige ondertiteling gebruiken, wat dat betreft heb je gewoon best pech. Maar dat soort dingen heb ik ook wel eens.

Spijtig genoeg behoor ook ik tot die doelgroep    ... Ik kan technisch niets bijdragen bij deze discussie maar zou het enorm apprecieren dat de ondertiteling ook van de opgenomen programma's  synchroon zou verlopen.

 

Groetjes,

Roman

[Erik Slagter]

Als een van jullie, en ik suggereer het nog maar weer eens, een gesloten (niet-enigma)-ontvanger heeft en daarmee het probleem ook kan aantonen, dan sta je richting M7/VRT véél sterker, zeker als het een "bekend" merk is. Zodra men enigma of onbekend merk hoort, gaan de oren vaak dicht, heb ik geleerd.

[jeanclaude]

die vraag is gesteld in meerdere forums, maar we krijgen geen antwoorden terug, blijkbaar hebben we allemaal een unix ontvanger.......

[charlesduco]

Ik heb enkele dagen geleden wél ge-dvbsnoop-t via DVB-T én satelliet op de zender VRT Eén. Op DVB-T doet het synchronisatieprobleem zicht niet voor. Dus je mag stellen dat via DVB-T 100% correcte teletekst-informatie inclusief timestamps wordt uitgezonden.

 

Ik ben erin geslaagd om de overeenkomstige PES-streams van het teletekstsignaal van DVB-T en sat naast elkaar te leggen, maar mijn kennis van de DVB-technologie reikt nog niet zo ver om de data volledig te begrijpen en de oorzaak van dit probleem te isoleren.

Hieronder post ik alvast eens twee overeenkomstige PES-pakketjes die ik met de zoekfunctie van een teksteditor netjes heb kunnen filteren uit een groter bestand.

DVB-T

------------------------------------------------------------
PES-Packet: 00000480   PID: 4115 (0x1013), Length: 1288 (0x0508)
Time received: Fri 2014-03-21  19:04:10.785
------------------------------------------------------------
Packet_start_code_prefix: 0x000001
Stream_id: 189 (0xbd)  [= private_stream_1]
PES_packet_length: 1282 (0x0502)
    reserved1: 2 (0x02)
    PES_scrambling_control: 0 (0x00)  [= not scrambled]
    PES_priority: 0 (0x00)
    data_alignment_indicator: 1 (0x01)
    copyright: 0 (0x00)
    original_or_copy: 0 (0x00)
    PTS_DTS_flags: 2 (0x02)
    ES_rate_flag: 0 (0x00)
    additional_copy_info_flag: 0 (0x00)
    PES_CRC_flag: 0 (0x00)
    PES_extension_flag: 0 (0x00)
    PES_header_data_length: 36 (0x24)
    PTS:
        Fixed: 2 (0x02)
        PTS:
            bit[32..30]: 4 (0x04)
            marker_bit: 1 (0x01)
            bit[29..15]: 7736 (0x1e38)
            marker_bit: 1 (0x01)
            bit[14..0]: 4381 (0x111d)
            marker_bit: 1 (0x01)
             ==> PTS: 4548464925 (0x10f1c111d)  [= 90 kHz-Timestamp: 14:02:18.4991]
    stuffing bytes:
          0000:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0010:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff      ...............
    PES_data (private_stream_1):
        EBU data:
            data_identifier: 16 (0x10)  [= EBU data EN 300 472 (teletext)]

SATELLIET

 

------------------------------------------------------------
PES-Packet: 00000400   PID: 905 (0x0389), Length: 1288 (0x0508)
Time received: Fri 2014-03-21  19:03:50.807
------------------------------------------------------------
Packet_start_code_prefix: 0x000001
Stream_id: 189 (0xbd)  [= private_stream_1]
PES_packet_length: 1282 (0x0502)
    reserved1: 2 (0x02)
    PES_scrambling_control: 0 (0x00)  [= not scrambled]
    PES_priority: 0 (0x00)
    data_alignment_indicator: 1 (0x01)
    copyright: 0 (0x00)
    original_or_copy: 0 (0x00)
    PTS_DTS_flags: 2 (0x02)
    ES_rate_flag: 0 (0x00)
    additional_copy_info_flag: 0 (0x00)
    PES_CRC_flag: 0 (0x00)
    PES_extension_flag: 0 (0x00)
    PES_header_data_length: 36 (0x24)
    PTS: 
        Fixed: 2 (0x02)
        PTS:
            bit[32..30]: 2 (0x02)
            marker_bit: 1 (0x01)
            bit[29..15]: 19883 (0x4dab)
            marker_bit: 1 (0x01)
            bit[14..0]: 29599 (0x739f)
            marker_bit: 1 (0x01)
             ==> PTS: 2799039391 (0xa6d5f39f)  [= 90 kHz-Timestamp: 8:38:20.4376]
    stuffing bytes:
          0000:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
          0010:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff      ...............
    PES_data (private_stream_1):
        EBU data:
            data_identifier: 16 (0x10)  [= EBU data EN 300 472 (teletext)]

 

Hier de volledige bestanden, voor moest er iemand van de developers interesse hebben om dit probleem te doorgronden:

https://dl.dropboxus...7009/ttdvbt.txt

https://dl.dropboxus...87009/ttsat.txt

Daarnaast nog even melden dat OpenPLI ook niet perfect is, dat is ook geen schande. Maar je mag niet vergeten dat de timestamps(PTS) voor teletekst optioneel zijn in de officiële teletekst-specificatie. Met andere woorden: wie de telekst-standaard nauwgezet volgt, moet de ondertitels syncrhoon kunnen weergeven op basis van het tijdstip van uitzending(=Time received??) en dan is de PTS 90 kHz-Timestamp onbelangrijk.

En VLC Media Player doet dat dus wel perfect.

[jeanclaude]

ik denk dat de oorzaak van het probleem intussen wel goed gekend is. Daar staan we momenteel machteloos. We zoeken nu vooral naar alternatieve oplossingen. Iedereen die ons daarbij kan helpen zijn we zeer dankbaar.

[littlesat]

Dat vlc het perfect doet ligt meer aan de de hardware buffers die er niet zijn.. En vooral daar zit de pijn...

Door de vbr die erop zit is het vervolgens onmogelijk de boel met een fixed vertraging synchroon te krijgen... Je weet nooit hoeveel seconden in die buffers zit...

Edited by littlesat, 24 March 2014 - 19:28.

[jeanclaude]

ok, domme lekenvraag : als VLC het kan zonder hardwarebuffers, waarom zijn die dan nodig in PLi ? Kunnen die buffers er niet uitgehaald worden dan ?

[littlesat]

Omdat vlc die intel chip gebruikt om te decoderen... En een e2 box speciale hardware die in de broadcom controller zit...

[WanWizard]

Om duidelijker te zijn: alles op de PC (zoals VLC) verwerkt de stream in software. De STB's waar OpenPLi op draait verwerken die in hardware.

Je kunt daar vanuit de software maar beperkt invloed op uitoefenen.

[charlesduco]

Ik ben niet overtuigd van die stelling. Bij live ontvangst loopt alles goed, alleen bij opnames loopt het mis.

Conclusie: OpenPLI hanteert een foute werkwijze bij weergave van opnames en een correcte werkwijze bij weergave van live tv.

Edited by charlesduco, 24 March 2014 - 19:51.

[jeanclaude]

ok, dus enigma gebruikt de broadcom controller om de ondertitels te tonen, en daar hebben jullie geen invloed op, correct ? Dan is er toch nog iets wat ik niet begrijp : bij PLi kan ik vanalles instellen voor de ondertitels : grootte, plaats op het scherm, uitlijning....... Dit zijn display parameters. Worden die parameters ook door de broadcom chip afgehandeld, of zit die afhandeling bij PLi ? Jullie hebben toch een eigen ondertiteling afhandeling ? Kan er langs die kant nergens ingegrepen worden ?

ik begrijp dat het niet gemakkelijk is, en dat er geen eenvormige oplossing kan gevonden worden, maar ik zou er niet met inzitten om per bestand een aparte vertraging op te geven - als het maar werkt - en het hoeft niet perfect te zijn ook niet.