[twobob]

seems to me that would be the dropping code in GM lib.

That is to say the FB gets filled too late to ever be written to the screen and the same thing happens over and over again in each pass.


hmm not the dropping code... well not according to it's own readouts... "drop=0"

I'll have more of a play, I've chosen a much simpler "source", I'll try to get that going:

Then ramp up the "real-time complexity of operation" required of ffmpeg incrementally by providing "tougher" (larger perhaps, whatever turns out to be "tougher") sources.

Sounds a likely stress test path. (not withstanding getting something on the screen)

EDIT:

Possibly to do with the piping for example... take ¦ raw2gmv out and you will see the stuff pipe through...

so maybe it's the latency of two pipes? possibly it would be better to embed raw2gmv code directly in gmplay and have a gmRawPlay inteads.

Then we could test better what effects the extra overheads incurred in transcoding have.

err.. more thinking required : )