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...