Mp4 Corruption

[trythil]

So, my question is then, why on a mac is it a crap shoot as to wether an pc encoded mp4 will play in VLC?

Because it isn't, aside from the question of processing power.

I have a Mac (first-generation Macbook Pro). I have the latest version of VLC. I have yet to find a standards-compliant H.264 video stream that I cannot play back with VLC.

If the CPU isn't powerful to handle the video stream, or if the decoding software is not efficient enough, then things will probably stutter. This goes for any platform, though; it is not Mac-specific at all.


I wrote up some notes on generating encodes that Quicktime 7 can handle here:

http://www.animemusicvideos.org/phpBB/v ... t=qt7+x264

Note that the title is misleading; that was a mistake on my part. The incompatibility is not with x264, but with Apple's H.264 decoder: it does not support as large a subset of H.264 features as other decoders, such as the ffmpeg decoder (used in mplayer and VLC) and CoreAVC.

[JudgeHolden]

Link me the last mp4 you downloaded and played fine, so I can test it out. Processing power is not the issue, though you are on an intel processor as oppossed to a g5.

[JudgeHolden]

Ok, so here are some examples:

This one will play in VLC, but won't play in mplayer:



This video stalls in VLC, but will play in mplayer with no issues:



This one will play in everything (Including quicktime):



Now, why the difference? It can't be processing power, cuz then the first two wouldn't work in any player. Am I correct in thinking that? Now h264 became big on this site AFTER the new intel processors, so maybe there is a glitch between intel macs and G5/4 macs? I don't know, all I know is that if Rina's video plays in VLC, then to should requett's, that's if it is true that they used the same standard encode.... So, I'm confused.

[trythil]

Link me the last mp4 you downloaded and played fine, so I can test it out.

The last H.264 video stream I downloaded and successfully played was aerialesque's Azure. The encoding parameters on that video are as follows:

Code: Select all

x264 - core 54 svn-618 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=8 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=6 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=crf crf=20.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30

The last H.264 video stream I generated was my latest video, which I can confirm as playable with mplayer and VLC on multiple platforms. Encoding parameters were as follows:

Code: Select all

x264 - core 54 svn-650M - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=12 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=8 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=300 keyint_min=30 scenecut=40(pre) rc=2pass bitrate=1400 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30

The usage of the 8x8 DCT and B-frame pyramid appear to break it for Quicktime 7, unfortunately. I don't think it adds all that much to the quality/size ratio, though; if I get the time and the motivation, I'll see if I can generate an encode that QT7 can accept and see what I have to give up.

Ok, so here are some examples:

I'm grabbing these now and will get back to you with results once I've played through them.

Now, why the difference? It can't be processing power, cuz then the first two wouldn't work in any player. Am I correct in thinking that?

I was unclear in my last post -- stuff like processing power, available memory, memory speed, etc. do matter, but the efficiency of the decoder is also a big factor.

I don't know whether or not the PowerPC codebase of (say) the ffmpeg decoders have received as much optimization attention as the x86 codebase; to definitively answer that question, we'd have to look back at the ffmpeg commit logs. However, if the x86 port is more optimized for various x86 processors then the PowerPC port is more optimized for various PowerPC processors, then that could make a difference.

CoreAVC is a great example of how decoder efficiency can make a significant difference.

[trythil]

Okay, here's the results.

These are my playback tools, their versions, and whatever other diagnostic data they wanted to spit out. My copy of mplayer was compiled from the mplayer Subversion repository, whereas my copy of VLC was obtained from videolan.org.

Code: Select all

MPlayer dev-SVN-r23218-4.0.1 (C) 2000-2007 MPlayer Team
CPU: Genuine Intel(R) CPU           T2500  @ 2.00GHz (Family: 6, Model: 14, Stepping: 8)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

VLC version 0.8.6b Janus
Compiled by videolan@epsilon.via.ecp.fr.
Compiler: gcc version 4.0.1 (Apple Computer, Inc. build 5367)
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by the VideoLAN team; see the AUTHORS file.

==

Ok, so here are some examples:

This one will play in VLC, but won't play in mplayer:

This plays in VLC and mplayer for me.

This video stalls in VLC, but will play in mplayer with no issues:

I did not experience any obvious stalls with VLC. mplayer was able to handle the file, as well.

This one will play in everything (Including quicktime):

Same results.


Tomorrow I'll see what information I can get out of these videos with regards to what encoding options they used.

[JudgeHolden]

