[FFmpeg-user] No pixel format specified - meaning of yuv420p?

[Andy Furniss]

MRob wrote:
> Thank you for the very fast response, it's appreciated.
>
> On 2016-12-01 16:23, Lou wrote:
>> On Thu, Dec 1, 2016, at 03:00 PM, MRob wrote:
>>> I'm exporting a video from an older Adobe Elements (Windows)
>>> with intention to put it on the web (both H.264 and VP8). I
>>> exported using Adobe's "DV AVI" which appears to be the most
>>> unmolested output format
>>
>> DV is not a good choice: it's lossy and will mess up your width,
>> height, aspect ratio, etc. Install UT video. UT video is a free and
>> open compressed lossless format that works well as an intermediate
>> format:
>>
>> http://umezawa.dyndns.info/archive/utvideo/?C=M;O=D
>>
>> Then restart Elements and export using that. Make sure Elements
>> doesn't change the width, height, frame rate, etc (I recall Adobe
>> Media Encoder doing that often). Finally, re-enode the intermediate
>> file with ffmpeg.
>
> Oh, thank you for that information. Unfortunately, it looks like I'm
>  working with Premier Elements, and after installing UT video, I
> don't see any facilities to export using it. Is this a limitation of
> Premier? Or am I looking in the wrong place? Thanks for the off-topic
> help with that.
>
>> [...]
>>> But from reading that mailing list post and the error message
>>> text, it sounds like adding "-pix_fmt yuv420p" affects the
>>> output. I do not need to retain compatibility with terribly old
>>> devices (though I am using baseline level 3.0), so I wanted to
>>> ask if there is a better way to handle conversion in this case.
>>
>> You'll need yuv420p. Most non-FFmpeg based players and various
>> devices don't support anything else.
>
> I see, so the reason I hadn't seen that before was because any other
>  videos I'd encoded likely had the yuv420p pixel format in the video
>  stream already?

Possibly, or you didn't restrict to baseline.

You really should know what format the source video is is to do things
properly.

If say it's interlaced and stored as 422 or 411 then the default
conversion to 420 will be wrong. You would need to add interl=1 to the
scale filter (even then it's not truly correct, but the difference is
hard to see). If you want to keep as interlaced you would also need to
encode as MBAFF with libx264 and be sure to check field dominance is
correctly flagged in stream and container.

Of course if the source is interlaced and you just want something
"disposable" for the web rather than an archive, you could just
de-interlace it. Choices still involved = framerate/fieldrate, but may
(depending on source format) be able to avoid source chroma format issues.