Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wer]

I hope someone can point me in the right direction here...

I have a bunch of subtitled (external SRT) movies in my library.  JRiver subtitles most of them fine.

On ONE of them, MC does not synchronize the subtitles properly.  I have had to edit the STR with SubEdit to make all the subtitles appear earlier by 1.2 seconds.  That's a lot of correction.

The funny thing is, ALL other programs (VLC, MPC-HC, Quicktime) play that movie's subtitles perfectly in sync.  Only JRiver requires the -1200ms correction.  This is true across MC16 and MC17, RO-Std and RO-HQ, and across two different PCs.  Universally, all other programs agree, and MC is 1.2 seconds off.

I'm anticipating this happening with additional movies as I add them.  It's kind of a problem because since the SRT has to be named properly for all these programs to automatically pick it up, I can't easily have a separate version of the subs for JRiver.  When JRiver has working subs, all other programs are out of sync.

Clearly it's something about this file (MPG) that MC is barfing on, but anyone have any ideas?  I would be glad to send JRiver the file to look at, but it's 4GB+.

Thanks...

[wer]

I've done a little more investigating here.

It is not a problem with subtitles, per se.  JRiver plays the subtitles at the exact time specified in the subtitle file.

The problem is actually with the Audio-Video playback timing in JRiver.

The JRiver clock seems to just "start late" with this video file.  All audio/video is synchronized, but all sounds and images come out 1.2s EARLY on the clock compared to all other programs.

For example, the MGM Lion roars at ~2s into the video on with MC, but ~3s in (1.2s later than JRiver) in all other programs.  A character first speaks at 2:14.8 in all other programs, but at 2:13.6 in JRMV.

Since the subtitles have times specified in the file, and since MC seems to display subtitles to match the on-screen clock, this makes the subtitles out of sync with the audio/video.  In order to get the subtitles to display appropriately, they must be move forward in time 1.2s to match the audio/video, which is running ahead of the clock, compared to other movies.

I tried transcoding the movie to another format, and JRiver still behaves the same way.  What could be making it do this?

[wer]

I've found other movies where MC exhibits the same problem, so it's not just one file.  In the cases I've found where there's a discrepancy, MC is always about 1 full second early with the audio/video compared to other programs.

These aren't weird files out of nowhere.  I follow the same workflow as always:  Rip with DVD Decrypter to single VOB, then run through MPEG-Streamclip to fix any timecode breaks (which cause MC to choke).  That's it.  Perfectly normal MPEGs extracted from the DVD; they play in everything.

Could someone from JRiver please lend a hand here?  I'd appreciate it.

[Matt]

What's your audio buffering set to in Options > Audio > Output mode settings...?

Is it all videos, or only certain videos?

If it's certain videos, could you provide a sample?

Thanks.

[wer]

Well of course only subtitled videos are candidates.

It does not happen to ALL subtitled videos, only some.  The Star Wars movies for example, which have some alien subtitles, do not have a problem.

Audio buffering is set to 0.2s

I will upload a sample file, and will PM the location to you.  If there's someplace specific you'd like me to send it let me know.

Thanks!

[Matt]

Thanks for the file.  That's the biggest upload anyone has ever sent me.

As for the issue, I can certainly reproduce it.  And like you say, the subtitles are showing right when the SRT says, it's just that the reported position is off by a couple seconds.

I'm paging nevcairiel (author of LAV Splitter) to see if he has any ideas.

[wer]

Thanks Matt, you're awesome!

I am hoping this can be fixed in MC16, since I'm prevented from going to MC17 because of other issues.  (like slo-mo when jumping)

Sorry for the file size... If you can recommend a free & easy way to clip MPEG2+AC3 without transcoding or breaking it, I will keep that in mind if I ever have to send you another file. 

[Matt]

Here's what nevcairiel, the author of LAV, and the authority on things like this, had to say:

I'm not sure its a bug.
I tried playing the file with some other DirectShow splitters (i
seeked to 2:00 and let it play from there)

