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

[prefix1647]

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):

• OS: Win 11 Pro 22H2 (Build 22621.1105)
• NEAV1E Version: 2.1.1

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]

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.