Quote:
Originally Posted by sneaker_ger
The logs look fine. Is your hardware otherwise OK, i.e. can you run memtest without any errors for hours? Maybe there are encoding errors which go unnoticed on more error resilient software decoders compared to your hardware decoder? I'd also say that you may want to look for bitrate spikes, but if your original 720p files already work fine, it's unlikely to be the source of the problem.
If you cannot find the error, you might want to test out HandBrake. It can burn in ASS subs and encode to mkv and mp4, all in one step. It only supports AC3 passthrough though, but that way you may be able to see if mkvmerge is at fault.
Just to be sure: you ARE remuxing your files with mkvmerge before putting them onto your phone, right? Because x264's mkv output has no index, which prevents proper seeking. |
I may give handbrake a try, although I'm more familiar with MeGUI and prefer it since I use it for multiple things and it does (used to) work. I actually did run memtest recently for a different reason and found no errors, but that still wouldn't explain why an older MeGUI package will encode these files and they will be seekable on my phone.
I am remuxing with MKVmerge, I add the output of MeGUI as well as the original, uncheck the original video and subtitle streams (and any any attachments/Chapters.txt) leaving only the new video stream and the old audio stream. Regardless of the order I select the files in, MKVmergeGUI selects the original source file as the output filename (with a '(1)' appended), not sure if this has to do with the index thing you were talking about.
Unless something has changed with MKVmerge (I know that it was updated recently with MeGUI) that is messing up the index on remuxing, but then would it still seek fine in software mode and on my laptop?