ffmpeg refuses to process Indeo3 resolutions not a multiple of 4.

[Sgeo]

Summary of the bug:

ffmpeg refuses to process Indeo3 resolutions not a multiple of 4. Attached is a video extracted from a game that appears to have such a resolution

How to reproduce:

Attempt to play attached video. Video extracted from a game via

ffmpeg -i SCIGUY.MOV -c copy

(and some manipulation of that file's first few bytes to extract different videos. Note that this process has, in fact, resulted in valid videos, see https://github.com/Sgeo/therock_decoder ) 

ffmpeg version:

C:\Users\Sgeo\Documents\Dev\Rust\therock_decoder>ffmpeg --help
ffmpeg version N-86950-g1bef008 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7.1.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib
  libavutil      55. 70.100 / 55. 70.100
  libavcodec     57.102.100 / 57.102.100
  libavformat    57. 76.100 / 57. 76.100
  libavdevice    57.  7.100 / 57.  7.100
  libavfilter     6. 98.100 /  6. 98.100
  libswscale      4.  7.102 /  4.  7.102
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
Hyper fast Audio and Video encoder


built on ...

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Sgeo]

ffmpeg -v 9 -loglevel 99 -i 12110633.mov

[Carl Eugen Hoyos]

Regression since cd645c15d8d91444e49aea589ace4d9f76210641

[giwiniswut]

Today i stumbled upon this as well. Currently the indeo3 decoder appears to reject resolutions that are not multiples of 8 (as opposed to 4 as OP experienced).

I removed that constraint from the indeo3.c file and ffmpeg seemed to convert the affected videos with "faulty" resolutions just fine.

I summarized my findings in this gist on GitHub: ​https://gist.github.com/SebiderSushi/be89ede578881f22c66d667e717c9859

I will attach these exact same files here as well, i mainly posted them inside a GitHub gist to get Markdown formatting.

[giwiniswut]

Summary of dodging this constraint, written in MarkDown

[giwiniswut]

Command line output of trying to convert the affected file in my case

[giwiniswut]

Command line output of successful conversion with patched ffmpeg

[Elon Musk]

Please share input indeo3 file.

[giwiniswut]

Hello sorry for my absence. Today i updated my git remotes and while rebasing my ffmpeg hacks i noticed that you changed that constraint. Thank you very much for taking care of this ticket!

I was holding off of sharing the input indeo3 files like you requested because the files i dealt with are not mine so i had asked the person that shared them with me for permission. Since they did not respond to that question i am sharing the files by my own judgement now as i'd say they are more or less public anyway because they were sent to me through a cloud drive link in a [comment on stackoverflow]​https://stackoverflow.com/questions/63164543/ffmpeg-webvtt-m3u8-download-into-single-vtt-file-ignore-the-x-timestamp-map-mp#comment116883606_65573828

I will attach them to this ticket as well if possible. As expected, with ~3.3MiB and ~10.3MiB the files are above the file size limit.

The relevant 2 file links from that stackoverflow comment are:
​https://1drv.ms/u/s!AgFGtfExBIBTkiGy1vB4oYvh5t4N?e=v4u7CV
​https://1drv.ms/u/s!AgFGtfExBIBTkjL1gZtJOz9CV9tz?e=12z3gb

Also, i uploaded the converted files i produced here: ​https://mega.nz/folder/AqpAmZxb#q4wInpkC_b9RZEVfVMkIRQ

I am bringing this up again since as i understand the commit 59dd70299007677bd1501973f537d54fc52b2746 to ffmpeg master weakened the constraint so that it now only rejects uneven values; however, one of the videos i'm dealing with has a resolution of 312x203, welp.

What is the technical reason behind this constraint, seeing as i was able to convert the exact same rejected video with my hacked up ffmpeg build?
FFmpeg automatically adjusted the resolution during conversion, so the video resolutions went from 182x182 to 184x184 and 312x203 to 312x204 while converting the videos i dealt with from indeo3 to h264 which i had enabled with the --enable-libx264 build option.

[Carl Eugen Hoyos]

Given that this is a regression, I think this is not an ideal solution.