Media Player Classic supports Matroska v2, *.mp4, *.mov, and MPEG-4 Timed Text

[Liisachan]

As a nit-picky test (?) I made a weird MP4 file by muxing AVC and MPEG-1 Layer 1.
The resulted file plays fine both in MPC and via Haali's filter.
I'm going to test some more weird MP4 files later

(BTW, "inaccurate frame-timing for softsubs" I mentioned is not nit-picky like above; it's a real critical, dead-or-alive problem, as any decent timers/typesetters put a great effort to make SSA/ASS frame-accurate, to avoid for instance a sub that overruns by 1 frame beyond the scene change.)

Originally Posted by Egh

And what "border" fix are you talking about?

I don't really know. CCCP people say "The official VSFilter 2.36 from Gabest contains a small border and shadow drawing bug for SRT/SSA subtitles. This build has been compiled from Gabest's source with the fix for that bug, and is otherwise identical." and Matroska people say "VSFilter v2.36 + border fix 2005-03-20 Normal and Unicode version." That's all I know. Sorry for being off-topic, Elias.

BTW, iirc the anamorphic works on MPC/VM9 Renderless, if you tick "Use Overlay" in ffdshow.

[Elias]

Originally Posted by Liisachan

As a nit-picky test (?) I made a weird MP4 file by muxing AVC and MPEG-1 Layer 1.
The resulted file plays fine both in MPC and via Haali's filter.
I'm going to test some more weird MP4 files later

(BTW, "inaccurate frame-timing for softsubs" I mentioned is not nit-picky like above; it's a real critical, dead-or-alive problem, as any decent timers/typesetters put a great effort to make SSA/ASS frame-accurate, to avoid for instance a sub that overruns by 1 frame beyond the scene change.)

I don't really know. CCCP people say "The official VSFilter 2.36 from Gabest contains a small border and shadow drawing bug for SRT/SSA subtitles. This build has been compiled from Gabest's source with the fix for that bug, and is otherwise identical." and Matroska people say "VSFilter v2.36 + border fix 2005-03-20 Normal and Unicode version." That's all I know. Sorry for being off-topic, Elias.

BTW, iirc the anamorphic works on MPC/VM9 Renderless, if you tick "Use Overlay" in ffdshow.

No it's okay, you're talking about MPC, which isn't off topic Please do more weird mp4 files and test them. Gabest needs to know how it works with all kinds mp4 files. That critical thing you mentioned, is it something that can be fixed by providig Gabest a sample? What is softsubs? By the way, Gabest is reading this thread, so make sure you explain all the issues in a very detailed way.

Another thing I need some feedback on: the latest MPC that's up on Rapidshare, do you consider it in any way stable, or does it seem like Beta software (crashes etc)?

[Liisachan]

Originally Posted by Elias

That critical thing you mentioned, is it something that can be fixed by providig Gabest a sample? What is softsubs? By the way, Gabest is reading this thread, so make sure you explain all the issues in a very detailed way.

Gabest kindly answered here:
https://sourceforge.net/tracker/?fun...group_id=82303
and I've realized that this is not that easy. I was especially shocked to find that the current time stamp reported by DirectShow system is not deterministic. First time you play the file, DS may say "the frame 1 begins at 00:00.092" then second time you play the same file it may say "frame #1 is at 00.093", then "00.105" third time etc etc. Crazy, as Gabest said. How could the time stamp of the same frame of the same file change every time you play it?

The frame #1 (0-based) at 10 fps is supposed to begin at 00:00.10 of course, so if you wanted to start your subtitle at #1 you'd write "Start at 00:00.10" in your subtitle script, but MPC generally can't start the sub on the frame 1 because crazy DirectShow tells it "Hey, dude, the current time is 00.092" when it renders the frame 1 and MPC thinks "Ok, this subtitile is supposed to start at 00.100, so I have to wait more if it's 00.092 now"--the result is, subtitle is out-of-synch. When you specified "This sub should be on frames #1-10" MPC would probably display it on frames #2-11.

If the error was always -1 frame, some kind of simple hack for boked DS might work, but the error can be both +/- and the error changes each time you play the same file.

"Softsub" is a switchable, separated, subtitle stream. "Hardsub"--subtitles burnt permanently in video frames--is frame-accurate by definition (as it's a part of pictures in video frames), but softsub can be out-of-synch against the video frames, just like an audio stream could. Needless to say, no one wants to see any streams being out-of-synch.

This is what Gabest himself wrote in dsm.txt:

The algorithm of SyncPoints generation
--------------------------------------

First example:

stream 1: 1,5,8 (video)
stream 2: 2,3,6,7,9 (audio)
stream 3: 4 (subtitle)

1 ----|               1->2   1      +2        -> 1 (t 1, fp 1)
      |---- 2         2->3   1,2    +3 -2     -> 1 
      |---- 3         3->4   1,3    +4        -> 1
    +-|-- 4 (start)   4->5   1,3,4  +5 -1     -> 1
5 --|-|               5->6   3,4,5  +6 -3     -> 3 (t 5, fp 3)
    | |---- 6         6->7   4,5,6  +7 -6     -> 4 (t 6, fp 4)
    | |---- 7         7->8   4,5,7  +8 -7 -4  -> 4
    +-|-- 4 (stop)    
      |---- 8         8->9   5,8    +9 -5     -> 5 (t 8, fp 5)
9 ----|               9->10  8,9   +10 -8     -> 8 (t 9, fp 8)
      |---- 10        10->   9,10             -> 9 (t 10, fp 9)

In this example, subtitle should be on 5 and not on 9. But actually that sub would be on 9 and not on 5 (or on 1 and not on5) unless you are just lucky. I confimed that by converting Hard_vs_Softsubs.mkv into .dsm. The problem is not in containers, but in DirectShow itself.

Originally Posted by Elias

Another thing I need some feedback on: the latest MPC that's up on Rapidshare, do you consider it in any way stable, or does it seem like Beta software (crashes etc)?

It's working flawlessly for me. I once experienced abnormally high CPU load when playing (XviD+2 Vorbis+SRT).mkv, which I've never experienced with the previous version, but I can't reproduce the problem. It happened only once. I monitored CPU load closely in different conditions, but nothing wrong was found. In some cases, the new beta seems to be slightly less CPU-intensive than celtic_druid's mplayerc2005.08.13.2kxp_27.7z (maybe just accidental), but mostly about the same than the previous versions.

[Liisachan]

Apparently MPC reports MP1/2 audio in .mp4 as mp3 (WAVE_FORMAT_MPEGLAYER3) to the downstream filter (ffdshow).
Although, it is quite possible that .mp4 files themselves are weird (they are made by VLC media player 0.8.4-test1a.)

This problem doesn't occur for MP2 in mkv.

More discussion including milan_cutka's comment and sample files:
https://sourceforge.net/tracker/inde...61&atid=471489

Something isn't right for MP1 in mkv either. Even if MPC's internal MatroskaSplitter is enabled, Haali's splitter is loaded for mp1.mkv. I believe this one is MPC's problem.

Small Sample files (meaningless 10-second tone):
mpeg1-layer1.mkv
mpeg1-layer2.mkv

[Egh]

So I guess that "border" bugfix is what been implemented in celtic's build of MPC. Since there's a difference of 1px in parameters there (i.e. to achieve similar effect i had to increase border by 1px compared to March build by gabest)

[Drachir]

Originally Posted by Liisachan

Apparently MPC reports MP1/2 audio in .mp4 as mp3 (WAVE_FORMAT_MPEGLAYER3) to the downstream filter (ffdshow).
Although, it is quite possible that .mp4 files themselves are weird (they are made by VLC media player 0.8.4-test1a.)

What ObjectTypeIndication is used for the Audio Track?

MP4Box -info file_created_with_VLC-0.8.4-test1a.mp4

http://www.itscj.ipsj.or.jp/sc29/ope...w/29n5556t.doc

[Elias]

Originally Posted by Liisachan

Apparently MPC reports MP1/2 audio in .mp4 as mp3 (WAVE_FORMAT_MPEGLAYER3) to the downstream filter (ffdshow).
Although, it is quite possible that .mp4 files themselves are weird (they are made by VLC media player 0.8.4-test1a.)

This problem doesn't occur for MP2 in mkv.

More discussion including milan_cutka's comment and sample files:
https://sourceforge.net/tracker/inde...61&atid=471489

Something isn't right for MP1 in mkv either. Even if MPC's internal MatroskaSplitter is enabled, Haali's splitter is loaded for mp1.mkv. I believe this one is MPC's problem.

Small Sample files (meaningless 10-second tone):
mpeg1-layer1.mkv
mpeg1-layer2.mkv

I wouldn't recommend using VLC for mp4 creation (nothing bad about the player). Use MP4Box since it's the best thing for creating mp4 files.

[bond]

currently all mp4 muxers signal mp1, mp2 and mp3 audio the same way as "mpeg-1 audio", which is compliant to the mpeg-4 specs

the point why this is done that way is that the mpeg-1 specs require every mpeg-1 audio decoder supporting a specific layer to handle all lower layers too, eg a mp3 decoder has to support mp2 and mp1 too, at least thats what i think bill may or jeanlf told me once



btw if people want mp4 files of all imagineable sorts you can get my collection here

[Liisachan]

Originally Posted by Egh

So I guess that "border" bugfix is what been implemented in celtic's build of MPC. Since there's a difference of 1px in parameters there (i.e. to achieve similar effect i had to increase border by 1px compared to March build by gabest)

Maybe... Like I said, a full explanation was not given anywhere. If you're really interested, how about installing CCCP or Matroska Pack yourself? Personally I wouldn't like to install them for several reasons, like I'd like to keep testing the newest ffdshow etc while MatroskaPack would install older ffdshow.

Originally Posted by Elias

I wouldn't recommend using VLC for mp4 creation (nothing bad about the player). Use MP4Box since it's the best thing for creating mp4 files.

I never use VLC to create .mp4 files for practical purposes, I wouldn't use MP1/2 to begin with (who would actually use MPEG-1 layer 1 today? ) You are the one who asked us to test even borked .mp4 files, and that's the only reason I did weird things using weird ways on purpose. I am actually mirroring the newest mp4box builds by celtic_druid.

Seriously tho, mkvmerge correctly transmuxes those mp1 / 2 / 3 in MP4 into A_MPEG/L1, L2, L3 respectively, so there should be a 'right' quick way to distinguish MPEG Layer in MP4, but on the other hand it is obvious that almost no one would use MP1/2 in MP4 anyway.

[Elias]

Originally Posted by Liisachan

I never use VLC to create .mp4 files for practical purposes, I wouldn't use MP1/2 to begin with (who would actually use MPEG-1 layer 1 today? ) You are the one who asked us to test even borked .mp4 files, and that's the only reason I did weird things using weird ways on purpose. I am actually mirroring the newest mp4box builds by celtic_druid.

Well, I meant more in general, you should use MP4Box it's good that you're trying different mp4 converters now How does that mp4 file play in MPC if created with mp1/2 using MP4Box/mp4UI?

[Liisachan]

Originally Posted by Elias

How does that mp4 file play in MPC if created with mp1/2 using MP4Box/mp4UI?

Basically the same. If its internal Mpeg Audio decoder is disabled, MPC can call ffdshow. ffdshow then correctly recognizes mp1 as mp1, mp2 as mp2, if you see "info & debug," but ffdshow uses the decoder you set for mp3 nevertheless.
Example:
(1) in ffdshow, set the decoder for MP1/2=libmad, set the decoder for MP3=mp3lib
(2) Play mp4box-mp2.mp4
(3) libmad should be used, but mp3lib is used.

mp4box-mp2.mp4 (audio only)
mp4box-mp1.mp4 (audio only)
xvid+mp2.mp4

PS. Gabest officially confirmed that MPC's subs can't be as accurate as VSFilter's. Really sad. I was deeply shocked.
https://sourceforge.net/tracker/?fun...group_id=82303

[Haali]

Originally Posted by Liisachan

Gabest kindly answered here:
https://sourceforge.net/tracker/?fun...group_id=82303
and I've realized that this is not that easy. I was especially shocked to find that the current time stamp reported by DirectShow system is not deterministic. First time you play the file, DS may say "the frame 1 begins at 00:00.092" then second time you play the same file it may say "frame #1 is at 00.093", then "00.105" third time etc etc. Crazy, as Gabest said. How could the time stamp of the same frame of the same file change every time you play it?

The frame #1 (0-based) at 10 fps is supposed to begin at 00:00.10 of course, so if you wanted to start your subtitle at #1 you'd write "Start at 00:00.10" in your subtitle script, but MPC generally can't start the sub on the frame 1 because crazy DirectShow tells it "Hey, dude, the current time is 00.092" when it renders the frame 1 and MPC thinks "Ok, this subtitile is supposed to start at 00.100, so I have to wait more if it's 00.092 now"--the result is, subtitle is out-of-synch. When you specified "This sub should be on frames #1-10" MPC would probably display it on frames #2-11.

This is not entirely correct, and the bug report has an explanation. MPC's internal subtitler is not a DShow filter, instead it plugs inside VMR9, and that's where the problem is. VMR does syncronization for display internally, and may adjust timestamps slightly. VSFilter on the other hand is a standalone DS filter and modifies actual video frames before they are passed to VMR.

[Liisachan]

Thanks for you comment, Haali

I did read Gabest's second comment too. In his first comment, he said "The problem is dshow does not return the exact stream position" and so I thought vaguely that this was a problem of DiectShow. Naturally I thought "If DS is bad, then why is VSFilter ok?" at the same time, and asked about that. Then Gabest did more explanation in his 2nd comment. That post of mine here in doom9's forum was posted between his 1st and 2nd comments. I guess he used the plain word ("DirectShow") first so I would understand, and then explained a bit more ("VMR" "Plugin") as I asked the difference between MPC and VSFilter.

In my quick testing, the timing error in the 'value' can be both + and -.
However, in my actual experiences, the error is always negative (in other words, subs Start/End in MPC's renderer is always 1 frame too late, if the timing is not correct at all). I've been trying to figure out why the error is always negative in my real experiences, and here's what I'm guessing:

Example @23.976fps
Frame #50 = 02.085
Frame #51 = 02.127

In this case, the SSA Start Time for the sub that starts at #51 can be: 02.09 / 02.10 / 02.11 / 02.12. 4 different time stamps in SSA would mean the same thing. Why? Because the timing resolution of the video frame is 42ms while the resolution of the SSA time stamp is 10ms, hence 4 different time stamps in SSA meaning one same video frame.

I usually use the "max possible time stamp"--in the above example, I would always use "02.12" in SSA, altho 02.09 .10 or .11 could mean the same thing too. That's just my style. So, the "logical time stamp" of the target video frame is 02.127, and the timing I use in my SSA would be 02.12. The difference is only -0.007.

Therefore, in my style, if the error:
(reported time stamp) - (logical time stamp)
is < -0.007, MPC's sub will be one-frame too late. On the other hand, the error should be a big positive number in order for the frame-timing to be too early (only when #50 = 02.085 is reported as 02.12+, i.e. when error > 0.035).
If I'm guessing right, in my style, MPC's subs are
(1) one frame too late when the error < -0.01 or so
(2) one frame too early when the error > +0.03 or so

(1) often happens, while (2) seldom (or never) happens.

Like I said, generally there are 4 different SSA time stamps to mean the same thing, if the video is like 24fps. Let's call the 1st one "minimum possible time stamp" the last one "maximum possile time stamp" and others "middle time stamps." If you always use the "max possible" then MPC's subs are likely to be one frame too late. If you always use the "min possible" then (if i'm guessing right) MPC's subs are likely to be one frame too early. And if you use middle time stamps, frame-timing errors will happen relatively rarely.

However, I cant change the fact that MPC's sub renderer is not frame-accurate.
So I think I'll stop using MPC's sub renderer after all.
The font-quality of subs from MPC is higher than ones from VSFilter, at least in 200% video size and in fullscreen. I really liked it. Personally I prefered VMR9 Renderless in MPC to VSFilter, until I realized that MPC's one is not frame-accurate. I guess it's time to switch to VSFilter. It's not like I say good-bye to Gabest, as I'll use MPC anyway and VSFilter is written by the same author too, but somehow I can't help but feeling very sad I guess partly I'm angry at those silly functions for VMR Plugins made by MS people....Why could it be so wierd? My amateur's guess is......
1. Maybe there is an uninitialized variable somewhere in its algo to report the time.
-or-
2. It's reporting the actual 'observed' as-is timing--not the logical 'should-be' timing.

The both could explain why the ret. value changes every time you play the same clip. There would be no comfort even if I knew the reason

EDIT
maybe I'm not guessing right. the above theory does not explain why every Start/End time is one-frame too late in Hard_vs_Softsubs files.

[Haali]

I think VMR9 syncs to vertical refresh of the video card, so the frame is delayed until the next refresh.

[Egh]

Originally Posted by Haali

I think VMR9 syncs to vertical refresh of the video card, so the frame is delayed until the next refresh.

iirc you can disable the VSYNC there? But as far as i know, it doesn't fix the problem.

[Haali]

No, it has some internal reclock-like logic afaik. In renderless mode your callback is responsible for actual drawing, but vmr9 still does its evil things.

[Egh]

Originally Posted by Haali

No, it has some internal reclock-like logic afaik. In renderless mode your callback is responsible for actual drawing, but vmr9 still does its evil things.

Orly? Well, if so, then all we need is THE HACK. For VMR9 I mean.

but just thinking... Is there any way to disable that kind of behavour in VMR itself? Some hidden registry keys or so...

[Elias]

Guys, I don't want to sound like a boring mod, but please stick to mp4 and the problems MPC may have with it

[Elias]

New MPC build in the first post, check it out

[Blight]

DAR/PAR (under VMR9) is controlled by the player's reaction to directshow events. There is also a flag in DirectX 9c's implementation of VMR9 which also controls some aspect ratio controls.

This may explain why ZP works better than MPC. BTW, if there is a file that doesn't work in ZP, I would like to know about it (post on the ZP forum, don't pollute this thread).

There is another bug in VobSub dealing with ARGB input (leading to a black screen as the filter basically assumed the entire image was transparent or something of that nature). I went over it with gabest months ago but no patch has been issued.