Purple bars appear when scaling a video with ffmpeg for windows

[Leo Izen]

I try to scale a 1920x1080 video into 800x450 with FFmpeg and strange purple bars appear. To eliminate variables I used only yuv4mpegpipe files and try viewing with Windows Media Player, QuickTime, and VLC, and I get the same results.

The full ffmpeg -v 9 -loglevel 99 -i from the input file is this:

FFmpeg version git-N-29061-g5c00687, Copyright (c) 2000-2011 the FFmpeg developers

built on Apr 12 2011 16:33:59 with gcc 4.7.0 20110402 (experimental)
configuration: --enable-static --disable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-runtime-cpudetect --disable-avisynth --enable-bzlib --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libdirac --enable-libfaac --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-zlib --arch=x86_64 --cpu=i7 --enable-pic --enable-sram --prefix=/usr/local/x86_64-w64-mingw32 --cross-prefix=/usr/x86_64-w64-mingw32/bin/ --target-os=mingw32 --pkg-config=pkg-config --extra-libs='-lorc-0.4 -lx264' --enable-stripping --disable-debug --enable-w32threads
libavutil 50. 40. 1 / 50. 40. 1
libavcodec 52.119. 0 / 52.119. 0
libavformat 52.106. 0 / 52.106. 0
libavdevice 52. 4. 0 / 52. 4. 0
libavfilter 1. 78. 0 / 1. 78. 0
libswscale 0. 13. 0 / 0. 13. 0
libpostproc 51. 2. 0 / 51. 2. 0

[NULL @ 0000000021CFA390] Probed with size=2048 and score=100
[yuv4mpegpipe @ 0000000021CFA390] Probe buffer size limit 5000000 reached
[yuv4mpegpipe @ 0000000021CFA390] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'No-purple-bars.y4m':

Duration: N/A, bitrate: N/A

Stream #0.0, 2, 100/1199: Video: rawvideo, yuv420p, 1920x1080, 100/1199, PAR 1:1 DAR 16:9, 11.99 tbr, 11.99 tbn, 11.99 tbc

At least one output file must be specified

It says duration N/A but it is only 1 second long.

The output from scaling the video was this:
C:\Users\leo\Desktop>ffmpeg -v 9 -loglevel 99 -i No-purple-bars.y4m -s 800x450 -y Yes-purple-bars.y4m
FFmpeg version git-N-29061-g5c00687, Copyright (c) 2000-2011 the FFmpeg developers

built on Apr 12 2011 16:33:59 with gcc 4.7.0 20110402 (experimental)
configuration: --enable-static --disable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-runtime-cpudetect --disable-avisynth --enable-bzlib --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libdirac --enable-libfaac --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-zlib --arch=x86_64 --cpu=i7 --enable-pic --enable-sram --prefix=/usr/local/x86_64-w64-mingw32 --cross-prefix=/usr/x86_64-w64-mingw32/bin/ --target-os=mingw32 --pkg-config=pkg-config --extra-libs='-lorc-0.4 -lx264' --enable-stripping --disable-debug --enable-w32threads
libavutil 50. 40. 1 / 50. 40. 1
libavcodec 52.119. 0 / 52.119. 0
libavformat 52.106. 0 / 52.106. 0
libavdevice 52. 4. 0 / 52. 4. 0
libavfilter 1. 78. 0 / 1. 78. 0
libswscale 0. 13. 0 / 0. 13. 0
libpostproc 51. 2. 0 / 51. 2. 0

[NULL @ 00000000003AA560] Probed with size=2048 and score=100
[yuv4mpegpipe @ 00000000003AA560] Probe buffer size limit 5000000 reached
[yuv4mpegpipe @ 00000000003AA560] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'No-purple-bars.y4m':

Duration: N/A, bitrate: N/A

Stream #0.0, 2, 100/1199: Video: rawvideo, yuv420p, 1920x1080, 100/1199, PAR 1:1 DAR 16:9, 11.99 tbr, 11.99 tbn, 11.99 tbc

[buffer @ 00000000003AD120] w:1920 h:1080 pixfmt:yuv420p
[scale @ 00000000003ADC80] w:1920 h:1080 fmt:yuv420p -> w:800 h:450 fmt:yuv420p flags:0x4
Output #0, yuv4mpegpipe, to 'Yes-purple-bars.y4m':

Metadata:

encoder : Lavf52.106.0
Stream #0.0, 0, 1/90000: Video: rawvideo, yuv420p, 800x450 [PAR 1:1 DAR 16:9], 100/1199, q=2-31, 200 kb/s, 90k tbn, 11.99 tbc

Stream mapping:

