[Ffmpeg-devel] Re: [RFC] Improvement for theoddtimestampgeneration when parser is in use.

elupus elupus
Tue Mar 20 18:18:58 CET 2007


> 
> well iam not entirely sure either which way is best but 
> either way you cannot add fields into the middle of 
> AVCodecParserContext that breaks the ABI and would need a 
> mjor version bump adding fields to the end of the struct might be ok
> 
> also from the current position in the chunk the current 
> chunks timestamp and the size of the frame all are trivially 
> known you can just update the timestamp outside the parser 
> completely bypassing the parsers messing with timestamps, iam 
> not saying thats clean but no doubt simple
> 

Yes, wich is what the first patch attempts to do. Only change to parser is
so outside world know at what offset the frame started relative to the
timestamp. Then avformat calculates the timestamp correction based on
bitrate. Done this way since it still needs to know the timestamp of the
packet that started the frame. I mean the frame could technically cover
several packets.

I suppose avformat could keep track of the timestamp of the packet that made
parser output a frame, and at what offset in that packet it ended up when
av_parser_parse returned, then use that as the base for the next frame. That
seems abit stupid thou as it wouldn't give any other users of parser the
same information by default.

The first patch should work fine after some minor modifications (will fix
the abi breakage and some other things). Parser could keep doing what it
does currently, and avformat could just set packet timestamp to
cur_dts+duration if parser didn't give any timestamps. Aslong as the
timestamps that are returned from parser are corrected with the offset this
should give much more stable timestamps

However I think it would make sence to add the flag as that would make
parser always output usable timestamp+offset, but I'll put that in a
seperate patch, as it isn't really needed.

Anyway no need to respond to this unless you see something fundamentally
wrong in my thoughs above or the first patch. Will send a corrected patch
later.

Cheers

/Joakim





More information about the ffmpeg-devel mailing list