[FFmpeg-user] Slight blur on converted video

[Andy Furniss]

Erik Dobberkau wrote:
>> W dniu 2017-03-24 o 12:04, Dave pisze:
>>
>>> To answer your suggestions Chronek:
>>>
>>> I tried encoding with your suggested command line it was still pretty
>>> much the same.
>>>
>>> 1) I downloaded a fresh copy of ffmpeg and compiled it and still had the
>>> same results
>>> 2) I am not really in a position to comment on
>>> 3) I assure you AME is using the same settings
>>> 4) Might be a possibility, I am a bit of a newbie when it comes to this.
>>> Below is the metadata for the original clip in case anything is lost in the
>>> cut down version.
>>>
>>> The cut down version of the clip was created with QuickTime and you can
>>> download it here:
>>>
>>> http://www.bit.st/screenshots/in.mp
>>> <http://www.bit.st/screenshots/in.mp4>
>>
>>
> I got a decent result with one of the latest zeranoe builds:
>
> ffmpeg -i in.mp4 -c:v prores_ks -profile:v 1 -flags +ilme+ildct -top 1 -vf
> scale=interl=1 -sws_flags +full_chroma_inp+full_chroma_int -c:a pcm_s16le
> -ar 48000 -ac 2  dave_proresLT.mov
>
> Setting sws_flags just makes a minimal difference. Vendor and vtag don't
> make any difference at all, except the writing library metadate. Pix_fmt is
> set automatically.
>
> The standard prores encoder is even blurrier than prores_ks, but it's twice
> as fast on my machine. What's interesting, DNxHD remains just as sharp when
> using the intermediate bitrate (115/120/145M, 8bpc), in comparison -- so 2
> more bpc doesn't automatically give you a "better" result.


Haven't had time to look properly just a couple of thoughts.

in.mp4 is not too good to start with! Lol at the hat when (guess)
the encoder makes the cloth texture appear and does psy so it stays
still for a while the hat moves, before disappearing.

The screenshots look worse than encoding this test, though it is
slightly blurred.

What are we looking with?

Me a crappy tn panel 8 bit in - but then dithered, more than that, what
are we playing with? Me using mpv + opengl so the conversion to rgb for
display does preserve the full 10 bit 422. Use another player and you
may find that it gets a cheap non interlace aware cludge down back to
yuv420p before getting converted to rgb.