17 replies to this topic

[rocco99]

Waarom worden de gegeven van die bestanden niet in 1 bestand opgeslagen?

 

(1 de TS en het andere bestand de overige gegevens?)

[cobus]

misschien omdat dat niet kan ?

[littlesat]

Of omdat ooit iemand lang geleden dat zo verzonnen had...

[dAF2000]

Dit is voornamelijk een overblijfsel uit Enigma1 (de oudere ontvangers). Op deze manier kon je de oude opnames nog afspelen.

[Sateunis]

Misschien het overwegen waard om in PLI 4 alle bestanden samen te voegen tot een bestand.

Al komt dit de comptabiliteit met andere E2 ontvangers niet ten goede.

 

Ter info,

VDR gebruikte ook meerdere bestanden maar maakte voor elke opname een aparte directory aan.

Ik was hier geen fan van maar het heeft ook zijn voordelen.

Daarbij maakte VDR automatisch een hoofddirectory aan indien er een tweede opname van een zelfde serie volgde.

Hierdoor kreeg je een hoofddirectory met de naam van de serie en sub directory's van alle afleveringen.

 

Groet,

Sateunis

[WanWizard]

Ik denk dat dit nog niet zo eenvoudig is.

 

Je zult een compleet nieuw container formaat moeten implementeren, omdat je zowel data als metadata in een enkele file gaat opslaan. Je zult ook complexe update mechanismes voor die container moeten hebben, want een aantal van die files hebben dynamische data.

 

Dus persoonlijk zie ik het nog niet direct gebeuren.

[rocco99]

Je kan ook de TS en 1 bestand voor de overige data, zoals ik eerder zei. Geen idee of dit mogelijk is.

[dAF2000]

Je kan ook de TS en 1 bestand voor de overige data, zoals ik eerder zei. Geen idee of dit mogelijk is.

 

Vast wel, denk ik, maar dan vallen allerlei programmaatjes en plugins om. Kleine kans dat we het dus aanpassen.

[rocco99]

Het voordeel van al die kleine bestanden verkleint wel weer de kans op het deleten van het Meta bestand ipv. de TS in de verkenner. (natuurlijk bij detail weergave wel aan de bestandsgrote te zien)

[WanWizard]

Tja, als jij natuurlijk via de achterdeur op de box zit te rommelen, dan moet je wel weten waar je mee bezig bent.

 

Dit soort aanpassingen zal al zeker niet gebeuren om gebruikers tegen hun eigen stupiditeit te beschermen.

[christophecvr]

Wel als idee goed , .. maar echt onuitvoerbaar.

 

zie commentaar van :

WanWizard groot gelijk daar.

 

Maar ook vele plugins en .... Bovendien zal het uiteindelijke resultaat meer cpu power nodig hebben in media play fase.

[rocco99]

Tja, als jij natuurlijk via de achterdeur op de box zit te rommelen, dan moet je wel weten waar je mee bezig bent.

 

Dit soort aanpassingen zal al zeker niet gebeuren om gebruikers tegen hun eigen stupiditeit te beschermen.

 

Ik zie net dat je het ook aan de thumbnail kan zien, die van een video geeft immers een screenshot of pictogram an de ingestelde media player.

[MiLo]

't Staat al jaren op mijn "to do" lijstje om ze samen te voegen maar 't komt er maar niet van. CPU power is peanuts, gooi ze maar eens weg en kijk wat 't kost als de box voor elke skip een soort binary search moet doen. Valt reuze mee. Alleen snel spoelen werkt dan niet meer.

[Erik Slagter]

Je zou de metadata als een extra pid in de transport stream kunnen muxen. Beetje complex, maar zeker haalbaar. Dat zou erg mooi zijn. Of nog mooier, on-the-fly remuxen naar matroska. Het enige praktische probleem wat je dan hebt is dat de code in enigma geen grafische subs afspeelt vanuit mkv (= DVB subs). Ik zie daar een "leuk" projectje, voor iemand met veeeeel vrije tijd

[MiLo]

Zou ik met die pid nog kunnen "valsspelen" zodat 't eerste deel uit een soort header bestaat met daarin de info, een beetje ingepakt zodat de decoder verder niks mee doet?

Sowieso wordt pakweg 90% van de "sc" informatie niet gebruikt, dus 't kan ook stukken kleiner.

Een enkele file per opname is zeker het mooist.

[Erik Slagter]

Als de PID niet in de PMT genoemd wordt, zal enigma 'm niet aan de PID filter toevoegen en krijgt de decoder 'm nooit te zien

 

Waar ik alleen mee zit, je hebt op die manier geen enkele controle over waar het in de file terechtkomt. Truuks zoals die nu gebruikt worden waarbij de file offset gerefereerd wordt gaan dan niet meer werken.

 

On the fly remuxen naar matroska zou ik toch wel het mooist vinden, omdat die zelf al een heel goede index bijhoudt. Ik vraag me alleen af of mkvmerge (en de lib erbij) streaming spul kunnen muxen, waarbij de lengte niet vooraf bekend is. Misschien zou je links- of rechtsom aan het begin van de file ruimte moeten vrijhouden voor de index. Of de index komt achteraan de file, dat zou natuurlijk ook kunnen.

[WanWizard]

Dat maakt natuurlijk ook de huidige cut editor en aanverwanten obsolete, dus die moeten dan ook op de schop. En wat met encryped recordings, die bij afspelen terug de cam in moeten?

 

En hangt nogal wat vast aan zo'n aanpassing...

[Erik Slagter]

Daar staat tegenover dat als het een mkv wordt, je elke "willekeurige" editor op je PC kunt gebruiken.

 

De elementary streams neem je zo over, dus die mogen encrypted zijn. Het enige nadeel is dat je bij afspelen de stream niet meer zó de demuxer in kunt vrotten, je moet het eerst zelf (gstreamer) demuxen. Dat heeft ook wel weer nadelen. Dan zou je misschien nog beter on the fly kunnen omzetten van mkv naar transport stream.