[FFmpeg-devel] [PATCH] Implemented arrange feature to convert from low timebase formats to high timebase
Roman Arutyunyan
arutyunyan.roman at gmail.com
Wed Oct 17 16:39:54 CEST 2012
2012/10/17 Nicolas George <nicolas.george at normalesup.org>
> Le sextidi 26 vendémiaire, an CCXXI, Roman Arutyunyan a écrit :
> > This patch rearranges frame timestamps in muxer.
> >
> > The problem: When remuxing from low-timebase-resolution formats (like
> RTMP with 1KHz time base)
> > to high-resolution formats (like MPEG-TS with 90KHz) frame timestamps
> are multiplied by
> > resolution factor (*90 in this case). That significantly increases
> round-off error. If you
> > have two audio frames next to one another that kind of remuxing may
> result in your second frame's
> > timestamp be too far from where it should be as a result of round-off
> error multiplication.
>
> Have you discussed that particular problem somewhere (users mailing-list,
> bug tracker)? It looks to me like a framerate detection failure, and I am
> not sure that tweaking the timestamps randomly is the correct method of
> fixing it.
>
That's my experience with my project (nginx-rtmp-module). It works for me.
I wish we could discuss the problem here. Maybe there will be better
solutions.
100% correct solution is impossible here because precise timestamps are lost
after rounding.
Timestamps are not actually tweaked but in most cases are auto-generated
like with '-async -1'. That's not random tweaking. BTW '-async -1' also
works
pretty good until first gap in audio stream.
>
> > While I have not found a PC software sensitive to that kind of error
> Apple iPhone is very
> > much sensitive producing crackles at audio frame boundaries after such
> conversion (I convert
> > RTMP to HLS).
> >
> > The patch intoduces '-arrange[:stream_specifier] arrange_threshold'
> option, where arrange_threshold
> > is max timestamp divergence in microseconds. When the argument is
> nonzero and current frame dts
> > is within arrange_threshold distance from muxer stream dts then packet
> dts is reset making
> > current frame receive the currect auto-generated dts from muxer. If new
> packet dts differs
> > too much then it's not changed in any way (that usually means a gap in
> audio stream).
> >
> > The feature makes sence when applied to audio stream.
> >
> > ---
> > ffmpeg.h | 2 ++
> > ffmpeg_opt.c | 4 ++++
> > libavcodec/avcodec.h | 7 +++++++
> > libavformat/utils.c | 8 ++++++++
>
> The flag is stored in the AVCodecContext, the work is done in libavformat
> but the setting is controlled by the command-line tool. On the whole, it
> does not look right.
>
I'm agree. However AVCodecContext is easily accessed from output stream
structure
that's why I used it. I'll try to fix that.
> If the problem is specific to the ffmpeg command-line tool, then, assuming
> this is the right way of fixing it, then the flag should be in the
> OutputStream structure and the work done by ffmpeg.c in write_frame().
>
OK. Thanks for the clue. I'll fix that too.
>
> > 4 files changed, 21 insertions(+), 0 deletions(-)
> >
> > diff --git a/ffmpeg.h b/ffmpeg.h
> > index 56f8dfc..cadbea4 100644
> > --- a/ffmpeg.h
> > +++ b/ffmpeg.h
> > @@ -167,6 +167,8 @@ typedef struct OptionsContext {
> > int nb_pass;
> > SpecifierOpt *passlogfiles;
> > int nb_passlogfiles;
> > + SpecifierOpt *arrange;
> > + int nb_arrange;
> > } OptionsContext;
> >
> > typedef struct InputFilter {
> > diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> > index 2c5fbfb..a50a9cf 100644
> > --- a/ffmpeg_opt.c
> > +++ b/ffmpeg_opt.c
> > @@ -994,6 +994,8 @@ static OutputStream
> *new_output_stream(OptionsContext *o, AVFormatContext *oc, e
> > st->codec->global_quality = FF_QP2LAMBDA * qscale;
> > }
> >
> > + MATCH_PER_STREAM_OPT(arrange, i64, st->codec->arrange_threshold,
> oc, st);
> > +
> > if (oc->oformat->flags & AVFMT_GLOBALHEADER)
> > st->codec->flags |= CODEC_FLAG_GLOBAL_HEADER;
> >
> > @@ -2343,6 +2345,8 @@ const OptionDef options[] = {
> > "extract an attachment into a file", "filename" },
> > { "debug_ts", OPT_BOOL | OPT_EXPERT, {
> &debug_ts },
> > "print timestamp debugging info" },
> > + { "arrange", HAS_ARG | OPT_INT64 | OPT_SPEC, {
> .off = OFFSET(arrange) },
> > + "arrange closely spaced frames" },
>
> Both the name of the option and its description seem way too vague. A more
> specific name and an entry in the documentation would be in order.
>
Agreed. I've spent a lot for time thinking of a better name. Maybe there's
somebody around
who can suggest one? However that might depend on the solution we will
finally come to.
>
> Regards,
>
> --
> Nicolas George
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlB+u80ACgkQsGPZlzblTJOsjACeKQt6avaoJnLBsBhnDzVmvp1U
> 8M8An0cmB1KhOVL1rCCSg72s5SdghJjs
> =yLcd
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
More information about the ffmpeg-devel
mailing list