Ok, aerialesque's video plays perfectly in all players (to me, the perfect incode ... I don't know why people wouldn't want their encodes to be player freindly as possible). Oh, did anybody point out the fact that she forgot an extention?

As for yours, it works fine in VLC and mplayer. as for bframing, I have never seen a real size difference between using them in h264 and not using them (from the videos I have downloaded, I have never used bframes for h264, Dvix yes, h264 no) ... So again, I don't get why people would want to use them, when one can not use them and have a more compatible video. Anyway, so those two encodes are good ones.

I know when Rina was encoding, she was playing with every feature ... So, I do wonder if others do to .... if one dose it good, then 3 doses are better. That coupled with the fact that the codecs may not be as up to date for ppc just adds to the issue.

[trythil]

(to me, the perfect incode ... I don't know why people wouldn't want their encodes to be player freindly as possible)

The only reason to not use encoding features is if you're aiming for an environment in which you know there is no possible way for those features to work. For example, it would be stupid to try and make a video iPod play H.264 High Profile
video.

But on the desktop, where there is a choice of video players, and some are more compliant than others, I see no reason to handicap the encode just to accommodate the least capable player.

This stance means that a lot of people, by choice or policy, will not be able to play back what I distribute, and it probably goes against common wisdom among video professionals.

It's why I'm glad I don't work in that field.

as for bframing, I have never seen a real size difference between using them in h264 and not using them (from the videos I have downloaded, I have never used bframes for h264, Dvix yes, h264 no)

Whether or not B-frames make a difference is highly dependent on the input data. Long pans and motion like that tend to benefit a lot; lots of fades and flashes, not so much. Also, the B-frame difference isn't so much size as it is being able to achieve some level of quality at a smaller size.

That coupled with the fact that the codecs may not be as up to date for ppc just adds to the issue.

Well, first off, it's not a fact, it's speculation.

Second: what issue? You started out with

Exactly, the mp4 the PC users here use, is not standard h264 encodes

but I've yet to see evidence for that.

If the problem is really with software efficiency, or even with features missing from a port of the decoder software, then that doesn't mean that "PC users are using non-standard h264 encodes". That would be like saying that any video that the video iPod can't play must be nonstandard: taking decoder limitations and inferring file problems in the files from those limitations.

[JudgeHolden]

(to me, the perfect incode ... I don't know why people wouldn't want their encodes to be player freindly as possible)

But on the desktop, where there is a choice of video players, and some are more compliant than others, I see no reason to handicap the encode just to accommodate the least capable player.

This stance means that a lot of people, by choice or policy, will not be able to play back what I distribute, and it probably goes against common wisdom among video professionals.

It's why I'm glad I don't work in that field.

You see this is what it comes down to. To me a "Standard" encode will be as cross-platform and cross-player as possible. So, I'm for trying to get standards that make h264 videos on the org easier to play for the everyman (it's not like it's hard for me to try a different player if a video doesn't work in one, but I'm thinking of the other people who are downloading the videos). I know, I'm bucking the trend (Which I often seem to do ) here and even going against my own elitest tendancies, but I would like to see this great codec really become the codec of choice. However, I don't want to leave people behind at the same time. So, what I mean by standard is that it will be a simple encode, compatible with most players (kinda like dvix/xvid has become, where it is easy to play in every player,on a computer, not just VLC). As for converting for an ipod, that will have to be done by the consumer, unless one uploads an ipod version to ... hmm that's an idea. Anyway, that's what I am getting at in the end.

As for not updating the mplayer codec of ppc, it looks like the last update on their site was 2004 ... I could be wrong.

Anyway, I will continue to move back and forth in players. I just wanted to voice a different view on the subject of AMVs encoded in h264 on this site. [/i]

[Zero1]

It all depends on the video. One might sutter in VLC and then play great in mplayer or may not play at all in one and play in the other

As you may appreciate, H.264 requires more processing power than MPEG-4 ASP (eg XviD/DivX). In addition to this, that complexity can vary a lot between two videos. For example XviD uses 2 reference frames (which is an option you do not see or can change); in x264 you can set it to 0, or way up to 16. There's even options such as how the bitstream is coded, you can use CAVLC which is more efficient than Huffman (Huffman is the algorithm used in Zip files), but doesn't require huge amounts of processing power, and then you have CABAC which gets awesome savings but eats CPU time. Even the bitrate has effect since the higher the bitrate, the more stuff there is to decode with CABAC.

Like some people trying to do to much and not really undersatnding what they are doing. Confused Anyway, if you are on a PC, you would never see these issues.

