[FFmpeg-devel] lavf: different flush_packet options...

[Michael Niedermayer]

On Sat, Jun 28, 2014 at 07:27:18PM +0200, Reimar Döffinger wrote:
> Hello,
> options_table.h contains these:
> {"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = AVFMT_FLAG_FLUSH_PACKETS }, INT_MIN, INT_MAX, D|E, "fflags"},
> {"flush_packets", "reduce the latency by flushing out packets immediately", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_FLUSH_PACKETS }, INT_MIN, INT_MAX, D, "fflags"},
> 
> and:
> 
> {"flush_packets", "enable flushing of the I/O context after each packet", OFFSET(flush_packets), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, E},
> 
> There are several things that confuse me completely.
> a) what is the difference between these
> b) why is the first one marked as decode-only, the second as encode
> only, but both are actually used at the same place:
> mux.c:    if (s->flush_packets && s->pb && ret >= 0 && s->flags & AVFMT_FLAG_FLUSH_PACKETS)
> (and this is btw. the _only_ use of AVFMT_FLAG_FLUSH_PACKETS, and I
> absolutely see no reason why it requires flush_packets to be set except
> making it needlessly hard to use)
> 
> I suspect that the non-flag documentation should say "allow explicit
> flushing to reduce latency by writing NULL packets", assuming it is
> removed from the above if.
> The flag version should probably warn that it might break with some
> muxers (not sure, just a suspicion).

the non flags flush_packets was implemented by nicolas in march 2013
(4f112a8e34022c821be885ed293abc0b120c875b)

in september 2013 libav added the same feature but used flags instead
(596e5d4783ca951258a7c580951fd161f1785ec1)
we support this for compatibility with libav

The variant from and in libav contains several bugs, like being marked
for decoders instead of encoders it seems and as you noticed ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140628/3107663e/attachment.asc>