216 replies to this topic

[jeanclaude]

@charlesduco : zoals ik het begrijp zal bij een live uitzending de broadcom chip de ondertiteling tonen van zodra deze uitgezonden wordt. De gebruikte buffers blijven hier "leeg".

Bij een opname echter wordt er "vooruit" gekeken in de stream en vullen de hardware buffers zich met informatie. Vervolgens "weetd" de broadcom chip niet meer wanneer die ondertitels moeten getoond worden, omdat de noodzakelijke timings ontbreken .....

[WanWizard]

Inderdaad, bij het afspelen van een opname (een TS file) wordt het hele circus as-is de broadcom chip in gepompt, exact zoals (en net zo als) het binnengekomen is. En dat "pompen" gaat asynchroon met het afspelen.

 

Als er geen timestamps aanwezig zijn zal de chip de subtitles richting TV gooien op het moment dat ze binnen komen. Dat gaat live nog redelijk goed (de variaties zijn er wel, maar minder zichtbaar), maar bij playback is dat dus afhankelijk van het tempo waarin de data aan de buffer wordt aangeleverd. En daar heb je niet al te veel controle over. En je wilt dat ook niet knijpen, want dan kun je stotterend beeld en pixelation krijgen, en daar zit ook niemand op te wachten.

[jeanclaude]

daar vreesde ik al voor. Maar hoe past die PLi ondertiteling daar nu in ? Want jullie veranderen vanalles aan die ondertitels. Gebeurt dit vóórdat de stream naar de broadcom chip gestuurd wordt, of wordt dat ook in die broadcom chip afgehandeld ?

[WanWizard]

Dan moet ik je doorsturen naar familie... Hogere C++ kunde is al 20 jaar niet meer aan mij besteed.

[jeanclaude]

laat ik een proefballonnetje opgooien : volgens mij leest PLi de datastream, haalt er de teletext stream eruit om deze deze te herformateren volgens de PLI subtitle instellingen, en dit wordt vervolgens terug in de stream geworpen en naar de broadcom chip gestuurd.

kan men op dit punt een time-stamp aan de teletext stream toevoegen, en wel de laatst geregistreerde timestamp van de video-stream, eventueel te verhogen met een instelbare delay ?

mogelijk of niet mogelijk ?

[Erik Slagter]

Je kunt er rustig van uit gaan dat als het simpel was geweest, dat het al lang anders was geïmplementeerd.

De datastroom is (iets vereenvoudigd):

pvr* -->
tuner -> demuxer* -> video-> video decoder*
            |  +---> audio-> audio decoder*
            +------> subs->  enigma -> osd

Alles waar een * bij staat is hardware van de broadcom SoC. De hele stroom van tuner naar demuxer naar video decoder, en van tuner naar demuxer naar audio decoder, daar zit enigma of wat voor software dan ook nooit tussen, dat zijn bits die over paden binnen de SoC lopen.

 

Je hebt dus op enig moment dat je in enigma een ondertitel binnenkrijgt, en als je daar een timestamp bij hebt, dan kun je die zolang laten wachten tot de timestamp gelijk is aan die van de video die op dat moment wordt gedecodeerd/afgebeeld (dat kun je opvragen aan de hardware). Als je geen timestamp op de ondertitel hebt, dan wordt het erg lastig. Ik zit al te denken aan het constructie waarbij je gaat meten wat de vertraging is tussen ontvangst (is ook het moment dat het de decoder in gaat) en afbeelding (door buffering) van video frames *). De buffering, dus vanaf het punt dat het de video decoder in gaat en tot het moment dat het beeld op tv staat, kan substantieel zijn, meerdere seconden en is ook nog eens sterk afhankelijk van of de bron de tuner is of een file (pvr device).

 

De feitelijke ellende is dus dat een deel in hardware gebeurt en een klein deel in software en beide hebben heel weinig invloed op elkaar.

 

EDIT *) ik bedenk me net dat je dan de hele video stream van de demuxer moet aftappen in software, niet echt handig.

Edited by Erik Slagter, 24 March 2014 - 22:08.

[WanWizard]

Subs gaan dus niet door de hardware. Zoals ik al schreef, ik moest hier afhaken (en ik zal het nu overlaten aan de heren techneuten ).

[jeanclaude]

ach, ik ben al tevreden als er maar over nagedacht wordt.

en gaat het niet, jammer, maar we hebben het toch geprobeerd. Dan is het wachten tot de content providers of m7 met een werkende oplossing komen voor dit probleem

[charlesduco]

Als iemand me zou kunnen vertellen wat er juist mis is met de timestamps van het teletekstsignaal die M7 meestuurt, kan de functie "subtitle delay when timing lacks" of "subtitle delay when timing is bad" aangepast worden zodat het probleem tenminste manueel kan opgelost worden.

[jeanclaude]

simpel : er zijn er geen.

in het schema van Erik is duidelijk te zien dat de audio/video stream rechtstreeks door de hardware wordt afgehandeld, via de broadcom chip. Ondertitels worden via de OSD van enigma aangestuurd. Aangezien enigma geen time-stamps heeft, weet deze niet wanneer de ondertitels exact moeten verschijnen.

nu dat ik daar eigenlijk over nadenk, de ondertitels gaan dus niet via de broadcom chip, dus dat hele verhaal met die hardware buffers gaat niet op ? Volgens het schema van Erik gaan de ondertitels via enigma, dus timestamps of geen timestamps, daar kunnen jullie dan toch een delay opzetten ?

