On Thu, Oct 16, 2014 at 09:56:49AM +0200, Clément Bœsch wrote: > On Thu, Oct 16, 2014 at 01:43:27AM +0200, Michael Niedermayer wrote: > > ffmpeg | branch: master | Michael Niedermayer <michae...@gmx.at> | Thu Oct > > 16 00:13:45 2014 +0200| [7b6a97edd1b50c03ec9b30f5806a72036923bee4] | > > committer: Michael Niedermayer > > > > avcodec/avcodec: more verbose documentation for time_base > > > > Signed-off-by: Michael Niedermayer <michae...@gmx.at> > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7b6a97edd1b50c03ec9b30f5806a72036923bee4 > > --- > > > > libavcodec/avcodec.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > index cb0e744..3d6f7b9 100644 > > --- a/libavcodec/avcodec.h > > +++ b/libavcodec/avcodec.h > > @@ -1346,6 +1346,8 @@ typedef struct AVCodecContext { > > * of which frame timestamps are represented. For fixed-fps content, > > * timebase should be 1/framerate and timestamp increments should be > > * identically 1. > > > + * This often, but not always is the inverse of the frame rate or > > field rate > > + * for video. > > Can you provide examples where it's not?
I would have thought that is quite widely known that timebases arent always the inverse of framerates & fieldrates. but if you want an example, lets pick mpeg4 (ISO/IEC 14496-2) for variable fps material it stores timebases in the form 1/m thus that would be 1/30000 for 30000/1001 based material with frame drops or "duplicated fields/frames" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-cvslog mailing list ffmpeg-cvslog@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog
