Linux console mpeg splitter/joiner

[Verwijderd]

Voor een univ-project ben ik bezit met een distributed transcoding omgeving, maar dit vereist natuurlijk dat het oorspronkelijke mpeg (2, voorlopig enkel video) bestand wordt opgesplitst in verschillende stukjes.

Ben dus wat op zoek gegaan naar software die dit kan afhandelen, en kwam terecht bij mpgtx (mpgtx.sourceforge.net). Het programma heeft echter (naar mijn mening) een kleine bug waardoor het de video-stroom splitst voor het I-frame van de volgende GOP. Normaal zou dit correct zijn, ware het niet dat de frames in een andere volgorde worden opgeslagen dan dat ze worden afgespeeld. In mpeg2 zullen dus de laatste 2 B-frames na het I-frame liggen. De 2 laatste B-frames van het vorige stukje mpeg2 film wordt dus meegenomen naar het volgend stuk.

Aangezien dit problemen geeft bij het latere transcodeer- en join-werk ben ik dus op zoek naar een programma (non-gui, linux) dat in staat is de file te splitsen en rekening te houden met eventuele verschuivingen in de file....

Iemand enig idee?

[ Voor 6% gewijzigd door Verwijderd op 13-03-2005 07:27 ]

[Verwijderd]

Dat kan niet. Simpel. Je zult in je omgeving een workaround voor dit algemeen bekende probleem moeten inbouwen (bv. 'skip-last-i-frame', en dan handmatig een parser bouwen die na elke i-frame alleen nog b-frames doorstuurt en daarna stopt. Daarna vanaf en inclusief diezelfde i-frame naar de volgende client doorsturen). Dit vereist dus inderdaad moeite.

Waarheen transcode je eigenlijk? Distributed transcoding is een hel vanuit bitrate targetting gezien.

[Verwijderd]

Waarheen transcode je eigenlijk? Distributed transcoding is een hel vanuit bitrate targetting gezien.

Er wordt via ffmpeg getranscodeerd/gerecodeerd naar mpeg1; dus qua bitrate targetting is het niet zo een probleem aangezien ik gewoon alles in 1pass hercodeer. Het project gaat vooral over het distributed gedeelte, maar het zou natuurlijk leuk meegenomen zijn moest het eindresultaat een vloeiend film-fragment zijn.

De getranscodeerde stukjes hebben net zoals het oorspronkelijke fragment een gop-lengte van 12, de gops bestaan hier uit een I-frame gevolgd door 11 P-frames, en zijn bijgevolg volledig onafhankelijk van elkaar.

De stukjes worden gesplitst in blokjes van +/- 5MB, waar het laatste gop van het ene stukje ook wordt over genomen in het volgende stukje. Hiermee kunnen de blokjes onafhankelijk van elkaar worden getranscodeerd, en kan bij het joinen gewoon de laatste gop van elk fragment worden weggelaten... ware het niet dat ik in de problemen kom met die 2 extra frames.

Aangezien het eindresultaat er uit ziet als I1 P2 P3 P4 P5 P6, waarbij I1 = P2 = P3, zou het in principe al voldoende zijn dat ik P2 en P3 kan wegknippen.


Je zegt ook dat het een bekend probleem is, heb je toevallig geen link naar wat meer informatie?

[Verwijderd]

Het is een bekend industrie-probleem met MPEG-1. Links? Geen idee. Ik heb gewoon de MPEG-1 bitstream specificaties voor me liggen, die kun je bij ISO opvragen. Op zich zou die extra-GOP hack toch genoeg moeten zijn? MPEG GOP syncen is super-simpel, dus dat mag het probleem niet zijn. Ik zie zeg maar je probleem niet zo... Is je probleem die extra I-frame van de volgende GOP? Die kun je tijdens het recoderen (dus na het decoderen) toch droppen? Of bedoel je dat die eerste B-frames in het begin van je nieuwe stream krijgt? Dat kun je toch ook makkelijk afvangen in je recoder door ze te droppen?

[Verwijderd]

Het probleem is het verwijderen van de 2 frames bij het hercoderen. Dit gebeurt mbv ffmpeg, dus ik ga eens bekijken hoe ik ze met dat programma kan laten vallen.

[Verwijderd]

Je laat ze vallen na het decoderen. Dan heb je een stream met raw frames, en je gooit deze twee frames dus niet in de encoding-queue die later zal recoderen.