[doglover]

Als iemand me zou kunnen vertellen wat er juist mis is met de timestamps van het teletekstsignaal die M7 meestuurt, kan de functie "subtitle delay when timing lacks" of "subtitle delay when timing is bad" aangepast worden zodat het probleem tenminste manueel kan opgelost worden.

 

Als dit zou kunnen graag, want deze werken nu niet op de zenders die we hier bediscussiëren.

 

Volgens het schema van Erik gaan de ondertitels via enigma, dus timestamps of geen timestamps, daar kunnen jullie dan toch een delay opzetten ?

 

Sluit ik mij volledig bij aan.  (manueel instelbare delay)

 

Willy

Edited by doglover, 25 March 2014 - 07:42.

[WanWizard]

nu dat ik daar eigenlijk over nadenk, de ondertitels gaan dus niet via de broadcom chip, dus dat hele verhaal met die hardware buffers gaat niet op ? Volgens het schema van Erik gaan de ondertitels via enigma, dus timestamps of geen timestamps, daar kunnen jullie dan toch een delay opzetten ?

 

Het probleem is de andere kant op. De (bijvoorbeeld TS) file wordt gelezen, uiteengerafeld, de audio en video wordt richting chip gestuurd (en die heeft de hardware buffer!), de subtitle data naar Enigma. Die gooit ze direct naar buiten (want geen timestamp) terwijl de A/V nog in de buffer van de chip zit (en daar best wel de nodige seconden kan zitten). En daarom zijn de subtitles te vroeg, en daarom kun je in de image een delay op de subtitles zetten.

 

Ik denk alleen dat die delay op dit moment alleen werkt als er uberhaupt timestamps zijn, maar dat weet ik niet zeker (terug naar de specialisten weer). En wellicht moet dat stuk dus bekeken worden (want het instellen van een delay is wel aanwezig).

[WanWizard]

In navolging hierop: het instellen van een delay werkt dus WEL, ook bij het afspelen van een opname. Zowel de code als een test bevestigen dat. Uiteraard alleen als je Enigma als renderer gebruikt, niet via tuxtxt.

 

Echter, je wordt er niet zoveel wijzer van. Door het bufferingsmechanisme, en de variable bitrate die de providers gebruiken, kun je dus geen enkele predictie maken over de delay die nodig is. En door de variabele bitrate is er dus ook een variable delay nodig, je kunt op geen enkele manier afleiden waneer welk frame op het beeld verschijnt, en wat de dus timing van de subtitle zou moeten zijn.

 

Het instellen van een delay (recent nog aangepast zodat je max. 20s kunt instellen) zorgt er dus hooguit voor dat de subtitles op een "minder fout" tijdstip kunnen verschijnen, maar goed krijg je het nooit.

[doglover]

Sorry Wanwizzard:  Bij mij werkt de delay dus niet.

Heb beide instellingen naar 20 seconden gezet, zoals in de screen shot te zien is.  Geen effect.

 

Versie van OpenPli:

Kernel version: 3.8.7 Firmware version: 2014-03-11 14:14:59 Gui version: 2014-03-05

 

Willy

 

 

PS: Er zijn zenders waar deze delay wel werkt.  Maar op éénHD/SD en de andere zneders die ik voordien genoemd heb dus geen effect van het installen van de delay.

Attached Files

•  screenshot.jpg   89.2KB   11 downloads

Edited by doglover, 25 March 2014 - 11:14.

[doglover]

Het instellen van een delay (recent nog aangepast zodat je max. 20s kunt instellen) zorgt er dus hooguit voor dat de subtitles op een "minder fout" tijdstip kunnen verschijnen, maar goed krijg je het nooit.

 

 

Hiermee zouden we al heel blij mee zijn.

 

Willy

[WanWizard]

Wat werkt er precies niet? De ingestelde delay heeft nul invloed? Of niet de invloed die je graag zou zien?

En je kijkt naar teletekst ondertitels via de subtitle knop/audio-geel/geel-geel ?

 

(gewoon even zorgen dat we allebei naar exact hetzelfde kijken).

[doglover]

Wat werkt er precies niet? De ingestelde delay heeft nul invloed? Of niet de invloed die je graag zou zien?

En je kijkt naar teletekst ondertitels via de subtitle knop/audio-geel/geel-geel ?

 

(gewoon even zorgen dat we allebei naar exact hetzelfde kijken).

 

Nul effect.

 

En je kijkt naar teletekst ondertitels via de subtitle knop/audio-geel/geel-geel ?  JA

 

Willy

[Rob van der Does]

Ik heb dat ook diverse malen geprobeerd: +20 en -20 hebben hetzelfde effect op deze zenders, namelijk geen.

[littlesat]

Een delay hierop kan niet werken... De zenders hebben allemaal vbr... Je kunt wel weten hoe groot de buffers zijn, maar je weet nooit hoeveel seconden erin zitten... Zeker met ongeveer 10 seconden delay wordt het gejitter nog groter....

Als iemand een oplossing en/of goede work-a-round heeft dan horen we dat heel graag...
Een ding vind ik wel vreemd. Ik had ooit de delay toen het eerder eens mis ging vergroot... Toen bleek dit enigszins te werken. Nu is er iets waarom het niet werkt...

Al met al is de hoofdoorzaak dat de bron het niet goed uitzendt...

Edited by littlesat, 25 March 2014 - 16:19.

[Erik Slagter]

VBR plus reordering van video frames ivm b frames.