H.264 MKV Seek Issues (Again)

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

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

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]

Originally Posted by GG-Xtreme

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]

Originally Posted by sneaker_ger

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]

Originally Posted by sneaker_ger

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]

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

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]

Originally Posted by GG-Xtreme

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

Originally Posted by sneaker_ger

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]

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

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

Originally Posted by GG-Xtreme

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

ffmpeg?