H.264 MKV Seek Issues (Again)

[GG-Xtreme]

I posted a thread here a while ago about an issue I was having: H.264 MKV's I encoded using MeGUI and DirectShowSource would not seek properly on my Galaxy S Android phone, causing it to freeze or crash while seeking past a certain point (usually between halfway and 2/3rds of the way through the video). If allowed to play normally from the beginning, the videos play all the way through.

The issue was resolved by using FFVideoSource, although no one could explain why this change fixed anything. Now, after using MeGUI for a while with success, it seems the ffms2 has been updated or something--now videos I encode using FFVideoSource refuse to seek at ALL on my phone. Once again, allowed to play through from the beginning, they play fine, but any seeking causes the video frame to freeze while audio plays in the background, and the phone will be unresponsive until the video is stopped.

The videos are encoded using the x264 scratchpad profile tuned for better quality and animation, at 23.976fps and 800x450 resolution. The original MKV's used to make the source are 720p MKV's, and they play and seek just fine on my phone (although the point of reencoding them is to hardsub them so I don't have to deal with my phone's poor SSA subtitle support).

Would anyone have an idea as to what part of the the process is going wrong or part of the H264 stream is tripping up the phone's hardware decoding? (Software playback of all videos seeks fine, but that's an annoying workaround; all videos seek and play fine on my laptop with both software and hardware decoding) Perhaps someone would know if any recent changes in ffms2 could have caused this.

I'll install an old build of MeGUI in the meantime to encode videos, but I would really like to get to the bottom of this.

[sneaker_ger]

Are you encoding to mp4 or to mkv? Can you put on the log files? What happens if you manually add "--fps 24000/1001" to the x264 command line?

[GG-Xtreme]

Are you encoding to mp4 or to mkv? Can you put on the log files? What happens if you manually add "--fps 24000/1001" to the x264 command line?

