[C++] / [C] PNG's doorgeven via het geheugen ipv HD?

[GAEvakYD]

Ik ben bezig met een programma dat mpegstreams maakt van screenshots. Die screenhots
worden gemaakt met Qt, en worden in een gelinktelijst van QPixmap's (Eigen class van Qt)
gezet. Dit werkt allemaal naar behoren.

Dat mpegs maken doen we met de libary van berkeley. Op dit moment draait het zo dat we
eerste de plaajes maken en in de lijst zetten. Hierna lezen we de de buffer uit
en slaan we deze QPixmap's op als PNG op de hareschijf. Vervolgens
geven we aan de encoder door welke filenames die moet gebruiken. Dan gaat hij het filpje
maken, en gaat daarna weer nieuwe plaatjes maken en begint alles vanaf vooraf aan.

Wat we nu willen is dat dat hele stuk van het opslaan op disk wegvalt, en dat we gewoon
een lijst kunnen meegeven met PNG's erin. Dit is mogelijk, er is een Qt class Buffer. In
deze class kun je images stoppen als PNG formaat. Dan staat het plaatje dus als PNG in
je geheugen.

Nu komt het probleem dat de encoder een C libary is( waar we wel gewoon de source van hebben)
, hierdoor kunnen we die Buffer niet uilezen omdat die gebasseerd is op de Qt class QBuffer.
Dit is dus C++, en dat vint ansi C niet zo leuk.

Onze vraag is nu, hoe kunnen we dit het beste oplossen. Hoe krijgen we die png's in de C
libary. We hebben al zitten denken om
de harde geheugenadressen mee te geven. We weten alleen niet of dit mogelijk is en of dit
wel een goede degelijke oplossing is.

[ACM]

"Standaard" shared memory gebruiken? (shm functies geloof ik)

Daar zijn allerlei libs voor en de meeste unix-kernels ondersteunen het out-of-the-box
Je zou daarnaast nog naar de mm-library kunnen kijken.

[GAEvakYD]

Was stiekum vergeten te zeggen dat de app moet draaien op Windows NT/2000, Linux, Unix, Solaris. Vandaar dat we Qt gebruiken voor de grafische dingen.

Kun je in die libary's eigen datatypes gooien enzo?

[curry684]

GAEvakYD schreef op 10 oktober 2002 @ 14:13:
Nu komt het probleem dat de encoder een C libary is( waar we wel gewoon de source van hebben)
, hierdoor kunnen we die Buffer niet uilezen omdat die gebasseerd is op de Qt class QBuffer.
Dit is dus C++, en dat vint ansi C niet zo leuk.

Ik snap je probleem niet echt... wie houdt je tegen exact om die C-lib in een C++ class te wrapper die wel een QBuffer als input accepteert?

We hebben al zitten denken om de harde geheugenadressen mee te geven. We weten alleen niet of dit mogelijk is en of dit wel een goede degelijke oplossing is.

Bliep... en waaraan wil de die dan meegeven? Aan een static lib? Dat kan natuurlijk, want die link je mee... Aan een dynamische lib? Kan eveneens natuurlijk, want die zit in-process op execution time...

Ik zie echt totaal geen problemen hier... kun je wellicht je programmaopzet (libs tov. executale) eens wat toelichten?

[curry684]

ACM schreef op 10 oktober 2002 @ 14:17:
"Standaard" shared memory gebruiken? (shm functies geloof ik)

Daar zijn allerlei libs voor en de meeste unix-kernels ondersteunen het out-of-the-box
Je zou daarnaast nog naar de mm-library kunnen kijken.

Onder Windows heet dit overigens een File Mapping, enigszins misleidend omdat er geen file bij te pas hoeft te komen

Zie in MSDN/PSDK bij het hoofdstuk IPC onder File Mappings.

[Verwijderd]

curry684 schreef op 10 oktober 2002 @ 14:28:
[...]

Ik snap je probleem niet echt... wie houdt je tegen exact om die C-lib in een C++ class te wrapper die wel een QBuffer als input accepteert?

[...]

Bliep... en waaraan wil de die dan meegeven? Aan een static lib? Dat kan natuurlijk, want die link je mee... Aan een dynamische lib? Kan eveneens natuurlijk, want die zit in-process op execution time...

Ik zie echt totaal geen problemen hier... kun je wellicht je programmaopzet (libs tov. executale) eens wat toelichten?

