wmv3 video track produced by GoToMeeting is transcoded to 1000 FPS h264

[almson]

Summary of the bug:

GoToMeeting produces screencaptures with wmv3 codec at a very low framerate (less than 1 fps). When transcoding to a different video format (like h264), ffmpeg makes a decision about what framerate to use for output. Unfortunately, instead of choosing something sane like 30 or 60, it chooses 1000. If the option -r 30 is added, transcoding works well.

This is a big issue at my company, because we try to accept videos in any format and transcode them to h264 while preserving their framerate. This codec comes up a significant percent of the time. If you know of a workaround that would preserve the framerate for other videos, please let us know!

How to reproduce:

% ffmpeg -i gotomeeting_screencapture.wmv -vcodec h264 -preset veryfast -acodec mp3 -f mp4 -y output.mp4
ffmpeg version 2.8.6-1ubuntu2 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.3.1 (Ubuntu 5.3.1-11ubuntu1) 20160311

also affects

ffmpeg version N-53104-g0910488-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.3.1 (Debian 5.3.1-8) 20160205

I've uploaded gotomeeting_screencapture.wmv to the FTP_

[Carl Eugen Hoyos]

Please test current FFmpeg git head and provide the tested command line together with the complete, uncut console output to make this a valid ticket.

[almson]

./ffmpeg-git-20160430-64bit-static/ffmpeg -i gotomeeting_screencapture.wmv -vcodec h264 -preset veryfast -acodec mp3 -f mp4 -y output.mp4
ffmpeg version N-79691-g66dd21d-static ​http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2016 the FFmpeg developers

built with gcc 5.3.1 (Debian 5.3.1-16) 20160424
configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --enable-frei0r --enable-libfribidi --disable-indev=sndio --disable-outdev=sndio --enable-librtmp --enable-libmfx --enable-libzimg --cc=gcc
libavutil 55. 23.100 / 55. 23.100
libavcodec 57. 38.100 / 57. 38.100
libavformat 57. 34.103 / 57. 34.103
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 44.100 / 6. 44.100
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100

[wmv3 @ 0x584d520] Extra data: 8 bits left, value: 20
Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, asf, from 'gotomeeting_screencapture.wmv':

Metadata:

WMFSDKNeeded : 0.0.0.0000
DeviceConformanceTemplate: MP@HL
WMFSDKVersion : 12.0.10011.16384
IsVBR : 1
VBR Peak : 5688576
Buffer Average : 325
WM/ToolVersion : 7.16.0 Build 4800
WM/ToolName : GoToMeeting
BitRateFrom the writer: 345055
Audio samples : 282
Video samples : 33
recording time : Mon, 02 May 2016 16:02:39 Eastern Daylight Time

Duration: 00:00:26.83, start: 0.000000, bitrate: 335 kb/s

Stream #0:0: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, 1 channels, fltp, 48 kb/s
Stream #0:1: Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 1920x1080, 6849 kb/s, 1k tbr, 1k tbn

[wmv3 @ 0x587b9c0] Extra data: 8 bits left, value: 20
[libx264 @ 0x584f2c0] MB rate (8160000) > level limit (2073600)
[libx264 @ 0x584f2c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
[libx264 @ 0x584f2c0] profile High, level 5.2
[libx264 @ 0x584f2c0] 264 - core 148 r265 3b70645 - H.264/MPEG-4 AVC codec - Copyleft 2003-2016 - ​http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 lookahead_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=1 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=10 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
[mp4 @ 0x584dd20] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.

Last message repeated 1 times

Output #0, mp4, to 'output.mp4':

Metadata:

WMFSDKNeeded : 0.0.0.0000
DeviceConformanceTemplate: MP@HL
WMFSDKVersion : 12.0.10011.16384
IsVBR : 1
VBR Peak : 5688576
Buffer Average : 325
WM/ToolVersion : 7.16.0 Build 4800
WM/ToolName : GoToMeeting
BitRateFrom the writer: 345055
Audio samples : 282
Video samples : 33
recording time : Mon, 02 May 2016 16:02:39 Eastern Daylight Time
encoder : Lavf57.34.103
Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1920x1080, q=2-31, 1k fps, 16k tbn
Metadata:

encoder : Lavc57.38.100 libx264

Side data:

cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1

Stream #0:1: Audio: mp3 (i[0][0][0] / 0x0069), 44100 Hz, mono, fltp
Metadata:

encoder : Lavc57.38.100 libmp3lame

Stream mapping:

Stream #0:1 -> #0:0 (wmv3 (native) -> h264 (libx264))
Stream #0:0 -> #0:1 (wmav2 (native) -> mp3 (libmp3lame))

Press [q] to stop, ? for help
[libmp3lame @ 0x5853560] Queue input is backward in time
[mp4 @ 0x584dd20] Non-monotonous DTS in output stream 0:1; previous: 16175, current: 15276; changing to 16176. This may result in incorrect timestamps in the output file.
frame=25679 fps=292 q=-1.0 Lsize= 10256kB time=00:00:26.10 bitrate=3218.9kbits/s dup=25824 drop=0 speed=0.296x
video:9736kB audio:204kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.181873%
[libx264 @ 0x584f2c0] frame I:105 Avg QP:15.32 size: 75963
[libx264 @ 0x584f2c0] frame P:6469 Avg QP:20.18 size: 105
[libx264 @ 0x584f2c0] frame B:19105 Avg QP:23.49 size: 69
[libx264 @ 0x584f2c0] consecutive B-frames: 0.8% 0.0% 0.1% 99.1%
[libx264 @ 0x584f2c0] mb I I16..4: 67.0% 21.1% 12.0%
[libx264 @ 0x584f2c0] mb P I16..4: 0.1% 0.0% 0.0% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% skip:99.9%
[libx264 @ 0x584f2c0] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.0% 0.0% 0.0% direct: 0.0% skip:100.0% L0:67.0% L1:32.9% BI: 0.1%
[libx264 @ 0x584f2c0] 8x8 transform intra:21.0% inter:67.3%
[libx264 @ 0x584f2c0] coded y,uvDC,uvAC intra: 20.5% 23.2% 11.8% inter: 0.0% 0.0% 0.0%
[libx264 @ 0x584f2c0] i16 v,h,dc,p: 79% 18% 3% 0%
[libx264 @ 0x584f2c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 37% 29% 3% 0% 0% 1% 1% 3%
[libx264 @ 0x584f2c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 28% 15% 4% 4% 4% 5% 4% 9%
[libx264 @ 0x584f2c0] i8c dc,h,v,p: 71% 19% 8% 2%
[libx264 @ 0x584f2c0] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x584f2c0] kb/s:3105.62

[Carl Eugen Hoyos]

Apart from fixing vfr in mov, I am not convinced that this can be improved at all.

[almson]

How about we cap the framerate at something reasonable like 30 or 60 fps?

[Carl Eugen Hoyos]

Replying to almson:

How about we cap the framerate at something reasonable like 30 or 60 fps?

As in: We do not allow 120fps videos?

[almson]

I mean we detect that we have this sort of variable framerate situation and then no, we don't allow 120 fps video. Or, idk, use 120 fps but not 1000.

[Carl Eugen Hoyos]

Given that your file has <5fps, I don't think limiting to 120fps really helps.
Note that the sample from ticket #4277 does have a framerate of 1000.

[almson]

It does help because the file will process 8x faster. Does ticket #4277 refer to a variable framerate file?

[almson]

It's probably overkill, but a parameter such as "--framerate-for-vfr-videos" would be perfect. The core problem is we want to set framerate only for videos which don't natively have one.