[FFmpeg-user] What is 'yuv420p(tv, smpte170m, progressive)'?
markfilipak.windows+ffmpeg at gmail.com
Tue May 19 16:56:51 EEST 2020
On 05/19/2020 02:18 AM, Carl Eugen Hoyos wrote:
>> Am 19.05.2020 um 06:18 schrieb Mark Filipak <markfilipak.windows+ffmpeg at gmail.com>:
>> relying on 'progressive' versus 'smpte170m'
> I don’t think this distinction makes any sense.
> Carl Eugen
Why do you say that, Carl Eugen?
If ffmpeg defines "progressive" as a video that contains picture-frames or soft telecine, then I
want to simply transcode.
If ffmpeg uses "smpte170m" with "progressive" to denote hard telecine, then I want to detelecine first.
If ffmpeg uses "smpte170m" without "progressive" to denote odd/even scan fields separated by
1/(field_rate) seconds (e.g. telecast video), then I want to either, 1, deinterlace, or 2, bob &
frame double before transcoding.
If all that is correct, and if I can use ffprobe to determine those cases, then I can automate the
transcodes via a script that processes individual source files or whole discs.
I realize there will be cases that require further probing (e.g. mixed sources such as "Making of"
documentaries) or that require special processing (e.g. totally screwed up 'PTS's and/or audio sync
problems), but those cases will be rare and will be evident when played back. I also realize that
fixing up audio & subtitle streams (e.g. naming and setting defaults) will require something like
MKVToolNix (or mkvmerge), but if I can bulk transcode several discs simultaneously, overnight, then
the bulk of the job can be done while I sleep and I can do the fixups in the morning -- remuxing is
I also realize that some videos use branching and that I have to look at 'mpls' & 'IFO' files
because ffmpeg doesn't support those (or does it?), but I'll know about branching in advance and
transcode them manually via HandBrake.
I value your input, but I need to understand it to make use of it. I hope that I've added enough
distinction that it now makes sense. And I hope you and others will post back.
Thanks, and Regards - Mark.
More information about the ffmpeg-user