I am encoding directly to MKV so that I can remux with audio from the original file using MKVmerge. My AVS looks something like this for all files (I have also tried using .AssumeFPS(), which made no difference):
LoadPlugin("C:\Program Files (x86)\Haali\MatroskaSplitter\avss.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("C:\Path\to\720p.mkv", fpsnum=24000, fpsden=1001)
#deinterlace
#crop
LanczosResize(800,450) # Lanczos (Sharp)
#denoise

LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\VSFilter.dll")
TextSub("C:\Path\to\720p_track3.ass", 1)


My encoder settings look like this:
program --preset slow --tune animation --crf 18.0 --output "output" "input"

I'm running a job as a test right now, I'll post the log when it's done.

Edit: Logs
-[Information] Log for job1 (video, 720p.mkv.avs -> 450p_noaudio.mkv)
--[Information] [5/5/2011 2:15:56 AM] Started handling job
--[Information] [5/5/2011 2:15:56 AM] Preprocessing
--[Information] [5/5/2011 2:15:56 AM] Avisynth input script
---[NoImage] LoadPlugin("C:\Program Files (x86)\Haali\MatroskaSplitter\avss.dll")
---[NoImage] LoadPlugin("C:\Program Files (x86)\MeGUI\tools\ffms\ffms2.dll")
---[NoImage] FFVideoSource("C:\Path\to\720p.mkv", fpsnum=24000, fpsden=1001)
---[NoImage] #deinterlace
---[NoImage] #crop
---[NoImage] LanczosResize(800,450) # Lanczos (Sharp)
---[NoImage] #denoise
---[NoImage] LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\VSFilter.dll")
---[NoImage] TextSub("C:\Path\to\720p_track3.ass", 1)
--[Information] [5/5/2011 2:15:57 AM] Job commandline: "C:\Program Files (x86)\MeGUI\tools\x264\vfw4x264.exe" --preset slow --tune animation --crf 18.0 --sar 1:1 --output "C:\Path\to\450p_noaudio.mkv" "C:\Path\to\720p.mkv.avs"
--[Information] [5/5/2011 2:15:57 AM] Encoding started
--[Information] [5/5/2011 2:31:28 AM] Standard output stream
--[Information] [5/5/2011 2:31:28 AM] Standard error stream
---[NoImage] raw [info]: 800x450p 1:1 @ 24000/1001 fps (cfr)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
---[NoImage] x264 [info]: profile High, level 3.1
---[NoImage]
---[NoImage] x264 [info]: frame I:296 Avg QP:13.97 size: 60828
---[NoImage] x264 [info]: frame P:7961 Avg QP:16.36 size: 9204
---[NoImage] x264 [info]: frame B:26268 Avg QP:21.52 size: 1145
---[NoImage] x264 [info]: consecutive B-frames: 2.7% 4.0% 6.3% 25.5% 15.3% 46.2%
---[NoImage] x264 [info]: mb I I16..4: 20.6% 37.0% 42.4%
---[NoImage] x264 [info]: mb P I16..4: 3.4% 3.4% 2.2% P16..4: 32.0% 10.4% 7.6% 0.0% 0.0% skip:41.0%
---[NoImage] x264 [info]: mb B I16..4: 0.2% 0.3% 0.1% B16..8: 15.1% 1.8% 0.7% direct: 1.2% skip:80.7% L0:38.6% L1:55.9% BI: 5.5%
---[NoImage] x264 [info]: 8x8 transform intra:38.1% inter:64.6%
---[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 49.0% 70.7% 51.2% inter: 6.3% 9.7% 3.2%
---[NoImage] x264 [info]: i16 v,h,dc,p: 44% 23% 11% 21%
---[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 11% 21% 7% 8% 8% 8% 8% 10%
---[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 12% 14% 7% 9% 9% 7% 8% 8%
---[NoImage] x264 [info]: i8c dc,h,v,p: 44% 23% 22% 10%
---[NoImage] x264 [info]: Weighted P-Frames: Y:3.8% UV:3.2%
---[NoImage] x264 [info]: ref P L0: 55.1% 5.2% 15.5% 6.5% 4.6% 4.2% 3.2% 1.9% 1.8% 1.8% 0.2% 0.0%
---[NoImage] x264 [info]: ref B L0: 78.0% 9.2% 5.4% 2.1% 1.7% 1.4% 1.2% 0.6% 0.4%
---[NoImage] x264 [info]: ref B L1: 93.8% 6.2%
---[NoImage] x264 [info]: kb/s:674.18
---[NoImage] encoded 34525 frames, 37.09 fps, 674.18 kb/s
--[Information] Final statistics
---[Information] [5/5/2011 2:31:29 AM] Constant Quality Mode: Quality 18 computed...
---[Information] [5/5/2011 2:31:29 AM] Video Bitrate Obtained (approximate): 675 kbit/s
--[Information] [5/5/2011 2:31:29 AM] Postprocessing
---[Information] Deleting intermediate files
--[Information] [5/5/2011 2:31:29 AM] Job completed


If it helps, here is a log from a video I encoded that has no problems seeking on my phone:
---[NoImage] x264 [info]: frame I:298 Avg QP:14.04 size: 61201
---[NoImage] x264 [info]: frame P:9780 Avg QP:17.51 size: 10412
---[NoImage] x264 [info]: frame B:24038 Avg QP:22.27 size: 2788
---[NoImage] x264 [info]: consecutive B-frames: 4.8% 7.7% 9.4% 52.7% 10.0% 15.4%
---[NoImage] x264 [info]: mb I I16..4: 22.5% 38.4% 39.1%
---[NoImage] x264 [info]: mb P I16..4: 3.6% 6.0% 2.8% P16..4: 31.0% 11.3% 7.9% 0.0% 0.0% skip:37.5%
---[NoImage] x264 [info]: mb B I16..4: 0.5% 1.2% 0.4% B16..8: 20.5% 4.8% 1.8% direct: 2.0% skip:68.8% L0:46.8% L1:46.2% BI: 7.0%
---[NoImage] x264 [info]: 8x8 transform intra:48.9% inter:65.4%
---[NoImage] x264 [info]: direct mvs spatial:99.9% temporal:0.1%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 58.3% 67.9% 38.7% inter: 11.4% 12.4% 3.0%
---[NoImage] x264 [info]: i16 v,h,dc,p: 30% 26% 9% 36%
---[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 14% 13% 6% 10% 8% 10% 8% 12%
---[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 13% 13% 7% 11% 9% 9% 8% 9%
---[NoImage] x264 [info]: i8c dc,h,v,p: 42% 27% 19% 12%
---[NoImage] x264 [info]: Weighted P-Frames: Y:2.3% UV:1.7%
---[NoImage] x264 [info]: ref P L0: 48.5% 5.7% 14.4% 7.2% 5.3% 5.0% 4.7% 3.5% 2.6% 2.5% 0.6% 0.0%
---[NoImage] x264 [info]: ref B L0: 62.2% 12.7% 7.7% 4.5% 3.6% 3.8% 3.0% 1.7% 0.9%
---[NoImage] x264 [info]: ref B L1: 92.2% 7.8%
---[NoImage] x264 [info]: kb/s:1051.87
---[NoImage] encoded 34116 frames, 27.83 fps, 1051.87 kb/s
--[Information] Final statistics
---[Information] [4/9/2011 7:20:31 AM] Constant Quality Mode: Quality 18 computed...
---[Information] [4/9/2011 7:20:31 AM] Video Bitrate Obtained (approximate): 1053 kbit/s

[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 (http://handbrake.fr/). 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.

[GG-Xtreme]

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 (http://handbrake.fr/). 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?

[sneaker_ger]

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.

It has not.

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?

You would see it as buffering, slow or wrong seeking.

To pin down the error you could:
1.) create a video only mkv to make sure it's not a problem with the sound
2.) downgrade mvkmerge
3.) downgrade x264

[GG-Xtreme]

You would see it as buffering, slow or wrong seeking.

To pin down the error you could:
1.) create a video only mkv to make sure it's not a problem with the sound
2.) downgrade mvkmerge
3.) downgrade x264

Ok, I've started doing some testing. Using VLC (doesn't happen in MPC), the distortion/slow seeking you described DOES occur with the MeGUI output file, but does NOT occur on the remuxed MKV that MKVmerge outputs.

Ok, I think the problem is the audio...but it isn't :confused:. When I remuxed the MeGUI output without audio, my phone displays an "Unsupported File" message, but then the file plays and seeks fine. But the audio is the exact track, untouched, from the source file--which plays and seeks fine on my phone.

This behavior is consistent across several different source files encoded by different people, with the only thing in common being that the audio is a 48KHz stereo AAC (and that I reencoded and remuxed the video). With the last file I encoded that did not exhibit the problem (before MeGUI was updated), I actually re-encoded the audio myself (still to 48KHz stereo AAC), but I was also using an older version of MeGUI/ffms2/MKVmerge.

I'm going to test an old version of MKVmerge, and if that doesn't work, an older version of MeGUI/ffms2/x264 and post back my results.

[sneaker_ger]

Different versions of MeGUI itself and ffms2 shouldn't make a difference. Concentrate on mkvmerge and x264.
The only thing where different ffms2 versions could have an impact is the detection of the framerate, but according to your logs it's already correctly recognized by x264 as 24000/1001 (cfr).

[GG-Xtreme]

Different versions of MeGUI itself and ffms2 shouldn't make a difference. Concentrate on mkvmerge and x264.
The only thing where different ffms2 versions could have an impact is the detection of the framerate, but according to your logs it's already correctly recognized by x264 as 24000/1001 (cfr).

Shouldn't make a difference, but then again, I originally switched to ffms2 from dss because of different seek issues created by the latter. Btw, thanks for all the help so far, I feel that I'm close to solving this issue :)

I did try all of the following with no luck:
-with new mkvmerge:
*remux after first extracting the AAC stream (instead of muxing straight with the original video file)
*remux after first extracting the AAC stream and muxing it into an m4a
*remux after first extracting the AAC and re-encoding it with Nero AAC
-with old mkvmerge:
*remux normally
*same things I tried with the new mkvmerge

That leaves everything down to the video encoding...onto the more lengthly testing.

[GG-Xtreme]

Ok, I'm lost again. I tried every combination of old MeGUI/ffms2/x264 (I even tried dss) and old mkvmerge, as well as every combination of an up-to-date MeGUI and mkvmerge (including re-encoding all the audio streams, a total of almost 30 test files), and my issue is not resolved. I still cannot seek at all on my phone (video frame freezes and audio plays in the background, attempting to resume a stopped video from any point other than the beginning results in a black screen and no sound).

But at the same time, all videos I encoded previously using the older version of MeGUI/mkvmerge still seek fine on my phone, as well as all the source MKV's I'm using for my encoding. I'm baffled, so I'm going to try another computer (even though I've always used this computer for encoding), and if that doesn't work...any suggestions? :confused:

[sneaker_ger]

Not really.

You don't happen to have increased your keyframe interval compared to your older encodes, do you?

[GG-Xtreme]

Not really.

You don't happen to have increased your keyframe interval compared to your older encodes, do you?

I've never touched anything that mentioned keyframes. I've always used the avisynth and x264 parameters in my first post.

[sneaker_ger]

The log on the working file doesn't show the keyint.
Can you put up a complete media info log for both a working and a not-working file?

[GG-Xtreme]

The log on the working file doesn't show the keyint.
Can you put up a complete media info log for both a working and a not-working file?

How do I obtain that? I Google 'find keyframe interval of file', but I didn't get much help. It doesn't seem like MeGUI has created any other logs besides what I posted, so I'm probably not aware of the method to get the log.

[sneaker_ger]

If you're using MPC-HC, just open a file, click File->Properties->MediaInfo.
Otherwise you get get it here (http://mediainfo.sourceforge.net/en/Download).

[GG-Xtreme]

If you're using MPC-HC, just open a file, click File->Properties->MediaInfo.
Otherwise you get get it here (http://mediainfo.sourceforge.net/en/Download).

Sorry to overcomplicate things, but since I usually delete my encodes after watching them, I had a hard time finding a working video that I encoded recently, so settings may have been different in MeGUI. However, I also got the mediaInfo logs of the source videos I was using, as well as a log from a file that will only seek the first 2/3rds of the file (although the entire file will play fine if I don't seek).

[sneaker_ger]

Just put the text in [code] tags, attachment approval takes forever.

[GG-Xtreme]

Just put the text in [code] tags, attachment approval takes forever.

Oh, didn't even notice that...fail >_<

(Skip to the bottom of the post for my preliminary conclusion)

A working file:
General
Unique ID : 249313175826901316123259450232779160547 (0xBB8FF8990FB4EC348BFDB6F4E13DBBE3)
Complete name : G:\Video\working1.mkv
Format : Matroska
File size : 90.3 MiB
Duration : 23mn 41s
Overall bit rate : 533 Kbps
Encoded date : UTC 2011-01-10 13:27:31
Writing application : mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48
Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 41s
Width : 720 pixels
Height : 406 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 98 r1649 20cbe10
Encoding settings : cabac=1 / ref=3 / deblock=1:1:1 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=21.5 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 23mn 41s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Language : Japanese

Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : English


A broken file:
General
Unique ID : 242693633988069634236511583745911236367 (0xB69517FCC98BBCA2A72E8AE28557270F)
Complete name : G:\Video\broken3.mkv
Format : Matroska
File size : 160 MiB
Duration : 24mn 0s
Overall bit rate : 932 Kbps
Encoded date : UTC 2011-05-07 02:15:10
Writing application : mkvmerge v4.7.0 ('Just Like You Imagined') built on Apr 21 2011 01:13:14
Writing library : libebml v1.2.0 + libmatroska v1.1.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 10 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 0s
Width : 800 pixels
Height : 450 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 114 r1913 5fd3dce
Encoding settings : cabac=1 / ref=10 / deblock=1:1:1 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60
Language : English

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 24mn 0s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Language : Japanese


tl;dr It's more complicated than that since I have a few working files at different encoding resolutions/qualities and one partially working file.

So I wrote a Python script to compare the "Encoding settings" line of 8 mediaInfo log files, and what I found was this:

threads=12 ... qpmin=0 / qpmax=69

Those two settings were the only ones that were consistent in all broken files and did not occur in any working files. It's not much to go on, but hopefully it's a clue.


Edit: After searching around, I found this mostly unrelated thread: http://shark007.net/forum/Thread-some-MKVs-play-some-don-t
Someone having MKV playback issues on an Xbox 360 can't play an MKV that contains the same settings as my broken files, but has no problems with MKV's that have different qpmin/qpmax values.

Edit: Another device that has issues with those qpmin and qpmax values: http://www.acryan.com/forums/viewtopic.php?f=108&t=12431

[sneaker_ger]

And you really tested the first file?

If you want to get rid of the "header stripping" (that's actually the reason why I wanted to see the complete log), go into mkvmerge GUI's options, tick "Disable header removal compression for audio and video tracks by default", restart mkvmerge GUI and then remux a not-working file.

[GG-Xtreme]

And you really tested the first file?

If you want to get rid of the "header stripping" (that's actually the reason why I wanted to see the complete log), go into mkvmerge GUI's options, tick "Disable header removal compression for audio and video tracks by default", restart mkvmerge GUI and then remux a not-working file.

Yes, the first file is definitely working. I will try your suggestion though. Once again, thanks for the help.

If that doesn't work, is there a way to ensure different qpmin and qpmax values so that I can test my theory?

[sneaker_ger]

Ok, if the first file is working then it's probably not the issue, as it also uses header stripping.

qpmax 69 is actually the same as qpmax 51, it's just some internal value for x264 IIRC. So the only other differences are number of ref frames (10 vs. 3), qpmin (10 vs. 0 - but I doubt it's the problem), level flag (3.0 vs 3.1 - I doubt it's the problem), bframes (3 vs. 5) and the resolution.

Can you try to encode to 720x406 with 3 ref frames, 3 bframes and level 3.0 flag for testing purposes?

[GG-Xtreme]

Alright, that setting didn't fix the issue. I do think though that somehow those qpmin and qpmax values are outside of some hardware limitation of my phone, since the files seek in software mode and on my computer.

Edit:

Ok, if the first file is working then it's probably not the issue, as it also uses header stripping.

qpmax 69 is actually the same as qpmax 51, it's just some internal value for x264 IIRC. So the only other differences are number of ref frames (10 vs. 3), qpmin (10 vs. 0 - but I doubt it's the problem), level flag (3.0 vs 3.1 - I doubt it's the problem), bframes (3 vs. 5) and the resolution.

Can you try to encode to 720x406 with 3 ref frames, 3 bframes and level 3.0 flag for testing purposes?
I have other working files that have the same number of ref frames and bframes (and resolution of course) as the broken. qpmin and qpmax values are the only things I've never seen in a working file.

[sneaker_ger]

I'd really be surprised if qpmin turns out to be the culprit, but I guess it won't hurt testing at this point. Also try lowering --keyint to 25 while you're at it, this can greatly improve seeking.

[sneaker_ger]

If that doesn't work, is there a way to ensure different qpmin and qpmax values so that I can test my theory?

Totally overlooked that. --qpmin 10 and --qpmax 51 are the options - who would've thought?

[GG-Xtreme]

Totally overlooked that. --qpmin 10 and --qpmax 51 are the options - who would've thought?

asdfjkasdfasdf; So enforcing qpmin=10 and qpmax=51 didn't change anything. I even tried a slightly lower encoding quality. Going to try another computer now...

[sneaker_ger]

Some very weird problem you got there... doesn't make any sense at all to me.
Did you try --keyint 25? Also the bitrate of the working file is way higher than that the reenconded one - maybe we should try increasing crf and set vbv-maxrate/vbv-bufsize.

[GG-Xtreme]

Some very weird problem you got there... doesn't make any sense at all to me.
Did you try --keyint 25?

Did you mean --keyint 250? mediainfo already shows that for all of my files, should I add the parameter anyway?

And yea, it's weird, but I just noticed something else (at least for my latest test): when the video frame freezes, if I leave it for a good 30 seconds, I'll get an error on my phone about the file being an unsupported format. If I clear the error...the video frame unfreezes and the file resumes playing normally from where I was trying to seek to. But it's hard to think this is an issue with my phone when my phone's memory is loaded with MKV's that seek without issue.

[sneaker_ger]

I really mean 25.

Is there any support forum for the player where you could ask a dev to take a look at the problem?
Also, try a different revision of x264. For startes get the newest from http://x264.nl

[GG-Xtreme]

I really mean 25.

Is there any support forum for the player where you could ask a dev to take a look at the problem?
Also, try a different revision of x264. For startes get the newest from http://x264.nl

Oh. Then I guess it can't hurt to try that. This issue happens with every video player on my phone, as long as hardware acceleration is enabled. I tried 2 different revisions of x264 in my testing (including the one used to encode all my working source files), but I haven't tried the latest yet.

[sneaker_ger]

(including the one used to encode all my working source files)

Yikes.
I'm starting to think it's really just an issue of the phone. But I guess reinstalling would mean quite a lot of work, huh?

[GG-Xtreme]

Yikes.
I'm starting to think it's really just an issue of the phone. But I guess reinstalling would mean quite a lot of work, huh?

But those source files have no seek issues on my phone. Also, I no problem reflashing my phone. Actually, I'm probably going to do that now to keep up with kernel commits on github.

What makes this issue interesting is that I've never downloaded or received an MKV that didn't seek properly on my phone, only files that I encode exhibit this problem...but I can't figure out what I'm doing wrong >_<

Edit: Update: I tried --keyint 25 and using the latest build of x264, and I tried completely wiping and reflashing my phone's ROM and kernel, but nothing has changed. Time to give Handbrake a try.

Edit: And...no luck with Handbrake. I...give up? Seriously, this doesn't even make sense. It's like my phone is restricted to only seek the first 50 videos I've ever encoded, but never again. I need someone else to start encoding these for me, since it's apparently out of my realm =/

[GG-Xtreme]

*Bump*

I've solved my issue. Well, more of a workaround than a solution. I can get ALL of my MKV's to seek if I first resample the audio to 44.1KHz. The fact that this works suggests a problem with my phone, but is still illogical, since I have plenty of working MKV's on my phone that I encoded using 48KHz sample rates (and all of my source videos that seek fine use 48KHz). Re-encoding the audio myself without downsampling to 44.1KHz does NOT resolve my issue. I understand that I probably won't get much input at this point, but thanks anyway to sneaker_ger for helping me narrow down the problem.

I guess this is now an AAC encoding issue instead of an H.264 one? Although the issue only affects MY MKV and MP4 containers, not the source ones...

[sneaker_ger]

Good thing you could rule out the video.
Which AAC encoder are you using? Both NeroAacEnc and the one from Apple are supposedly decent, so try to switch to one of them. HandBrake uses FAAC.

[GG-Xtreme]

Good thing you could rule out the video.
Which AAC encoder are you using? Both NeroAacEnc and the one from Apple are supposedly decent, so try to switch to one of them. HandBrake uses FAAC.

I always use NeroAacEnc. This might be a stretch, but now I suspect that there is a *chance* that all the people encoding my recent source videos are encoding the audio in someway that the sample rate is choking my phone (since the sample rate just carries over when re-encoding, unless I manually resample).

^^^This is supported by the fact that if I resample the audio from '48KHz' to 48KHz using foobar2000 and remux it, it seeks FINE on my phone. What a confusing and unlikely scenario :rolleyes: But then again...why does the problematic audio not prevent the source file from seeking?! It's like the remuxing is breaking something.

[GG-Xtreme]

Instead of starting another thread, does anyone know of an MKV remuxing tool besides mkvmerge/mkvtoolnix?

[ckmox]

Instead of starting another thread, does anyone know of an MKV remuxing tool besides mkvmerge/mkvtoolnix?

ffmpeg?