> > Timestamps in encoded frame are expected. > Why I dunno, but this was the case with FLV, which is the only > officially supported container format AFAIK.
I know but I've been successfully using gnash with AVC for a while with a new video decoder for 0.8.3. I have issues of course (mostly the second question in my previous response), but still. > > My guess is this is so it's possible to build an index of cue > points w/out decoding the stream. > The guess is based on behavioural analisys of a running youtube player, > tracking bytesLoaded/bytesTotal, bufferTime, memory use, filesystem caching > and seek operations. > Right... since gnash stores the (variable length) coded frames in a queue it can (rather) quickly traverse, this feature could be used for trick-play (seek, play backwards or at various speeds). Still, it seems restrictive to demand this pass through a SW API. I do understand that there's no need to extend it before there are parsers/decoders that need this feature a public patch so I guess I should get back to the code...
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
