[FFmpeg-user] VFR video re-encoding

[ValdikSS]

I'm trying to make a webm from it, saving VFR. To visually understand if the video is playing fine, look how Stripperella sign fades in.

This command gives 23.98 CFR as expected, dropping frames as it reaches opening. Opening stutters, as expected:

$ ffmpeg -i rkszxnz.mkv -threads 3 -speed 5 test.webm
…
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
Past duration 0.736259 too large    692kB time=00:00:09.71 bitrate= 583.0kbits/s   
Past duration 0.921074 too large                                                                                                                  
Past duration 0.917076 too large                                                                                                                  
Past duration 0.913078 too large                                                                                                                  
Past duration 0.933067 too large                                                                                                                  
Past duration 0.929070 too large    713kB time=00:00:10.76 bitrate= 542.8kbits/s dup=0 drop=3   
Past duration 0.925072 too large                                                                                                                  
Past duration 0.921074 too large
…

Adding -vsync 0:

$ ffmpeg -ss 00:00:45 -i rkszxnz.mkv -t 00:00:30 -b:v 0 -crf 40 -threads 3 -speed 4 -vsync 0 test2.webm

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
frame=  834 fps= 26 q=0.0 Lsize=    2584kB time=00:00:30.03 bitrate= 705.0kbits/s   
video:2578kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.234568%

No encoder or muxer messages, but the opening is not as smooth as in original video.

Ok, moving forward. If I add -copyts, ffmpeg crashes somewhere in libvpx:

$ ffmpeg -ss 00:00:45 -i rkszxnz.mkv -t 00:00:30 -b:v 0 -crf 40 -threads 3 -speed 4 -vsync 0 -copyts test3.webm
…
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help

Program received signal SIGSEGV, Segmentation fault.
0x00007fffef4d7390 in ?? () from /usr/lib/libvpx.so.3
(gdb) bt
#0  0x00007fffef4d7390 in ?? () from /usr/lib/libvpx.so.3
#1  0x00007fffef4fc0e3 in ?? () from /usr/lib/libvpx.so.3
#2  0x00007fffef49755a in ?? () from /usr/lib/libvpx.so.3
#3  0x00007fffef29a0c7 in vpx_codec_encode () from /usr/lib/libvpx.so.3
#4  0x00007ffff64175ae in ?? () from /usr/lib/libavcodec.so.56
#5  0x00007ffff65e6b6f in avcodec_encode_video2 () from /usr/lib/libavcodec.so.56
#6  0x0000555555560728 in main ()
(gdb) quit

But we can move -ss after -i and it would work fine:

$ ffmpeg -i rkszxnz.mkv -ss 00:00:45 -t 00:00:30 -b:v 0 -crf 40 -threads 3 -speed 4 -vsync 0 -copyts test3.webm
…
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
frame=  834 fps= 26 q=0.0 Lsize=    2584kB time=00:00:30.03 bitrate= 705.0kbits/s   
video:2578kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.234568%

Again, no notices or warnings from both muxer or encoder. Video does not playing smoothly.

Removing -vsync 0 leads to dropping frames and CFR video:

$ ffmpeg -i rkszxnz.mkv -ss 00:00:45 -t 00:00:30 -b:v 0 -crf 40 -threads 3 -speed 4 -copyts test4.webm
…
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
Past duration 0.736259 too large    691kB time=00:00:09.67 bitrate= 584.8kbits/s   
Past duration 0.921074 too large    699kB time=00:00:10.09 bitrate= 567.4kbits/s   
Past duration 0.917076 too large                                                                                                                  
Past duration 0.913078 too large
…

Using -copytb 0 with -vsync 0 gives stuttering video without notices or warnings:

$ ffmpeg -i rkszxnz.mkv -ss 00:00:45 -t 00:00:30 -b:v 0 -crf 40 -threads 3 -speed 4 -vsync 0 -copytb 0 test5.webm
…
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
frame=  834 fps= 10 q=0.0 Lsize=    2584kB time=00:00:30.03 bitrate= 705.0kbits/s   
video:2578kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.234568%
…


The same goes to -copytb 1.
Resulting videos are VFR, but probably wrongly muxed. You can see in Bomi or any other video player which can show FPS that the source file plays 29.97 fps in
opening almost all the time while VFR encoded files are jumping between 28 and 30 fps.

Is this a bug or am I missing something?


On 02/08/2016 02:09 AM, Nicholas Robbins wrote:
> On Sunday, February 7, 2016 1:28 PM, ValdikSS <iam at valdikss.org.ru> wrote:
>
> Why are you trying to "reencode it" that format looks fine to me. Are you trying to make it CFR?
>
>
> If you give us your complete input command and the complete, uncut, console output we can answer your question better.
>
> -Nick
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 856 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20160208/16597b68/attachment.sig>