search

Alkl58 / NotEnoughAV1Encodes

GUI for AV1 (aomenc, rav1e & svt-av1)
MIT License
543 stars 24 forks source link

[BUG] Using .m2ts or .264 as source files results in malformed/invalid output .mkvs using most recent tool binaries. #129

Open prefix1647 opened 1 year ago

prefix1647 commented 1 year ago

Describe the bug Using .m2ts container or .264 (video-only) as source files results in malformed/invalid output .mkvs using the most recent tool binaries.

To Reproduce Steps to reproduce the behavior:

  1. Use .m2ts or .264 source file instead of .mkv. Use latest 12/15/2022 builds of binary tools (and latest version of MKVToolNix).
  2. Run lib-aom encode job, 2-pass (as recommended for maximum encode efficiency). Chunking using PySceneDetect.
  3. Encode will run as normal, taking many hours (depending on system). Nothing will be in output folder, or if there is, it will be a malformed .mkv. For example. in my most recent test, all tracks are present but only the audio and subtitle tracks actually have data in them (the video track is 0-length except for metadata about its codec, color space, bit depth, resolution, and other such things).

The only test run that was successful and output a complete, working MKV file with video, audio, and subtitle track was when I re-muxed the .m2ts to .mkv manually first, then fed that .mkv into NEAV1E.

Expected behavior App should output a valid MKV file regardless of source container format or the number/type of tracks in the source container, except in cases where the source containers or formats are incompatible with ffmpeg (human-readable error should be thrown in the case). Considering that a complete non-free build of ffmpeg eats any actually-used-in-the-real-world formats, I'm thinking there shouldn't be any issues unless the source container/tracks are corrupted.

Log File Output of log file is identical to working encode with .mkv source file. No errors indicated in either logfile, both the failed and successful jobs indicate complete success with no problems.

Desktop (please complete the following information):

Additional context Currently, NEAV1E seems to only output valid MKV file if the source file is also MKV. At least, this is the case with the most recent tool builds as provided via the updater tool (I copied in the MKVToolNix 73 binaries myself). There is no indication of why the disparity is occurring in any log files. Log files indicate everything working successfully in all cases, so failures are happening silently and not being logged, or are not being detected as failures by ffmpeg or NEAV1E.

Alkl58 commented 1 year ago

Tried 264 and m2ts, two pass, py-scenedetect, importing audio (multiple combinations) with the latest mkvtoolnix version and so far it works.

Would it be possible to send me the source material (also possible on discord privately).

Will try different videos tomorrow, but so far can't reproduce sadly.