On Tue, 6 Jan 2015 20:40:51 +0100
Clément Bœsch <u...@pkh.me> wrote:
> On Tue, Jan 06, 2015 at 08:28:48PM +0100, wm4 wrote:
> > On Tue, 6 Jan 2015 18:09:58 +0100
> > Clément Bœsch <u...@pkh.me> wrote:
> >
> > > From: Clément Bœsch <clem...@stupeflix.com>
> > >
> > > This function will be used in the following commits in ffmpeg and
> > > ffplay.
> > > ---
> > > cmdutils.c | 170
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > cmdutils.h | 12 +++++
> > > 2 files changed, 182 insertions(+)
> > >
> > > diff --git a/cmdutils.c b/cmdutils.c
> > > index b35180e..0e22e57 100644
> > > --- a/cmdutils.c
> > > +++ b/cmdutils.c
> > > @@ -31,7 +31,9 @@
> > >
> > > #include "config.h"
> > > #include "compat/va_copy.h"
> > > +#include "libavcodec/bytestream.h"
> > > #include "libavformat/avformat.h"
> > > +#include "libavformat/isom.h"
> > > #include "libavfilter/avfilter.h"
> > > #include "libavdevice/avdevice.h"
> > > #include "libavresample/avresample.h"
> [...]
> > > +/**
> > > + * Get the MOV timeline from the stream side data, construct a
> > > libavfilter
> > > + * filtergraph, and insert it after the last filter.
> > > + *
> > > + * @param st the stream with the timeline
> > > + * @param last_filter pointer to last filter to stick the filtergraph
> > > (will be updated)
> > > + * @param start_time initial timestamp offset in AV_TIME_BASE_Q time
> > > base
> > > + * @param reverse if set, prepend the timeline filtergraph instead
> > > of appending it
> > > + */
> > > +int insert_timeline_graph(const AVStream *st, AVFilterContext
> > > **last_filter,
> > > + int64_t start_time, int reverse);
> > > +
> > > #endif /* CMDUTILS_H */
> >
> > So libavformat exports the raw MOV atom, and all tools ffmpeg.c uses to
> > parse it are private libavformat/libavcodec API?? That seems very
> > unfair to the API user.
>
> libavformat/isom.h is needed only for MOVElst, which is the following:
>
> typedef struct MOVElst {
> int64_t duration;
> int64_t time;
> float rate;
> } MOVElst;
>
> About the bytestream, that's kind of the same issue you will have for parsing
> kind of any bytestream, I don't think it is really unfair since most
> multimedia
> app will probably already have that.
>
Why not just wrap this struct?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
