I've written a batch file to split up a source file into individual files by GOP. I'm using an input file that has only a single video stream, as audio and other streams seemed to only make other problems arise, or perhaps was simply making this same issue have even worse consequences. The splitting is done via this command: ffmpeg -i input.mkv -c copy -map 0 -segment_time 00:00:01 -f segment -reset_timestamps 1 .\split\output%%06d.mkv Once I have those I do a slightly modified binary search encode job to hit a target VMAF score on all the individual GOPs. All those encoding jobs and subsequent VMAF comparisons all execute successfully. Once that is done I merge the results back into a single result file. Then, just to confirm, I run VMAF on the complete final result. Here's where the problem comes up. The file that I mux via these commands: for /f %%G in ('dir /b/on output*.mkv') do echo file '%%G' >> splitlist.txt ffmpeg -loglevel info -f concat -safe 0 -i splitlist.txt -c copy ..\finalresult.mkv seems to have some kind of problem. If I encode with a target VMAF of 97, and all the individual GOP files did indeed get encoded such that they all individually have a VMAF of 97, then it only follows naturally that the final result file will also have a VMAF of 97. However, the file that's been merged by ffmpeg in this fashion returns an absolutely horrible VMAF score. But if I take the same individual results files and use the mkvmerge GUI instead and then run it through VMAF it does indeed return a score of 97.x, as it should. finalresult.mkvmerge.VMAF 97.020162.mkv finalresult.ffmpeg.VMAF 47.014416 WTF.mkv ffmpeg is apparently doing something different, but I can't figure out what I might do to solve it. I would prefer to merge the files with ffmpeg simply because I can script that easily. Scripting that part of the job with mkvmerge is slightly more complicated and I'd hope to not have to go that route if I can avoid it. C:\temp2\Blade Runner 720x480 test>ffprobe "finalresult.mkvmerge.VMAF 97.020162.mkv" ffprobe version 2022-01-30-git-1530b3f566-full_build-www.gyan.dev Copyright (c) 2007-2022 the FFmpeg developers built with gcc 11.2.0 (Rev7, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 57. 19.100 / 57. 19.100 libavcodec 59. 20.100 / 59. 20.100 libavformat 59. 17.101 / 59. 17.101 libavdevice 59. 5.100 / 59. 5.100 libavfilter 8. 26.101 / 8. 26.101 libswscale 6. 5.100 / 6. 5.100 libswresample 4. 4.100 / 4. 4.100 libpostproc 56. 4.100 / 56. 4.100 Input #0, matroska,webm, from 'finalresult.mkvmerge.VMAF 97.020162.mkv': Metadata: title : Blade.Runner.1982.The.Final.Cut.2160p.BluRay.REMUX.HEVC.DTS-HD.MA.TrueHD.7.1.Atmos-FGT encoder : libebml v1.4.2 + libmatroska v1.6.4 creation_time : 2022-02-20T23:29:29.000000Z Duration: 01:57:31.33, start: 0.000000, bitrate: 3243 kb/s Stream #0:0: Video: hevc (Main), yuv420p(tv, smpte170m/smpte170m/bt709), 720x480 [SAR 32:27 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn (default) Metadata: BPS : 3242258 DURATION : 01:57:31.326000000 NUMBER_OF_FRAMES: 169064 NUMBER_OF_BYTES : 2857777985 _STATISTICS_WRITING_APP: mkvmerge v65.0.0 ('Too Much') 64-bit _STATISTICS_WRITING_DATE_UTC: 2022-02-20 23:29:29 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES C:\temp2\Blade Runner 720x480 test>ffprobe "finalresult.ffmpeg.VMAF 47.014416 WTF.mkv" ffprobe version 2022-01-30-git-1530b3f566-full_build-www.gyan.dev Copyright (c) 2007-2022 the FFmpeg developers built with gcc 11.2.0 (Rev7, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 57. 19.100 / 57. 19.100 libavcodec 59. 20.100 / 59. 20.100 libavformat 59. 17.101 / 59. 17.101 libavdevice 59. 5.100 / 59. 5.100 libavfilter 8. 26.101 / 8. 26.101 libswscale 6. 5.100 / 6. 5.100 libswresample 4. 4.100 / 4. 4.100 libpostproc 56. 4.100 / 56. 4.100 Input #0, matroska,webm, from 'finalresult.ffmpeg.VMAF 47.014416 WTF.mkv': Metadata: ENCODER : Lavf59.17.101 Duration: 01:57:31.80, start: 0.000000, bitrate: 3243 kb/s Stream #0:0: Video: hevc (Main), yuv420p(tv, smpte170m/smpte170m/bt709, progressive), 720x480 [SAR 32:27 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn Metadata: ENCODER : Lavc59.20.100 libx265 DURATION : 01:57:31.795000000 They're showing as different durations for some reason. And I'm not sure why the one that's been merged via ffmpeg doesn't display as much info via ffprobe. All I know is the ffmpeg version seems to start comparing in VMAF ok but at some point during the comparison it just falls off the rails as if the data suddenly has fallen out of step, akin to comparing two completely different video streams after that point. (Phantom frames making their way in somehow? Both VMAF output files list the same number of frames, though, so I guess not.) I've been trying to find something in ffmpeg's command line options that I could change or add, but so far I haven't seen anything obvious to me that I should do. Is there something I should have in this merging command that I'm missing, or am I simply stuck having to manually merge it with the mkvmerge GUI? Thanks. (Yes, I'm aware of av1an. Couldn't get it to do what I'd like under Windows, and I don't feel like setting up linux just for this task in hopes of the linux av1an package behaving better. I'm hitting my VMAF target within 0.1 already, and just hope I can sort out this merging automation issue.) -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be?
On Mon, Feb 21, 2022 at 2:40 PM Clayton Macleod <cherrytwist@gmail.com> wrote:
I've written a batch file to split up a source file into individual files by GOP.
Well, I think I've solved this on my own. I believe the issue with some of the sources I have been testing with is that things are crumbling when they are open GOP. I've taken some of the failed test subjects and done a lossless encode on them with closed GOP set and things are now working as they should with those previous failures. It only seems to have issues with open GOP files. This makes perfect sense, though I wish I knew of a quick and easy way to determine if a file was open or closed GOP. At first, the thought that it might be a GOP issue didn't even occur to me. At any rate, I'm pretty sure I've got this problem licked, seeing as how a reencode with closed GOP seems to do the trick. Thanks anyway. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be?
On Fri, Mar 4, 2022 at 12:27 AM Clayton Macleod <cherrytwist@gmail.com> wrote:
Well, I think I've solved this on my own.
I take that back. I've now encountered an example where I know for sure my input file is closed GOP and using ffmpeg to split the input file and later merge the output files does not work properly and I get a bad file, and again if I take the same output files and merge them with mkvmerge that output file is good. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be?
participants (1)
-
Clayton Macleod