ffmpeg incorrectly classifies .yuv input format as "gsm"

[Martin]

Summary of the bug:

Input a raw 4:2:0 .yuv, attempting to pad black pixels
ffmpeg classifies the image as "gsm", then fails to parse image dimensions supplied, using either "-s WxH" or "-video_size WxH"

How to reproduce:

ffmpeg -y  -v 99 -pix_fmt yuv420p -video_size 1882x1062 -i "problem_file.yuv"
 -vf "pad=iw+16:ih+8:0:0:color=0x000000, format=pix_fmts=yuv420p" "problem_file_pad.yuv"

ffmpeg version 4.4.1-static https://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg
  libavutil      56. 70.100 / 56. 70.100
  libavcodec     58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter     7.110.100 /  7.110.100
  libswscale      5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
Splitting the commandline.
Reading option '-y' ... matched as option 'y' (overwrite output files) with argument '1'.
Reading option '-v' ... matched as option 'v' (set logging level) with argument '99'.
Reading option '-pix_fmt' ... matched as option 'pix_fmt' (set pixel format) with argument 'yuv420p'.
Reading option '-video_size' ... matched as AVOption 'video_size' with argument '1882x1062'.
Reading option '-i' ... matched as input url with argument 'problem_file.yuv'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with argument 'pad=iw+16:ih+8:0:0:color=0x000000, format=pix_fmts=yuv420p'.
Reading option 'problem_file_pad.yuv' ... matched as output url.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option y (overwrite output files) with argument 1.
Applying option v (set logging level) with argument 99.
Successfully parsed a group of options.
Parsing a group of options: input url problem_file.yuv.
Applying option pix_fmt (set pixel format) with argument yuv420p.
Successfully parsed a group of options.
Opening an input file: problem_file.yuv.
[NULL @ 0x6f601c0] Opening 'problem_file.yuv' for reading
[file @ 0x6f60f00] Setting default whitelist 'file,crypto,data'
Probing gsm score:51 size:2048
[gsm @ 0x6f601c0] Format gsm probed with size=2048 and score=51
st:0 removing common factor 160 from timebase
Option video_size not found.

Notes: This error only occurs with one of my images (attached) out of 166.

Workaround: Add input file option "-f rawvideo" to force ffmpeg to classify the input image format as "rawvideo".

ffmpeg -y  -v 99 -pix_fmt yuv420p -f rawvideo -video_size 1882x1062 -i "problem_file.yuv"
 -vf "pad=iw+16:ih+8:0:0:color=0x000000, format=pix_fmts=yuv420p" "problem_file_pad.yuv"

[Martin]

input file to command, compressed

[Balling]

Workaround: Add input file option "-f rawvideo" to force ffmpeg to

That is not a workaround. That is what you are supposed to do. Also, why .yuv file has ASCII letters patterns inside?

[Balling]

-pix_fmt is a parameter that is deprecated as a global paramater. There is another -pix_fmt option that is not deprecated that is inside -f rawvideo

no header

Maybe you should use y4m

[Martin]

I'm really not sure what you are trying to say here.

Here are the image metadata:

"width":1882,
"height":1062,
"depth": 8bit,
"layers": 3,
"model": yuv,
"sampling": 420,
"swing": studio,
"pixel_format": yuv420p,
"space":"sRGB",
"colour_primaries": "bt709",
"colour_matrix": "bt709",
"transfer_function": "iec61966",

I have many images all of the exact same type, just different dimensions and different pixel values, and ffmpeg processes these correctly without requiring "-f rawvideo" to be specified.

There is a bug in ffmpeg triggered by this input image causing a failure.

[Balling]

pixel_format: yuv420p

Okay, the file got corrupted on extract.

without requiring "-f rawvideo" to be specified.

Does not it warn that option -pix_fmt is deprecated then?

[Martin]

Does not it warn that option -pix_fmt is deprecated then?

There are 0 deprecation warnings in my entire log.

'Can't be yuv420p...'

The "p" in yuv420p simply refers to the ordering of pixel values:
p = planar = [Y_1...Y_N][U_1...U_N/4][V_1...V_N/4]

The pixel values are stored contiguously in the .yuv file with no delimiters.
It is up to ffmpeg to separate these planes if necessary, given the correct arguments.

[Martin]

Another option in case you cannot decompress *.7z successfully