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

[Liisachan]

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 (http://ffdshow.faireal.net/mp4box-mp2.mp4) (audio only)
mp4box-mp1.mp4 (http://ffdshow.faireal.net/mp4box-mp1.mp4) (audio only)
xvid+mp2.mp4 (http://ffdshow.faireal.net/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/?func=detail&atid=565649&aid=1280326&group_id=82303

[Haali]

Gabest kindly answered here:
https://sourceforge.net/tracker/?func=detail&atid=565649&aid=1280326&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? :angry:

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]

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]

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.

[Egh]

Elias: you say we need to beta-test the build. OK, but where to report bugs and glitches?! :)

e.g. d2v "splitting" didn't work with my .d2v files in 20051025 build at all (dgdecode 1.46b1). How to inform gabest about that? :P

[Elias]

Elias: you say we need to beta-test the build. OK, but where to report bugs and glitches?! :)Do it in this thread, he reads it for bugreporting (I thought that was what we were doing?). Also, the bugtracker and forum on sf.net for MPC might be even better.

http://sourceforge.net/forum/?group_id=82303

http://sourceforge.net/tracker/?group_id=82303&atid=565649

[Elias]

Date News
10/30

Media Player Classic is going MP4: Gabest has resumed work on MPC and is currently adding MP4 support to the player, thus offering a "no additional filters and one executable without installation only" solution for MP4 playback.Just one thing, MPC cannot play mp4v/avc1 inside mp4 without ffdshow. However, if it's just AAC, it ought to work perfect, 'cause MPC has an internal AAC filter. Can somebody run some tests on this matter? I will do a couple of tests myself (been forgetting it all the time since I'm lazy uninstalling ffdshow). Also, try some MPEG-1/2 (VCD/SVCD) and mp1/mp2/mp3 inside mp4 etc, which MPC also should play fine. Of course, without any external filters like ffdshow.

[Egh]

Would be sensible idea to test MP4 splitting with Nero Decoder as well. I may test some high-profile avc in mp4 files produced by Nero Recode.

[Liisachan]

However, if it's just AAC, it ought to work perfect, 'cause MPC has an internal AAC filter. Can somebody run some tests on this matter? Did a quick test and these play:
(MPEG-2 AAC).mp4
(MPEG-4 AAC).mp4
(HE-AAC).mp4
(HE-AAC PS).mp4

[CruNcher]

Nice to see ya back Gabest :)

[Egh]

@Gabest:

one more bug seems to be in last build (wasn't in 1025). Seems that Half-size, Normal, Double-size options in context menu do not work.

[Elias]

All right boys and girls, Gabest is uploading the new stable release as we speak!

http://sourceforge.net/project/showfiles.php?group_id=82303&package_id=84358

[Elias]

Media Player Classic 6.4.8.5 is out. There's no changelog on sourceforge yet, but I suppose the new release has something to do with the MP4 capabilities.There won't be any changelog :( Gabest doesn't feel up to it for some reason. And he can't remember everything.

[21:42:46] Elias: will there be a changelog at all?
[21:43:18] Gabest: no one is willing to make one!
[21:43:33] Gabest: I asked myself and I said no..
[21:45:45] Elias: hahaBy the way, has anyone experienced any bugs with the latest stable release?

[Egh]

By the way, has anyone experienced any bugs with this latest stable release?

I still do :) With all last builds. But since couple of ppl I asked can't reproduce it, i don't know whenever it's my system which b0rked or what :)

In short if you have one file playing, and you drag&drop another one, it's possible to have two files mixed :) i.e. previous file simply isn't stopped and removed from memory, it still plays :P

I haven't fully tested though which options lead to such interesting result. ffdshow used as decoder, mode is VMR9 renderless.
Seems not dependand on internal mpc splitters (i.e. happens with haali as well). Seems also nondependend on container, happened both with mkv and avi.

But again, until others are able to reproduce it, I don't know if it's only particular system bug or what :P

[Elias]

I still do :) With all last builds. But since couple of ppl I asked can't reproduce it, i don't know whenever it's my system which b0rked or what :)

But again, until others are able to reproduce it, I don't know if it's only particular system bug or what :PKeep posting them here then, because Gabest is really hungry for updating MPC, even after the stable release :)

I couldn't reproduce it either.

[22:05:18] Elias: http://forum.doom9.org/showthread.php?p=730848#post730848
[22:07:13] Gabest: I bet he made ffdshow register the filter graph
[22:08:22] Elias: well... you're the man :)
[22:08:33] Elias: not that I have any clue what you're talking about
[22:09:37] Gabest: open the property page of ffdshow, there under Info & debug: Make DirectShow graph available to graphedit
[22:10:17] Gabest: if someone checks this then mpc and ffdshow both register the filter graph

