View Single Post
Old 09-26-2012, 07:37 AM   #210
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Týr
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,552
Karma: 6021146
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
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 : )

Last edited by twobob; 09-26-2012 at 11:00 AM. Reason: did more thinking. well, a bit
twobob is offline   Reply With Quote