FS#26905 - [ffmpeg] fails to convert ppm to mp4 properly?

Attached to Project: Arch Linux
Opened by Matthias Krüger (matthiaskrgr) - Tuesday, 15 November 2011, 16:52 GMT
Last edited by Ionut Biru (wonder) - Sunday, 11 December 2011, 21:42 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
A few days ago, converting ppm streams from 'gource' to mp4 worked just fine.
The command I used was

gource -1200x720 --key --camera-mode overview --highlight-all-users --file-idle-time 0 -auto-skip-seconds 0.001 --seconds-per-day 0.5 --hide progress,mouse --stop-at-end --max-files 99999999999 --max-file-lag 0.00001 --output-ppm-stream - | ffmpeg -f image2pipe -vcodec ppm -i - -y -vcodec libx264 -threads 4 -b 3000k -maxrate 8000k -bufsize 10000k video.mp4

When I do the same now (I had to replace -b with -b:v because ffmpeg complained):


gource -1200x720 --key --camera-mode overview --highlight-all-users --file-idle-time 0 -auto-skip-seconds 0.001 --seconds-per-day 0.5 --hide progress,mouse --stop-at-end --max-files 99999999999 --max-file-lag 0.00001 --output-ppm-stream - | ffmpeg -f image2pipe -vcodec ppm -i - -y -vcodec libx264 -threads 4 -b:v 3000k -maxrate 8000k -bufsize 10000k video.mp4

, ffmpeg gets me this output:


ffmpeg version N-34586-g33feba3, Copyright (c) 2000-2011 the FFmpeg developers
built on Nov 8 2011 14:45:52 with gcc 4.6.2
configuration: --prefix=/usr --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libvpx --enable-libtheora --enable-libgsm --enable-libspeex --enable-postproc --enable-shared --enable-x11grab --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libschroedinger --enable-libopenjpeg --enable-librtmp --enable-gpl --enable-version3 --enable-runtime-cpudetect --disable-debug --disable-static
libavutil 51. 24. 0 / 51. 24. 0
libavcodec 53. 29. 0 / 53. 29. 0
libavformat 53. 20. 0 / 53. 20. 0
libavdevice 53. 4. 0 / 53. 4. 0
libavfilter 2. 47. 0 / 2. 47. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 51. 2. 0 / 51. 2. 0
[image2pipe @ 0x2301880] Estimating duration from bitrate, this may be inaccurate
Input #0, image2pipe, from 'pipe:':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: ppm, rgb24, 1200x720, 25 tbr, 25 tbn, 25 tbc
[buffer @ 0x230a7c0] w:1200 h:720 pixfmt:rgb24 tb:1/1000000 sar:0/1 sws_param:
[libx264 @ 0x230b040] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
[libx264 @ 0x230b040] profile High 4:4:4 Predictive, level 3.1, 4:4:4 8-bit
[libx264 @ 0x230b040] 264 - core 119 - H.264/MPEG-4 AVC codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=4 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=3000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=8000 vbv_bufsize=10000 nal_hrd=none ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'pacmanlog2gource_Nov_15_2011.mp4':
Metadata:
encoder : Lavf53.20.0
Stream #0:0: Video: h264 (![0][0][0] / 0x0021), rgb24, 1200x720, q=-1--1, 3000 kb/s, 25 tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (ppm -> libx264)
frame= 735 fps= 23 q=-1.0 Lsize= 1452kB time=00:00:29.32 bitrate= 405.6kbits/s
video:1440kB audio:0kB global headers:0kB muxing overhead 0.800530%
[libx264 @ 0x230b040] frame I:3 Avg QP: 5.67 size: 16641
[libx264 @ 0x230b040] frame P:261 Avg QP: 0.25 size: 2947
[libx264 @ 0x230b040] frame B:471 Avg QP: 1.09 size: 1391
[libx264 @ 0x230b040] consecutive B-frames: 14.3% 0.8% 0.0% 84.9%
[libx264 @ 0x230b040] mb I I16..4: 65.1% 33.4% 1.5%
[libx264 @ 0x230b040] mb P I16..4: 0.1% 0.0% 0.0% P16..4: 0.3% 0.1% 0.1% 0.0% 0.0% skip:99.4%
[libx264 @ 0x230b040] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.2% 0.1% 0.0% direct: 0.1% skip:99.6% L0:43.3% L1:39.9% BI:16.8%
[libx264 @ 0x230b040] final ratefactor: -18.81
[libx264 @ 0x230b040] 8x8 transform intra:31.2% inter:15.2%
[libx264 @ 0x230b040] coded y,u,v intra: 2.4% 2.5% 2.5% inter: 0.2% 0.2% 0.2%
[libx264 @ 0x230b040] i16 v,h,dc,p: 97% 1% 2% 0%
[libx264 @ 0x230b040] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 4% 72% 0% 0% 0% 0% 0% 0%
[libx264 @ 0x230b040] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 25% 25% 3% 3% 4% 3% 5% 5%
[libx264 @ 0x230b040] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x230b040] ref P L0: 73.5% 8.7% 10.7% 7.1%
[libx264 @ 0x230b040] ref B L0: 74.2% 19.5% 6.3%
[libx264 @ 0x230b040] ref B L1: 91.1% 8.9%
[libx264 @ 0x230b040] kb/s:401.13


