I've been using Hybrid for years without issues, but in the most recent builds I've run into a bug when using MP4 Box with HEVC encoded files. After muxing the first GOP is completely black (i.e. first 250 frames), as if the I-frame data is missing entirely. When I switch to ffmpeg as the mp4 muxer I end up with stuttering playback of 20fps.
I've been using as a workaround a render into .mkv and then remuxing the mkv into .mp4 using ffmpeg on the command line and that worked well until the last two versions, when the HDR metadata I need to be embedded in the hevc stream stopped being embedded into the matroska file.
As part of my troubleshooting I did a full setting reset and reinstall of the latest Hybrid version. MP4 box crashed when the Signal PAR 1:1 was flagged, and then output video that would not decode until I flagged off RDO in the HEVC settings.
I've attached the log files for both the mp4 box and the ffmpeg encodes, and have available the output and source files in a Dropbox folder I can send you.Please, read the 'Infos needed to fix&reproduce bugs,..'-sticky before you post about a problem.
Quote:MP4 box crashed when the Signal PAR 1:1 was flagged
(strange thing is that the log doesn't contain any crash)
-> Can you please create another debug output (level 9) of the job processing?
Cu Selur
Ps.: I attached more recent builds of x265 and MP4Box for you, please check whether these fix the issue for you.
Also in case it is a problem with the decoding of the source try whether enabling "Config->Internals->Avisynth->Always use Avisynth" changes anything.
I also did some testing with your settings and had no problem with the job processing, encoding and muxing all went fine.
No problems real problems.
Crashes might be related to "--pmode --pme" which I normally don't use since it caused random crashes on any machine I tried it.
(reported it x265 devlopers didn't really care since the problem seems to appear randomly)
Cu Selur
I should have been clear - I didn't use the Signal PAR 1:1 for the outputs I generated because that was an easy flag to ignore. I've generated that log output in this set of log files.
I tried replacing MP4Box and x265 with the files you sent and that didn't work, and ran the decode using avisynth with both mp4box and ffmpeg for the muxer - I'm still seeing stuttering on the video muxed with FFMPEG and the first 250 frames dropped with mp4 box. I'll send a link to the output files so you can see what I'm seeing in an email.
(30.06.2017, 19:30)Selur Wrote: [ -> ]-> try disabling '--repeat-headers' (x265->Misc->Random Stuff->Repeat headers)
This fixed the blacked out first GOP in the MP4Box mux. Still not sure why the FFMPEG one still fails, but at least I'm able to get usable files - I'll submit a bug report to MP4Box dev group to see if they can fix what's causing it!
Thanks for your help!
For ffmpeg: did you try enabling "Config->Internal->Handling->Ignore all input timecodes" ?
I also checked the ffmpeg file again and for me it doesn't stutter,... (even runs smooth when I play it with the dropbox player inside the browser,..)
I tried ignoring all input timecodes, and that didn't make a difference.
I do now see what you're seeing though with the FFmpeg file - I just tested it on my mac using MPV for playback and had no issues vs. on my Windows, where I'm using MPC-HC for playback, which means that there's something in that stream that some decoders don't like. It also looks like MPV was simply skipping the bad GOP on the mp4box encoded file which made it look like it was working by simply dropping the first 8 seconds. Dropbox, who reencodes the files into H.264 for the web look, seems to have forced a constant frame rate to the FFmpeg version and that 'fixed' it, but for the reencode the one done with Mp4box holds the first valid frame for 8 seconds at the start of that video.
I can't seem to wrap my head around this because x265 which is encoding both the files muxed in MP4box and FFmpeg shouldn't be doing anything different between the two streams and its something in the way that FFmpeg is wrapping it? I'll keep doing some tests on my end to see what happens with other decoding applications.
FFmpeg and MP4Box always wrapped video streams a bit different and since ffmpeg often had more issues Hybrid by default uses MP4Box. (+ usually the MP4Box dev team is more responsive and friendly to bug reports)