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]

Originally Posted by 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?

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. 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]

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?

[sneaker_ger]

Originally Posted by GG-Xtreme

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.

Originally Posted by GG-Xtreme

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]

Originally Posted by sneaker_ger

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 . 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]

Originally Posted by 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).

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?

[sneaker_ger]

Not really.

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

[GG-Xtreme]

Originally Posted by sneaker_ger

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]

Originally Posted by 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?

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.

[GG-Xtreme]

Originally Posted by sneaker_ger

If you're using MPC-HC, just open a file, click File->Properties->MediaInfo.
Otherwise you get get it here.

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]

Originally Posted by sneaker_ger

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-som...lay-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/viewtop...?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]

Originally Posted by 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.

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?