I appreciate you may not be familliar with opensource, or the community or people who write these programs, but they are all very well capable of what they are doing, and unlike MKV where there may be an amount of guessing at how things are handled, stuff like H.264 and MP4 is fully documented by MPEG, and these developers have a copy of those documents (it's simply in .pdf format), so it's not as though they are reverse engineering. Trust me on this one, but please show some more respect for the people who are doing this for free. Without them you wouldn't have VLC, FFDShow, XviD, x264, MP4box, MKVMerge, Virtualdub, AVISynth, DGIndex, or even the org itself. If you doubt the ability of the developers, pengvado the developer of x264 now works at Nero (the CD/DVD writing software people) after seeing x264; and MP4Box has seems to have some kind of ties with ENST, which I think is some French telecom company (but since I don't know French, I can't look into it).

Oh, and mplayer seems to be the more relaible player for mp4s on a Macs, so it could also be a problem with VLC.

I had a sneaking suspicion this would end up being CPU related, but this seems to be a coincidence. mplayer usually has lower CPU requirements than VLC, so that may be why VLC stutters and mplayer doesnt. That isn't inconsistant implementation, that's your CPU being too slow to run the file in VLC. Given a fast enough CPU, I would lay money that VLC would run fine too; after all MP4 has been around since 2000, and has had major usage in the last 2 or 3 years. Do you think the developers would still not have got it right by now despite having the documents?

such as the ffmpeg decoder (used in mplayer and VLC)

That's the other thing; both players use the same decoder, so the fact that it plays in one and not the other seems fishy.

Now, why the difference? It can't be processing power, cuz then the first two wouldn't work in any player.

As I said, processing requirement can vary a lot between files of even the same framerate and resolution, not to mention that even players that use the same decoders have different CPU and memory requirements.

Now h264 became big on this site AFTER the new intel processors, so maybe there is a glitch between intel macs and G5/4 macs?

lol what? H.264 became big here in particular because I was continually pimping it in the AMV channel, wrote a guide and would help people if they wanted it (although I do not want to come across as big headed, but I have tried pretty damn hard to put the wheels in motion). They saw how awesome the codec was, and it spread via word of mouth. In addition to that, I was also doing my damndest to promote it to some fansub groups, and there is a hugeass thread on Animesuki where I discuss it extensively, so hopefully people can gain something from that. Not to mention it's being used in iPod, PSP, HD-DVD, Bluray and some hardware players (like KiSS 1600); it's generally the buzzword now.

Also not everyone who is encoding and playing back H.264 is doing so on a Mac, so the fact that Mac now has Intel CPUs has little to no bearing.

What is likely the issue (and trythil may well confirm or deny my theory) is the architecture difference between the G4/G5 and Intel Macs. Programs like VLC, mplayer, or rather the decoder, are written for x86 instruction sets, and generally not optimised for Mac because it's a relative minority. If the Intel Macs are similar or the same CPUs as Windows PCs, then performance shouldn't be an issue because it's a similar architecture. Having said that, I'm not that keyed up on CPU architecture so it would be great to get another opinion.

I hate to come across abruptly, but you are blaming things without fully understanting what or why it's happening.

You see this is what it comes down to. To me a "Standard" encode will be as cross-platform and cross-player as possible.

To me a "Standard" encode is anything I produce that complies with what MPEG specify. That is pretty much any encode I've produced using x264; and I could probably verify that if I had a compile of the H.264 reference software (where if it decodes with that, it's standard as far as MPEG are concerned).

I'm doing my part right; I'm complying with MPEG's specification (which is available to any company that wants to implement H.264 and/or MP4) as best I can, even using the recommended audio and container, if Apple only has a partial implementation of a decoder that's a shame for Mac users, but it's not my problem, they need to bitch at Apple to give them a full decoder.

There has to be a cutoff point somewhere. I mean do you expect me to release stuff in 320x240 DivX 3.11 just because there is a minority still with 500Mhz CPUs? If you don't take H.264 for everything it's worth, you may as well stick with XviD and just have larger filesizes.

Also Alternate Dimensions plays flawlessly with CoreAVC, FFDShow and VLC, having said that it's 29.97 fps and is high motion with a high bitrate, so it's likely your CPU is lagging.

Hate the player, not the game

[Kevmaster]

I use Total Video Convertor to convert the H264's to the right format for my Ipod..but somehow..it doesnt seem to work on some videos, but it works for other videos...