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

[elupus]

"Michael Niedermayer" <michaelni at gmx.at> wrote in message 
news:20070319224809.GS26096 at MichaelsNB...

> > Hmm, yea that could work. How about using need_parsing |=4 since that 
> > has
> > already been used to determin behavior of parser subsystem. The just 
> > reuse
> > available duration/bitrate?
>
> if it works and is clean then iam not opposed

Here are two patches with an idea on how to do it. First one is totally 
untested as i figured I was heading in the wrong direction when I started, 
but now i'm not so sure.

parser1.patch, handles the timestamp correction in libavformat and not in 
parser. (albeit currently misusing the parser context internal flags 
variable). it makes no change in the semantic on when to output timestamps 
from parser allthough it could do so based on that flag in the same approach 
that the second patch does.

parser2.patch does all calculations in parser, wich makes it usable outside 
avformat. It uses the bit_rate that ac3 and atleast aac parsers sets. 
HOWEVER, currently it isn't working due to time_base not being set in 
AVCodecContext, and it has no access to the streams timebase. (with 
time_base fixed up, it works thou).

Just wondering what direction i should move here. Either I make this a 
specific feature to avformat, and have parser just have a flag saying it 
should give byte offset from last available timestamp, any other users of 
parser could do same calculations as avformat would do when that flag is 
set.

The other option would be to make sure the AVCodecContext that get's passed 
to parser, gets the time_base from the stream. No idea what other things 
that might affect thou.

/Joakim 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parser1.patch
Type: application/octet-stream
Size: 3875 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070320/c89c570f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parser2.patch
Type: application/octet-stream
Size: 3340 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070320/c89c570f/attachment-0001.obj>