and the video just appears to be completely green watched with vlc player.

When I watch the video using mplayer, the video is not just a green screen, but the colors of things are wrong.


Additional info:
ffmpeg 20111108-1
gource 0.37-1
x264 20111030-1

Regards, Matthias
This task depends upon

Closed by  Ionut Biru (wonder)
Sunday, 11 December 2011, 21:42 GMT
Reason for closing:  Fixed
Additional comments about closing:  ffmpeg 20111211
Comment by Ionut Biru (wonder) - Tuesday, 15 November 2011, 17:33 GMT Comment by Matthias Krüger (matthiaskrgr) - Tuesday, 15 November 2011, 17:42 GMT
I can reproduce the problem with
ffmpeg-20111115-1-x86_64.pkg.tar.xz 15-Nov-2011 17:33 3.4M
, too.
Comment by Ionut Biru (wonder) - Tuesday, 15 November 2011, 17:58 GMT
can you report this issue on ffmpeg tracker? note that 20111115 is git master HEAD
Comment by DrZaius (DrZaius) - Tuesday, 15 November 2011, 19:47 GMT
Your output is RGB24. VLC from the repository apparently will not decode this as expected, but ffplay probably will convert from RGB to YUV properly upon playback. Alternatively, you can force the FFmpeg output to yuv420p which anything should play fine.

ffmpeg -f image2pipe -vcodec ppm -i - -y -vcodec libx264 -preset medium -crf 22 -pix_fmt yuv420p video.mp4

I wouldn't call this a bug with FFmpeg unless you think the default behavior should be changed to auto-select "-pix_fmt yuv420p" for RGB24 inputs when encoding with libx264. x264 does technically support RGB, but YUV usually recommended. This was reported as a bug already, and closed as invalid, but it might not be a bad idea now that I think about it more. Add your comment here if you like:

https://ffmpeg.org/trac/ffmpeg/ticket/585
Comment by DrZaius (DrZaius) - Tuesday, 15 November 2011, 21:09 GMT
Forget that last ticket, this one is more appropriate:
https://ffmpeg.org/trac/ffmpeg/ticket/658
Comment by DrZaius (DrZaius) - Monday, 05 December 2011, 19:26 GMT
"Fixed" upstream. Now yuv420p will be auto-selected for this type of input (upstream commit dd974c1bc1dc3116fffdbbb28a4ebfce7e1318ee). However, I wouldn't really call this a bug with FFmpeg as H.264 RGB is a valid output (although usually not desired). Until Arch updates FFmpeg just add "-pix_fmt yuv420p" to your command and you'll get a normal output that anything should be able to play.

Loading...