[smok3]

just a question, will aac decoder handle 5.1 aac as well?

[guada 2]

Who knows, perhaps.
One knows that it plays the aacplusv2 Ps of winamp, but it is less skillful than VLC.

[B.F.]

I don't know about bugs but I had some questions.
1) Why internal subtitle render work so slow?
Vsfilter work many times faster than internal render and had almost the same results.
2) How about ass animation support like textsub? Opinional of course.

And about that "subtitle is out-of-synch" problem.
If it nothing Gabest can do about DirectShow time accuracy, than how about a subtitle time correction hack?

[Liisachan]

And about that "subtitle is out-of-synch" problem.
If it nothing Gabest can do about DirectShow time accuracy, than how about a subtitle time correction hack? First, Gabest fixed it!!!



Check the new release, the problem was fixed, by a nasty
but elegant hack :P

nasty but elegant! huhu, I'd say ASS is always messy and splendid...

Secondly, like I said, you could reduce the probability of occurrence of out-of-synch subs by not using the "max possible time stamps" without making any bad side effects. But hey, anyway its fixed fixed fixed Hooray :D
I don't know about bugs but I had some questions.
1) Why internal subtitle render work so slow?
Vsfilter work many times faster than internal render and had almost the same results. one thing I can say for sure is: Let's say your video is 640x480. If you use VSFilter, the resolution of your subs is 640x480 even in the full screen mode. If you use MPC and set the max. texture=desktop, then the resolution of your subs is equal to the desktop resolution. In this case, you are comparing a 640x480 clip to a 1280x1024 (or anything: your desktop size) clip, subtitle-wise. Naturally the second one is much higher-quality AND much more cpu-intensive.

Another thing is, softsubs from VS are always relative-to-video-frame, whereas softsubs in MPC can be both relative-to-video-frame & relative-to-physical-device. VSFilter cannot "touch" a point out of the video frame, since it is in the upstream and it doesn't know what's going on in the downstream. MPC's renderer, on the other hand, can draw things everywhere on your screen. It's co-operating with video renderer. (This can be its weak point too, as we saw in that problem) And practically, this is confusing for absolute positioning, because {\pos(0,0)} is not unique for MPC, which is a major problem indeed, but anyway purely technically, it is clear that MPC's sub renderer is (at least potentially) more powerful and more flexible. And powerful/advanced framework is usually more cpu-eating.

2) How about ass animation support like textsub? Opinional of course. Yeah.... Well, you'll have to disable subpic-buffering in MPC's settings anyway, which makes MPC's subs even more cpu-intensive. Actually much more.

[Elias]

If anyone is curious about what the d3dx9_27.dll is, just check my first post, I've updated it with Gabest's answer. Gabest has been receiving a lot of questions about this dll, so let's make life easier for him :)

[Liisachan]

Let me add one more thing. VSFilter can work in the HW Overlay mode, which is fastest and least cpu-consuming, thanks to HW accelerators. When using MPC's sub renderer, that is not possible (for one thing, you can always screencap in that case), so I'm guessing (some of) HW accelerators are forced to be disabled if you use VMR9 Renderless. This might be another reason VSFilter is faster.

[Liisachan]

(1) Play PS-AAC.mp4 or PS-AAC.aac
(2) hit >> then hit <<
(3) Problems:
(a) the speed is about 100% again, but unstable (like 105%+jumpy)
-and/or-
(b) the output is mono.

[Elias]

(1) Play PS-AAC.mp4 or PS-AAC.aac
(2) hit >> then hit <<
(3) Problems:
(a) the speed is about 100% again, but unstable (like 105%+jumpy)
-and/or-
(b) the output is mono.Well, HE-AAC has never worked good for me with Winamp or VLC (last I tried, been a while). Some say it's better quality. It might be, but I wouldn't use it for now. It sure has less compatibility than LC-AAC does right now. I'll encode some HE-AAC samples later and try it out. Thanks for notifying about it :)

[Liisachan]

MPC works fine for HE-AAC v1 (both winamp & nero).
The above-mentioned problem is only for PS-AAC aka aacPlus v2.
The same clip plays fine for me with libfaad2 in ffdshow.

[bugmenotwillyou]

Ok I have a bug report:
Using MPC 6.4.8.5 (and older versions) and disabling the inbuilt "MPEG PS/TS/PVA" source filter to try another TS filter such as HDTVPUmp http://www.dvbportal.de/projects/hdtvpump/ or TSFileSource http://nate.dynalias.net/TSFileSource/TSFileSource.html. When trying to play a TS it errors out with the generic "Cannot render the file" error.

