[FFmpeg-devel] Regarding the removal of hacks

[Jan Ekström]

Hi,

I would like to raise a question regarding how the community feels
about removing hacks which most likely were done to work around
deficiencies of API clients. Silently.

Some weeks ago someone asked on #ffmpeg why he wasn't getting the time
scale (time base in MOV/ISOBMFF speak) he wanted out of movenc.c. So I
looked into it:

1) https://git.videolan.org/?p=ffmpeg.git;a=commit;h=b02493e47668e66757b72a7163476e590edfea3a
  (2012) Some API clients didn't clearly set a time base correctly for
VFR content - a hack was added in movenc.c to bump the time scale to
at least 10k.
2) https://git.videolan.org/?p=ffmpeg.git;a=commit;h=7e570f027b9bb0b5504
ed443c70ceb654930859d
  (2013) Someone clearly didn't like this forced behavior so an
AVOption was added to set a forced video time base for ALL video
tracks in a mux.
3) https://git.videolan.org/?p=ffmpeg.git;a=commit;h=194be1f43ea391eb986732707435176e579265aa
  (2014) Anton switches the time base utilized from the encoder
AVCodec to the AVStream, which most likely fixes the issue of output
time base being incorrect as some encoders dislike weird (?) time
bases (although how would you get VFR content through those if that
was the reason is still beyond me).

After this I told the user that this is a hack that's been added and
that his timestamps are still exact (which they are, just that the
time base is larger than it is). But as a developer, this just looks
like the whole mess should be removed:

1) ffmpeg.c , for which the original hack possibly was added in 2012,
now has an option to set output time base as far as I can remember? So
the user of the tool can properly set a specific time base if
required, just like with the AVOption.
2) This is just extra complexity/automated logic that can be hiding
bugs in API clients, and we ended up having an additional AVOption.

So, going forward, would patches to remove things like these be worth
sending to the list?


Best regards,
Jan Ekström