[FFmpeg-devel] Regarding the removal of hacks

Paul B Mahol onemda at gmail.com
Sat Mar 10 16:04:24 EET 2018

On 3/10/18, Jan Ekstroem <jeebjp at gmail.com> wrote:
> 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?

I'm all for exposing all hacks and removing all of them from the
FFmpeg codebase.

> Best regards,
> Jan Ekstroem
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list