| Message ID | 20180717093616.3647-1-barsnick@gmx.net |
|---|---|
| State | New |
| Headers | show |
The option still exists and is effective. See current line 3528 of fftool/ffmpeg_opt.c and the block at line 822 of fftool/ffmpeg_filter.c On 17-07-2018 03:06 PM, Moritz Barsnick wrote: > The "-deinterlace" option was removed in 481575d255195c6c2f32e04686b94de984ae78d4, > over five years ago. Refer to deinterlacing filters instead. That's a Libav no-op commit. It was merged in 42f5fc716e932b7b015d6605f2d88fc0eea4488b. Interestingly, the option was already deprecated at the time of merge but Michael then kept the option and replaced its code with yadif injection in 2013 in 4257b804e2354db07e66ebfd966d7d13f49c7895. However, he did not remove the deprecation notice. So, if that deprecation stands, we can remove the option/doc/code altogether, else remove the deprecation notice. Regards, Gyan
On Tue, Jul 17, 2018 at 16:00:33 +0530, Gyan Doshi wrote: > > The option still exists and is effective. See current line 3528 of > fftool/ffmpeg_opt.c and the block at line 822 of fftool/ffmpeg_filter.c > > On 17-07-2018 03:06 PM, Moritz Barsnick wrote: > > The "-deinterlace" option was removed in 481575d255195c6c2f32e04686b94de984ae78d4, > > over five years ago. Refer to deinterlacing filters instead. > > That's a Libav no-op commit. It was merged in > 42f5fc716e932b7b015d6605f2d88fc0eea4488b. Gee, that's no fun. I used "git -S" to search for changes, and found this commit in git master, and it didn't look like a no-op at all. But then, you're right, it touched avconv, and wasn't merged over to ffmpeg probably. > So, if that deprecation stands, we can remove the option/doc/code > altogether, else remove the deprecation notice. I guess it was undeprecated by making it work properly again, which is fair enough, as far as I'm concerned. Still, is it preferred to use a filter? Then my doc change stands. Whatever ;-) Patch dropped, Moritz
On 17-07-2018 04:52 PM, Moritz Barsnick wrote: > I guess it was undeprecated by making it work properly again, which is > fair enough, as far as I'm concerned. Still, is it preferred to use a > filter? Yes, the CLI option is global, so applies to all video streams. Most invocations I've seen of it are it set as an input option. Since those uses generally involve a single input and the filter passes through progressive content, no harm no foul. But it reinforces a wrong impression. Best to have it removed. Gyan
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index 3717f22d42..071ed7b1bc 100644 --- a/doc/ffmpeg.texi +++ b/doc/ffmpeg.texi @@ -835,8 +835,8 @@ factor if negative. Force interlacing support in encoder (MPEG-2 and MPEG-4 only). Use this option if your input file is interlaced and you want to keep the interlaced format for minimum losses. -The alternative is to deinterlace the input stream with -@option{-deinterlace}, but deinterlacing introduces losses. +The alternative is to deinterlace the input stream by use of a filter +such as @code{yadif} or @code{bwdif}, but deinterlacing introduces losses. @item -psnr Calculate PSNR of compressed frames. @item -vstats
The "-deinterlace" option was removed in 481575d255195c6c2f32e04686b94de984ae78d4, over five years ago. Refer to deinterlacing filters instead. Signed-off-by: Moritz Barsnick <barsnick@gmx.net> --- doc/ffmpeg.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)