[Liisachan]

AacPlus v2 problem exists in official 6484 and 6485, and does not exist in Celtic_Druid's 20050813, so maybe just updating libfaad would fix the problem.

However, some people (including Dave "Novalis" Turner from FSF) say that newer faad is GPL-incompatible.
http://www.hydrogenaudio.org/forums/index.php?showtopic=35535&view=findpost&p=314491

This is exactly what I don't really like about MPEG-4. European people might think MPEG-4 is a set of open standards and so automatically related open-souce software can exist, but that's not true, sadly, especially in the area where software patents are allowed, like in Japan and in US.
MPEG-4 itself is nice, I like it and use it often too, but the license can be tricky.

[stephanV]

Liisachan: the incompatibilities with the GPL are not related to software patents. Nero broke GPL compatibility by requiring a copyright attribution in the software itself, while the GPL allows to put such attributions externally from the software (e.g. in a readme file).

[Liisachan]

Ah, okay, well, actually, I knew that, and what I did wrong was, I wrote things that are not directly related here. (We do sometimes experience patent-related limitation about MPEG-4, but that would be unrelated here....)

Personally I wouldn't mind seeing that credit in the about box or somewhere (in CD version it is in a floating tooltip). But I guess that's not the problem.


PS.
Is there any possibility that Ahead will change that part? Or did they do that on purpose? At this rate open-source devs might end up in thinking "then we won't use v2, just use real's decoder" and I don't think that is what Ahead wants...

[bond]

Liisachan: the incompatibilities with the GPL are not related to software patents. Nero broke GPL compatibility by requiring a copyright attribution in the software itself, while the GPL allows to put such attributions externally from the software (e.g. in a readme file).nero tought claims that this is compliant to the gpl

[stephanV]

nero tought claims that this is compliant to the gpl
It isn't, because it is an additional restriction on top of the GPL. While everybody is free to modify the GPL license to their liking, a modified GPL is not the GPL.

[Wilbert]

I think jstembridge and Otto42 gave a good reason why it is not compatible with GPL, and nero acknowledged it, but didn't fix it.

I'm not sure what to make of the comments of Dave "Novalis" Turner (FSF engineer). He says it's a restriction, because it is not required by section 1 (that's only about the source code not about the program itself), and by section 2c (it isn't interactive ).

Ok, so it's not required (contrary to what nero claims), and thus a restriction. Restrictions are not allowed (see point 6 of the GPL).

So, there are two reasons why it is incompatible with the GPL.


A library isn't interactive right?

[Egh]

If anyone is curious about what the d3dx9_27.dll is, just check my first post, I've updated it with Gabest's answer. Gabest has been receiving a lot of questions about this dll, so let's make life easier for him :)

Of course celtics' build from august 13 was using that dll as well (at least one of variants).

[Elias]

Since I don't have Nero 7, I have to ask: how well does MPC decode the Nero 7 AAC, and the the Nero 7 mp4 containers?

[bond]

Since I don't have Nero 7, I have to ask: how well does MPC decode the Nero 7 AAC, and the the Nero 7 mp4 containers?the point of a standard, like mpeg-4, is that it doesnt matter what tool produced the stream (eg nero 6 or nero 7 or whatever) ;)

[Egh]

also FYI: if desktop is set let's say 1024*768, it doesn't mean that MPC renders it at same resolution.

IIRC, the reason why MPC subs rendering is slower is cause MPC uses supersampling, aka renders at higher that target resolution and then scales back to target one. So disabling buffer ahead makes things quite slow. And of course you need to do that in order to see karaoke :P

[Elias]

the point of a standard, like mpeg-4, is that it doesnt matter what tool produced the stream (eg nero 6 or nero 7 or whatever) ;)I know, we've been through this more than once :) I was more thinking that perhaps Nero had broken some part of the standard somehow (stephanV said that Nero, Apple and Sony have lots of incompatibilites with their mp4 containers, which is true, so that's why I asked).

[bond]

noone of these three breaks the standard with their mp4 files, except maybe apple by using own extensions

[movax]

Just a small side note, I think some of the sloppily written newer games are dumping the dynamic D3DX DLLs into system32, though IIRC, an application will go for the DLL in its current path first anyways. This new stuff is a royal pain in the ass...perhaps at least a static link option will appear with DirectX 10.

To elaborate on the games part, a lot of Civ4 problems were solved easily by installing the dx9 redist that came off the DVD, and of course, was _27.dll. But I also installed Shattered Union at the same time, and that installer happily dropped that file into my system32. I mentioned to Elias that hopefully apps will only love their version of the DLL, and not any others, for that method _seems_ sane, but when do companies and developers do sane things? :P