- MPC-HC MPEG Splitter matches LAV perfectly.
- MS MPEG Splitter causes the subtitles to be way too late, no matter
which of the two versions i use.
- Haali didn't want to open the file

So the only conclusion i can draw from this, matching MPC-HCs
splitters behaviour is the most sensible solution for me.
MPC-HC is quite the common player among the subtitle scene, and alot
of DirectShow players use their filters as well.

I imagine its caused by some simple concept in the code which ensures
that all mpeg files start with the timestamp zero.
Its actually quite common for mpeg files to start with some random
timestamps, doesn't have to be close to zero at all, and ffmpeg
exports the start time of the file to me, and i decrement all
timestamps by that value.

I would not feel comfortable to actually change this, because it may
cause quite a severe delay when starting playback of some files.
Designing subtitles against mpeg files is always risky, but i don't
think there is a universal solution here. I prefer having the same
behaviour as the MPC-HC filters instead of VLC, because that matches
the largest part of the DirectShow world.
It'll most likely also match everyone thats using ffmpeg for demuxing
(which VLC does not), like XBMC and MPlayer.

[wer]

Well, I'm not sure what to make of this.

MPC-HC's behavior is not the benchmark he seems to imply.  On my system, MPC-HC x64 v1.5.2.3456 varies significantly from MC, regardless of whether I have MPC's internal filters enabled or disabled.  So the behavior of LAV and MPC-HC do not match, at least not on all systems.

I have not installed any "filter packs" on my system.

I'm just referring to the out of box experience.  Perhaps if I sought out and installed the right combination of filters and splitters, as nevcairel may have, I could get MC/VLC/MPC/AirVideo/Handbrake/ffmpeg to all agree.  But out of the box, MC doesn't agree with the others.

Is there some specific setting in MPC that will make it agree with MC?  Then at least I could witness that... It wouldn't really solve much for me though since AirVideo, my streamer, still agrees with the others.

[Hendrik]

I just tried again.
Activated MPC-HCs internal MPEG TS/PS/PVA splitter, and played the sample Matt gave me (a 200MB cut of the start of the file)

If i use the .srt file with the subtitles 1.2 seconds earlier, it perfectly matches the Audio.
If i switch to LAV, the exact same timing.

I also checked MPC-HCs code, and i'm certain it does the same thing as LAV (making sure that timestamps start at 0, and not some random higher value).
Its possible that MPC-HCs behaviour changed in the versions since 3456 (i use 3965), but i doubt it.

Not doing this feels just wrong for me, sorry, not going to change.
I'm sure there would also be people out there that rely on MPC-HCs/LAVs behaviour, and changing it would cause them to come out of the woodwork kicking and screaming.

Its also certainly possible that most people just don't use MPEG-PS for storage (and external subtitles), just because of its inherently unpredictable behaviour, which is why such an issue never came up before.
However, without any data to suggest that, i'll just stick to how it works now.

Also, i don't care if VLC agrees, i know that MC and MPC-HC agree, as well as XBMC and most other ffmpeg based players/converters, thats enough for me.

Edit:
I actually downloaded MPC-HC 3456 and it still matches the audio perfectly.

[wer]

I actually downloaded MPC-HC 3456 and it still matches the audio perfectly.

I wish this were true for me, but it's not.  Nothing I do gets MPC-HC to agree.

Again, I wish it were only about VLC, but it's not.  I don't care if VLC agrees either, as I don't particularly have to use that player.  But other software, such as my streamer, or converter programs, I do have to use.

Not a comment on your code, but it's this sort of thing with codecs/splitters/etc that makes video on the PC such a nightmare.  Red October was to offer a solution that "just worked" and it usually does, but unfortunately not always.

I would be willing to encapsulate the video in MKV (no transcoding; don't want to lose quality) but I can't seem to find a converting & playback workflow/solution that works reliably and produces reliable files.

If one of you or someone else could suggest an alternative I'd be glad to try it.

Thanks at least for looking at the problem...