Stream #0.0 -> #0.0

Press [q] to stop encoding
frame= 13 fps= 0 q=0.0 Lsize= 6856kB time=1.08 bitrate=51798.0kbits/s

video:0kB audio:0kB global headers:0kB muxing overhead 1.#INF00%

The ffmpeg -v 9 -loglevel 99 -i output for the output file is this:
FFmpeg version git-N-29061-g5c00687, Copyright (c) 2000-2011 the FFmpeg developers

built on Apr 12 2011 16:33:59 with gcc 4.7.0 20110402 (experimental)
configuration: --enable-static --disable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-runtime-cpudetect --disable-avisynth --enable-bzlib --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libdirac --enable-libfaac --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-zlib --arch=x86_64 --cpu=i7 --enable-pic --enable-sram --prefix=/usr/local/x86_64-w64-mingw32 --cross-prefix=/usr/x86_64-w64-mingw32/bin/ --target-os=mingw32 --pkg-config=pkg-config --extra-libs='-lorc-0.4 -lx264' --enable-stripping --disable-debug --enable-w32threads
libavutil 50. 40. 1 / 50. 40. 1
libavcodec 52.119. 0 / 52.119. 0
libavformat 52.106. 0 / 52.106. 0
libavdevice 52. 4. 0 / 52. 4. 0
libavfilter 1. 78. 0 / 1. 78. 0
libswscale 0. 13. 0 / 0. 13. 0
libpostproc 51. 2. 0 / 51. 2. 0

[NULL @ 00000000003CA3A0] Probed with size=2048 and score=100
[yuv4mpegpipe @ 00000000003CA3A0] Probe buffer size limit 5000000 reached
[yuv4mpegpipe @ 00000000003CA3A0] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'Yes-purple-bars.y4m':

Duration: N/A, bitrate: N/A

Stream #0.0, 10, 100/1199: Video: rawvideo, yuv420p, 800x450, 100/1199, PAR 1:1 DAR 16:9, 11.99 fps, 11.99 tbr, 11.99 tbn, 11.99 tbc

At least one output file must be specified

I uploaded the sample files (.y4m.xz) to the upload.

Now I noticed that the error only occurs in Windows, and not in Linux. I don't know why.

[Leo Izen]

That should say upload.ffmpeg.org not just upload.

[Leo Izen]

Version is git. Sorry for not specifying. Don't know how to change.

[Carl Eugen Hoyos]

I also cannot reproduce the problem on Linux, you will have to help finding the reason, please start with using a less experimental compiler and less configure options.

[ami_stuff]

@thebombzen

Are you able to reproduce this bug on your system?

https://ffmpeg.org/trac/ffmpeg/ticket/52

maybe related

[Leo Izen]

I found what is causing the problem. When compiled with --enable-runtime-cpudetect, the purple bars appear, but they disappear when it is compiled without it. This is the ffmpeg output from when it is compiled with --enable-runtime-cpudetect:

[Leo@chessman ~]$ ./ffmpeg_g.exe -v 9 -loglevel 99 -i No-purple-bars.y4m -s 800x450 Yes-purple-bars.y4m
ffmpeg version git-N-29343-g8a68697, Copyright (c) 2000-2011 the FFmpeg developers

built on Apr 24 2011 18:28:28 with gcc 4.5.3 20110401 (prerelease)
configuration: --enable-runtime-cpudetect --arch=i686 --target-os=mingw32 --enable-cross-compile --cross-prefix=/usr/i686-w64-mingw32/bin/ --enable-memalign-hack
libavutil 51. 0. 0 / 51. 0. 0
libavcodec 53. 1. 0 / 53. 1. 0
libavformat 53. 0. 3 / 53. 0. 3
libavdevice 53. 0. 0 / 53. 0. 0
libavfilter 2. 0. 0 / 2. 0. 0
libswscale 0. 13. 0 / 0. 13. 0

[NULL @ 0012C400] Format yuv4mpegpipe probed with size=2048 and score=100
[yuv4mpegpipe @ 0012C400] Probe buffer size limit 5000000 reached
[yuv4mpegpipe @ 0012C400] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'No-purple-bars.y4m':

Duration: N/A, bitrate: N/A

Stream #0.0, 2, 100/1199: Video: rawvideo, yuv420p, 1920x1080, 100/1199, PAR 1:1 DAR 16:9, 11.99 tbr, 11.99 tbn, 11.99 tbc

fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x01b6 ignored
[buffer @ 00173080] w:1920 h:1080 pixfmt:yuv420p
[scale @ 001733A0] w:1920 h:1080 fmt:yuv420p -> w:800 h:450 fmt:yuv420p flags:0x4
Output #0, yuv4mpegpipe, to 'Yes-purple-bars.y4m':