[stephanV]

the point of a standard, like mpeg-4, is that it doesnt matter what tool produced the stream (eg nero 6 or nero 7 or whatever) ;)
But when talking about SBR and PS, there is more to it than just being able to decode the stream. So the question seems valid to me.

[Elias]

I mentioned to Elias that hopefully apps will only love their version of the DLL, and not any others, for that method _seems_ sane, but when do companies and developers do sane things? :PWhat are you talking about? I can't remember any of that.noone of these three breaks the standard with their mp4 files, except maybe apple by using own extensionsSony has added some proprietary stuff in their PSP mp4 containers, no? Nero has non-standard subtitles and chapters in their mp4 files, isn't that so (although, their mp4 containers are okay as far as I know)? Apple, well, yeah, non-standard extensions, but least guilty imho.

[Elias]

Am I the only one who is experiencing skippy audio playback for AAC in mp4 (Nero Digital LC-AAC VBR, demuxed and reimported to mp4 with MP4Box) with MPC's internal AAC decoder? It's not as smooth as when played in Winamp... But it's working pretty good most of the time, just every now and then the audio playback is like jumping. This is mp4 AAC only, no video.

[B.F.]

one thing I can say for sure is: Let's say your video is 640x480. If you use VSFilter, the resolution of your subs is 640x480 even in the full screen mode. If you use MPC and set the max. texture=desktop, then the resolution of your subs is equal to the desktop resolution. In this case, you are comparing a 640x480 clip to a 1280x1024 (or anything: your desktop size) clip, subtitle-wise. Naturally the second one is much higher-quality AND much more cpu-intensive.

Another thing is, softsubs from VS are always relative-to-video-frame, whereas softsubs in MPC can be both relative-to-video-frame & relative-to-physical-device. VSFilter cannot "touch" a point out of the video frame, since it is in the upstream and it doesn't know what's going on in the downstream. MPC's renderer, on the other hand, can draw things everywhere on your screen. It's co-operating with video renderer. (This can be its weak point too, as we saw in that problem) And practically, this is confusing for absolute positioning, because {\pos(0,0)} is not unique for MPC, which is a major problem indeed, but anyway purely technically, it is clear that MPC's sub renderer is (at least potentially) more powerful and more flexible. And powerful/advanced framework is usually more cpu-eating.

Yeah.... Well, you'll have to disable subpic-buffering in MPC's settings anyway, which makes MPC's subs even more cpu-intensive. Actually much more.
I know.
But it doesn't come from resolution.
I can play 1280x720 video on 800x600 screen resolution on AthlonXP2200+ and about 2-3 frames per second.
If I play the same video using vsfilter I had the full 30 frames per second and 85% CPU load.
I don't think MPC internal subtitle renderer must eat more CPU power than both video and audio decoders together.

[Egh]

I know.
I don't think MPC internal subtitle renderer must eat more CPU power than both video and audio decoders together.

Check how much you allowed to use for subs in mpc first.
If you play it on 800*600, make sure you have only 800*600 enabled. Another thing is, as i said previously, that mpc actually might render at MUCH higher resolution than that. E.g. you allowed to use only 800*600, and the text itself is printed at let's say 1280*1024 resolution and then scaled down to 800*600 and displayed. That's why mpc internal subs are much better than vsfilter in terms of quality.

Also, please take a look at subs file. check which internal resolution is allowed there. (if it's an .ass file, check PlayResX/PlayResY keys). iirc VSFilter will render the subs in this particular resolution only. But mpc might use much more.

So simplistic solution would be to greatly lower allowed rezo for subs in mpc.

[bond]

But when talking about SBR and PS, there is more to it than just being able to decode the stream. So the question seems valid to me.its spec compliant to place a sbr aac stream in mp4 without signalling sbr (aka a he-aac decoder has to recognize sbr itself even without the parser telling it that its he-aac)
dunno if this is true for ps too, but i guess so

so the demuxer strictly speaking is not forced to care about he-aac

Sony has added some proprietary stuff in their PSP mp4 containers, no?and? this doesnt make the sony .mp4 files incompliant

whats incompliant is the psp player which requires the proprieatary stuff, but again this doesnt make the files themselves incompliant

Nero has non-standard subtitles and chapters in their mp4 files, isn't that so (although, their mp4 containers are okay as far as I know)?the mp4 standard allows you to place anything you want in the udta atom, which nero uses for storing chapters
also the mp4 standard allows the placement of private streams in mp4, which nero uses for vobsubs

so nero's mp4 files are not incompliant

Apple, well, yeah, non-standard extensions, but least guilty imho. from my point of view apple is the only one breaking the standard by using the .m4v and .m4a extensions for .mp4