De (Qt) buffer zit in de C++ code. Deze buffer willen we vervolgens meegeven aan de C library, en hem daar uit laten lezen.

(In die buffer zitten die PNG's die we in de C-library willen krijgen)..

[curry684]

Verwijderd schreef op 10 oktober 2002 @ 14:49:
De (Qt) buffer zit in de C++ code. Deze buffer willen we vervolgens meegeven aan de C library, en hem daar uit laten lezen.

(In die buffer zitten die PNG's die we in de C-library willen krijgen)..

Ik snap het probleem echt niet....

C++:

extern "C"
{
#include "MyPgnLibraryWrittenInC.h"
}

class MyPngEncapsulatorClass
{
public:
  void Encode(const QBuffer &p_MyBuffer)
  {
  InternalCVersionOfPngEncode(p_MyBuffer.Data(), p_MuBuffer.Length());
  }
}

[GAEvakYD]

curry684 schreef op 10 oktober 2002 @ 15:01:
[...]

Ik snap het probleem echt niet....

C++:

extern "C"
{
#include "MyPgnLibraryWrittenInC.h"
}

class MyPngEncapsulatorClass
{
public:
  void Encode(const QBuffer &p_MyBuffer)
  {
  InternalCVersionOfPngEncode(p_MyBuffer.Data(), p_MuBuffer.Length());
  }
}

Het zijn meerde libary's. pnglib, zlib en mpegencode. Die mpegencode is dus ook puur C. We kunnen de mpegencode functie wel aanroepen vanuit onze C++ code, maar wat wil die hebben??. Juist file pointers, en dat willen wij juist niet.

[curry684]

ps. volgens dit topic was bovenstaande jullie al gelukt...

[Verwijderd]

We kunnen inderdaad de MPEG-encoder al vanuit ons C++ programma aanroepen.

Maar tijdens het encoden (wat in de C-library gebeurt) roept het programma normaal gesproken de .png files (die in de C++ code gemaakt worden) op schijf aan. Dit willen we omzeilen door de .png's in het geheugen te plaatsen, en deze geheugenplaatsen uit te lezen in de C-library.

[curry684]

GAEvakYD schreef op 10 oktober 2002 @ 15:11:
Het zijn meerde libary's. pnglib, zlib en mpegencode. Die mpegencode is dus ook puur C. We kunnen de mpegencode functie wel aanroepen vanuit onze C++ code, maar wat wil die hebben??. Juist file pointers, en dat willen wij juist niet.

Het lijkt me sterk dat die filepointer meer dan 3 functiecalls diep meegaat. How hard can it be om zelf een ingang met void* en int Length in te bakken?

Ik heb hetzelfde voor ZLib en JpegLib moeten doen tijdje terug, is krap een ochtend werk inclusief volledige C++ encapsulatie.

[Verwijderd]

hoe moet je die png's dan aan die mpeg lib doorgeven? met filenames? of file descriptors ofzo?

[Verwijderd]

curry684 schreef op 10 oktober 2002 @ 15:36:
[...]

Het lijkt me sterk dat die filepointer meer dan 3 functiecalls diep meegaat. How hard can it be om zelf een ingang met void* en int Length in te bakken?

Ik heb hetzelfde voor ZLib en JpegLib moeten doen tijdje terug, is krap een ochtend werk inclusief volledige C++ encapsulatie.

Kun je dit misschien iets duidelijker toelichten ?

Ken je die MPEG-encoder?

ff een kleine toelichting :
Die MPEG-encoder heeft van zichzelf een parameter file waarin hij uitleest welke bestanden (png's) hij als input moet gebruiken. Als hij deze filenames heeft ingelezen dan gaat hij van de volledige paden file-pointers maken.
Deze file-pointers gebruikt hij dan weer in een andere functie die de PNG's daadwerkelijk inleest.

[Verwijderd]

en als hij ze inleest zet hij ze in een buffer... en jij moet dan een functie in die library maken met een pointer als parameter die hij dan als buffer gebruikt, zodat hij die stappen van die file inlezen kan overslaan

[curry684]

Heej je begint 'm door te hebben

Die functie kan nooit meer dan 3 calls diep genest zitten... hint: zet een breakpoint in een duidelijke core-encoding-routine en wacht tot ie 'm raakt, bestudeer dan de callstack. Ik durf met vrij grote zekerheid te zeggen dat er een functie in de lib bestaat die als parameters een void* en int neemt voor Buf en BufLen.

[MSalters]

Ik gok dat je probleem is dat die disk te langzaam is, niet zozeer dat het een disk is. Dan zou een RAMdisk best wel eens handig kunnen zijn. Dat is uiteindelijk ook een vorm van shared memory.

[Verwijderd]

MSalters schreef op 10 oktober 2002 @ 21:35:
Ik gok dat je probleem is dat die disk te langzaam is, niet zozeer dat het een disk is. Dan zou een RAMdisk best wel eens handig kunnen zijn. Dat is uiteindelijk ook een vorm van shared memory.

Is wel een zeer omslachtige methode, en bovendien niet erg compatible.

[curry684]

MSalters schreef op 10 oktober 2002 @ 21:35:
Ik gok dat je probleem is dat die disk te langzaam is, niet zozeer dat het een disk is. Dan zou een RAMdisk best wel eens handig kunnen zijn. Dat is uiteindelijk ook een vorm van shared memory.

Sinds wanneer kent Windows native RAM-disks?

Afgezien daarvan heb je de vraag niet gelezen, want de snelheid is niet het probleem maar ze willen de fase van het naar disk schrijven gewoon algeheel elimineren omdat ie simpelweg overbodig is.

[GAEvakYD]

Eens even zoeken in welke buffer mpegencode zelf die png's donderd als die files inleest vanaf disk. Hopelijk kunnen wij die dan ook gebruiken.

[Verwijderd]

GAEvakYD schreef op 11 oktober 2002 @ 07:40:Hopelijk kunnen wij die dan ook gebruiken.

je bedoelt zeker aangezien wij die dan ook gebruiken?

[curry684]

GAEvakYD schreef op 11 oktober 2002 @ 07:40:
Eens even zoeken in welke buffer mpegencode zelf die png's donderd als die files inleest vanaf disk. Hopelijk kunnen wij die dan ook gebruiken.

Als je d'r echt niet uitkomt stuur maar een mailtje dan kijk ik wel of ik er van het weekend uitkom.

[GAEvakYD]

Hmmmm, hij blijft oelepoele over fie file pointers. Die heb je bij elke ingang nodig. We kunnen bijna frames maken nu, alleen in de fucntie aanroep wil die een filepointer hebben naar een file waar dus een png bestand hoort te staat. Enig idee, dit op te lossen. Dit was ook onze hoofdbedoeling van deze topic.


Ps Curry86, bedankt voor het aanbod. We proberen het eerst nog even zelf (zijn al de hele week hier mee bezig , blerggg). Mochten we er aan het einde van de dag nog niet uit zijn. Dan kan er wel eens mail in je mailbox komen. Heb je wel Qt ingestaleerd op je bak?, anders begint die daar over te oelepoele

[curry684]

GAEvakYD schreef op 11 oktober 2002 @ 10:05:
Hmmmm, hij blijft oelepoele over fie file pointers. Die heb je bij elke ingang nodig. We kunnen bijna frames maken nu, alleen in de fucntie aanroep wil die een filepointer hebben naar een file waar dus een png bestand hoort te staat. Enig idee, dit op te lossen. Dit was ook onze hoofdbedoeling van deze topic.

Je moet verder in de sourcecode graven... *ERGENS* moet ie iets intelligents gaan doen met de data in die file, en dat is het punt dat het 'm geen kont meer uitmaakt of ie een QBuffer, een void*, een file of een fiets als parameter krijgt. Geef maar ff de URL van die lib die je gebruikt.

Heb je wel Qt ingestaleerd op je bak?, anders begint die daar over te oelepoele

Neuh... maar who says I need to compile?

[edit]
Als je met mpeg_encode-1.5b-src.tar.gz werkt heb ik 'm al gevonden
In die lib zit geen enkele referentie naar files en hij is uit 1995 dus dat zal wel niet... hulde aan Berkeley voor het onderhouden van hun webpagina's

[Verwijderd]

curry684 schreef op 11 oktober 2002 @ 10:21:
In die lib zit geen enkele referentie naar files en hij is uit 1995 dus dat zal wel niet... hulde aan Berkeley voor het onderhouden van hun webpagina's

huh? hoe moet je de imagedata dan duidelijk maken aan die lib? als via het filesystem al niet kan, en via het geheugen ook niet? d.m.v. telepathie ofzo?

[curry684]

Verwijderd schreef op 11 oktober 2002 @ 10:41:
huh? hoe moet je de imagedata dan duidelijk maken aan die lib? als via het filesystem al niet kan, en via het geheugen ook niet? d.m.v. telepathie ofzo?

Lees het doorstreepte gedeelte ook ff, als dat niet relevant was geweest had ik het wel weggehaald

[Verwijderd]

curry684 schreef op 11 oktober 2002 @ 10:21:
[...]

Je moet verder in de sourcecode graven... *ERGENS* moet ie iets intelligents gaan doen met de data in die file, en dat is het punt dat het 'm geen kont meer uitmaakt of ie een QBuffer, een void*, een file of een fiets als parameter krijgt. Geef maar ff de URL van die lib die je gebruikt.

[...]

Neuh... maar who says I need to compile?

[edit]
Als je met mpeg_encode-1.5b-src.tar.gz werkt heb ik 'm al gevonden
In die lib zit geen enkele referentie naar files en hij is uit 1995 dus dat zal wel niet... hulde aan Berkeley voor het onderhouden van hun webpagina's

Deze gebruiken we. http://www.buckosoft.com/gallery/tools/mpeg_encode/

[curry684]

Ff gekeken, en je moet iig in pngrio.c beginnen:

C:

/* pngrio.c - functions for data input
 *
 * libpng 1.0.5 - October 15, 1999
 * For conditions of distribution and use, see copyright notice in png.h
 * Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.
 * Copyright (c) 1996, 1997 Andreas Dilger
 * Copyright (c) 1998, 1999 Glenn Randers-Pehrson
 *
 * This file provides a location for all input.  Users who need
 * special handling are expected to write a function that has the same
 * arguments as this and performs a similar function, but that possibly
 * has a different input method.  Note that you shouldn't change this
 * function, but rather write a replacement function and then make
 * libpng use it at run time with png_set_read_fn(...).
 */

In deze file zie je dat alle input via de functie png_read_data verloopt die vervolgens de standard-file-based readfunctie aanroept. Daar moet je dus een eigen variant op definieren die over een void* buffer loopt... check maar eens of je hiermee al verder komt (ik zit ook op me werk dus niet al teveel tijd nu )

[GAEvakYD]

Ziet er interesant uit, maar die buffer hoe kunnen we dat oplossen dan?. Want we weten dus niet hoe we een buffer moeten maken. Moet het met zoiets met een buffer van geheugen adressen ofzo??. Dit was ons hoofdprobleem, waardoor we en topic geopend hebben.

[GAEvakYD]

Nog even iets. Hhet blijkt dat de encoder vanuit mpeg.c (genMpegStream() ) de functie readFrame() aanroept in readframe.c. Deze roept weer readPNG() aan in readframe.c, vervolgens roept deze weer png_readpng.c in de file png.c aan. Hierna wordt ergens de functie png_read_data aanroepen wat jij zei. Maar in de andere read functies ervoor worden ook dingen gedaan die essienteel belang zijn voor het encoden. Hij doet daar allemaal check's waar die later de stream mee gaat maken. Check die functies maar eens readframe(), readpng(), png_readpng()

[curry684]

GAEvakYD schreef op 11 oktober 2002 @ 11:34:
Ziet er interesant uit, maar die buffer hoe kunnen we dat oplossen dan?. Want we weten dus niet hoe we een buffer moeten maken. Moet het met zoiets met een buffer van geheugen adressen ofzo??. Dit was ons hoofdprobleem, waardoor we en topic geopend hebben.

Uhm op dit moment schrijven jullie de originele PNG toch naar disk? Daarvoor heb je een void* nodig naar het begin en een int die de lengte definieert. Vervolgens stop je deze 2 in een struct die je meegeeft ipv een FILE* en definieer je je eigen read-functie die snapt dat er daar een MyCustomBufferDescriber* instaat ipv een FILE*.

ps. als je iets doormailt, aub. incluis VS project file

[GAEvakYD]

curry684 schreef op 11 oktober 2002 @ 13:30:
[...]

Uhm op dit moment schrijven jullie de originele PNG toch naar disk? Daarvoor heb je een void* nodig naar het begin en een int die de lengte definieert. Vervolgens stop je deze 2 in een struct die je meegeeft ipv een FILE* en definieer je je eigen read-functie die snapt dat er daar een MyCustomBufferDescriber* instaat ipv een FILE*.

ps. als je iets doormailt, aub. incluis VS project file

Dat stuk van dat schrijven naar disk moet er juist uit. Of is dat niet haalbaar denk je???.

Ps in de zip zit alles er op en eraan. gewoon starten met build.bat, die opend je builder en zet de variabele goed.

[curry684]

GAEvakYD schreef op 11 oktober 2002 @ 13:52:
Dat stuk van dat schrijven naar disk moet er juist uit. Of is dat niet haalbaar denk je???

Wat ik bedoelde: om iets naar disk te kunnen schrijven heb je een datapointer en een lengte nodig. Wat je nu moet doen is ipv die diskactie te doen die datapointer en die lengte rechtstreeks in de encoder te pompen.

[Verwijderd]

Sorry, we zijn nog niet zo thuis met dat geheugen gedoe

We hebben nu 2 manieren die allebei een halve oplossing leveren

A )
We kunnen die gemaakte plaatjes (QImage) in een buffer stoppen.
Maar het zijn dan nog geen PNG's.

Als we dan aan MPEG-encoder een pointer doorgeven met een lengte, dan ziet de MPEG-encoder toch dat het geen PNG's zijn, maar een voor hem onbekend formaat (QImage)?

B )
We kunnen die plaatjes dmv QImageIO een formaat meegeven en dat vervolgens in een buffer plaatsen. Echter, met QImageIO kunnen we weer niet de pointer naar het begin en de lengte opvragen. (Uit QImageIO komen Pixmap's)


Dus QImage heeft wél de mogelijkheden om de lengte en de datapointer op te vragen, maar dan blijven de plaatjes in Qt formaat, en QImageIO kan plaatjes als PNG in een buffer zetten, maar heeft weer niet de mogelijkheid om de datapointer en de lengte op te vragen

[curry684]

Uberhaupt heb je trouwens geen enkele reden meer om PNG te gebruiken als je puur en alleen in het geheugen werkt, vreet alleen maar gruwelijk veel performance... slikt de mpeg_encode geen simpele rgb-arrays?

[curry684]

Verwijderd schreef op 11 oktober 2002 @ 15:36:
Dus QImage heeft wél de mogelijkheden om de lengte en de datapointer op te vragen, maar dan blijven de plaatjes in Qt formaat, en QImageIO kan plaatjes als PNG in een buffer zetten, maar heeft weer niet de mogelijkheid om de datapointer en de lengte op te vragen

Dat Qt formaat wat je bedoelt is gewoon een bak rgb-scanlines (heb net opgezocht), en die kun je redelijk direct in de MPEG-encoder binnen streamen: geen ZLib, JPEG of PNG libs meer nodig. Moet wel wat extra ingangen definieren, maar da's niet zo'n punt.

[GAEvakYD]

Oei, Zal wel geweldig wezen als dat lukt. Alleen wij weten dus totaal niet hoe we dat moeten doen. Ps sorry mijn vriendin staat zo op de stoep om me het hele weekend mee te nemen (heel leuk hoor). Dus moet verplicht stoppen, hoop van het weekend nog effe te kunnen reply'n. Alvast bedankt.

[GAEvakYD]

Yeah Yeah, het is redelijk gelukt. Met een paar goede tips van curry684. Er komt een filmpje uit de encoder. Alleen 1 probleem, het beeld is helemaal zwart. Wel is de resolutie helemaal goed enzo. Dit is denk ik het probleem dat die niet een image standaard kan vinden. Zo'n mpeg frame moet namelijk op een format gezet worden (eerder stond dat op PNG). Omdat we dit nu helemaal niet meer gebruiken is er geen formaat.

[Olaf van der Spek]

curry684 schreef op 10 oktober 2002 @ 15:36:
[...]

Het lijkt me sterk dat die filepointer meer dan 3 functiecalls diep meegaat. How hard can it be om zelf een ingang met void* en int Length in te bakken?

Ik heb hetzelfde voor ZLib en JpegLib moeten doen tijdje terug, is krap een ochtend werk inclusief volledige C++ encapsulatie.

Die twee libs ondersteunen dat toch al (half)?
Voor libjpeg kun je callbacks schrijven die de data lezen/schrijven en libz heeft al functies voor data in het geheugen.

[GAEvakYD]

OlafvdSpek schreef op 15 oktober 2002 @ 13:21:
[...]

Die twee libs ondersteunen dat toch al (half)?
Voor libjpeg kun je callbacks schrijven die de data lezen/schrijven en libz heeft al functies voor data in het geheugen.

Dit hebben wij dus al aan de gang. Met een beetje geluk kunnen straks de libs jpeg en png gewoon weg(die gebruiken we nu ook niet meer). De fout zit er (volgens ons) in dat de mpeg encode een formaat krijgt aangeleverd dat die niet kent (QImage is van Qt).

[curry684]

OlafvdSpek schreef op 15 oktober 2002 @ 13:21:
Die twee libs ondersteunen dat toch al (half)?
Voor libjpeg kun je callbacks schrijven die de data lezen/schrijven en libz heeft al functies voor data in het geheugen.

Zlib was makkelijker dan JpegLib omdat ZLib echt op void* tjap werkt en je bij JpegLib idd een hoop extra moet implementeren in de class eromheen (quality en zo). Vandaar een ochtendje werk

Overigens biedt MpegEncode ook de mogelijkheden wel, maar wat minder prettig exposed (geen echte void* ingang, die zijn allemaal verkapt tot higher-level ingangen)

[GAEvakYD]

Wij gebruiken die void* nu niet. We geven gewoon die hele struct door, waar dus een void* in zit naar een QImage. Vervolgens geven we deze struct helemaal door via GenMPEGStream, ReadFrame naar ReadMemory (alternatief voor ReadPNG). Wat we daar doen is dit.
De struct ziet er zo uit:

code:

struct PNGSTRUCT
  {
  void*       p_ImageData;    // QImage->ScanLine[0]
  int         p_ImageSize;    // Qimage->Buffer
  int         p_Width;        // QImage->Width
  int         p_Height;       // QImage->Height
};

Die vullen we zo:

code:

        m_pixmap = QPixmap::grabWindow( QApplication::desktop()->winId(),  0, 0, 
            QApplication::desktop()->width(),QApplication::desktop()->height() );
        m_image = m_pixmap.convertToImage();
        m_pngstruct.p_ImageData = m_image.scanLine(0);
        m_pngstruct.p_ImageSize = m_image.numBytes();
        m_pngstruct.p_Width     = m_image.width();
        m_pngstruct.p_Height    = m_image.height();

En zo zetten we in de encode de rgb data:

code:

static void
  ReadMemory(pngStruct, mf)
struct PNGSTRUCT pngStruct;
MpegFrame *mf;
{
  int x, y;
  xelval maxval;
  int format;


  if (mf->rgb_data) {
    png_freearray(mf->rgb_data, Fsize_y);
  }
  
mf->rgb_data =  pngStruct.p_ImageData;
  
  
  
  //ERRCHK(mf, "pnm_readpnm");

  /*
   * if this is the first frame read, set the global frame size
   */
  Fsize_Note(mf->id, pngStruct.p_Width, pngStruct.p_Height);

  mf->rgb_maxval = 255;
  mf->rgb_format = PNG_FORMAT;
  mf->rgb_format = 0;

Is dit fout?omdat ik jullie zo hoor praten over die void* ingangen

[Olaf van der Spek]

Dit lijkt me niet geheel correct:

code:

mf->rgb_format = PNG_FORMAT;
mf->rgb_format = 0;

[GAEvakYD]

Klopt daar was ik mee aan het pielen. Origineel staat daar PNG_FORMAT.

[curry684]

GAEvakYD schreef op 15 oktober 2002 @ 13:43:
Dit hebben wij dus al aan de gang. Met een beetje geluk kunnen straks de libs jpeg en png gewoon weg(die gebruiken we nu ook niet meer). De fout zit er (volgens ons) in dat de mpeg encode een formaat krijgt aangeleverd dat die niet kent (QImage is van Qt).

In de docs van QImage staat dat ie gewoon een lijst van pixels heeft in het geheugen, separated as scanlines. Standaard imageblobje dus... lulligheid is dat indien de QImage in 16-bit 5-6-5 mode draait of zo je dat formaat ook door moet geven aan MpegEncode, en mocht ie het niet ondersteunen moet je handmatig converteren.

[GAEvakYD]

hmmmmm, erg opmerkelijk dit. Met 1 plaatje in het geheugen een film maken gaat goed (een film van 5x hetzelfde plaatje). Gooien we een hele gelinkte lijst van struct door. Chrast die op de functie PPMtoYUV.

Opzicht kunnen we daar nog wel inkomen, maar waarom gaat die daar met 1 plaatje wel doorheen.

Arggg erg naar stuk als je er een hele week op zit.