Metadata:

encoder : Lavf53.0.3
Stream #0.0, 0, 1/90000: Video: rawvideo, yuv420p, 800x450 [PAR 1:1 DAR 16:9], 100/1199, q=2-31, 200 kb/s, 90k tbn, 11.99 tbc

Stream mapping:

Stream #0.0 -> #0.0

Press [q] to stop encoding
frame= 13 fps= 0 q=0.0 Lsize= 6856kB time=1.08 bitrate=51798.0kbits/s
video:0kB audio:0kB global headers:0kB muxing overhead inf%

When I compiled without it, the purple bars weren't there and this is the output:

[Leo@chessman ~]$ ./ffmpeg_g.exe -v 9 -loglevel 99 -i No-purple-bars.y4m -s 800x450 Yes-purple-bars.y4m
ffmpeg version git-N-29343-g8a68697, Copyright (c) 2000-2011 the FFmpeg developers

built on Apr 24 2011 18:35:51 with gcc 4.5.3 20110401 (prerelease)
configuration: --arch=i686 --target-os=mingw32 --enable-cross-compile --cross-prefix=/usr/i686-w64-mingw32/bin/ --enable-memalign-hack
libavutil 51. 0. 0 / 51. 0. 0
libavcodec 53. 1. 0 / 53. 1. 0
libavformat 53. 0. 3 / 53. 0. 3
libavdevice 53. 0. 0 / 53. 0. 0
libavfilter 2. 0. 0 / 2. 0. 0
libswscale 0. 13. 0 / 0. 13. 0

[NULL @ 0012C400] Format yuv4mpegpipe probed with size=2048 and score=100
[yuv4mpegpipe @ 0012C400] Probe buffer size limit 5000000 reached
[yuv4mpegpipe @ 0012C400] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'No-purple-bars.y4m':

Duration: N/A, bitrate: N/A

Stream #0.0, 2, 100/1199: Video: rawvideo, yuv420p, 1920x1080, 100/1199, PAR 1:1 DAR 16:9, 11.99 tbr, 11.99 tbn, 11.99 tbc

fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x01b6 ignored
[buffer @ 00173080] w:1920 h:1080 pixfmt:yuv420p
[scale @ 001733A0] w:1920 h:1080 fmt:yuv420p -> w:800 h:450 fmt:yuv420p flags:0xa0000004
Output #0, yuv4mpegpipe, to 'Yes-purple-bars.y4m':

Metadata:

encoder : Lavf53.0.3
Stream #0.0, 0, 1/90000: Video: rawvideo, yuv420p, 800x450 [PAR 1:1 DAR 16:9], 100/1199, q=2-31, 200 kb/s, 90k tbn, 11.99 tbc

Stream mapping:

Stream #0.0 -> #0.0

Press [q] to stop encoding
frame= 13 fps= 0 q=0.0 Lsize= 6856kB time=1.08 bitrate=51798.0kbits/s
video:0kB audio:0kB global headers:0kB muxing overhead inf%

[Leo Izen]

How do I close/fix this?

[vickas54]

Maybe a good idea not to close this yet...looks like it might be related to asm optimizations??

It doesn't occur in the 32-bit build, (still running on Win7 64-bit of course) but it runs alot slower in the 32-bit build (about half as fast). Couple with the above statement about --enable-runtime-cpudetect causing it, I'm guessing some optimization code doesn't work very well in a 64-bit windows environment. I also suspect that the 32-bit build isn't actually using optimizations, considering it runs about half as fast. Perhaps this is only when running on 64-bit windows...

At least the 32-bit build gives correct output...

I'm using hawkeye's windows binaries from hawkeye.arrozcru.org. Unfortunately I don't have MinGW installed right now, so I can't try out any different compiler flags.

EDIT: I just noticed that thebombzen ran a 32-bit version with runtime-cpudetect and without, and yet on hawkeye's builds, both 32- and 64-bit builds have runtime-cpudetect enabled, and the 32-bit one doesn't have any purple scaling issue here....interesting. Did you run those builds on 32-bit windows or 64?

[vickas54]

Looks like the same thing as ticket#9. Anyone care to merge them?

[Leo Izen]

The purple bars glitch appeared with 64-bit on 64-bit vista, 32-bit on 64-bit vista, AND 32-bit with Wine. Because it also occurred with wine, it wasn't an OS problem.

[Carl Eugen Hoyos]

Is this still reproducible with current git head (or with a current release)?

[Carl Eugen Hoyos]

Please reopen if this is still reproducible.