The VideoLAN Forums

I have an mp4 file that will not play on my linux VLC (it stutters & freezes) but it plays fine on windows. A different mp4 plays fine in linux. So the problem must be in the linux vlc support for the codec of this particular file. How can I find out what codec is used in this mp4 file?

How can I find out what codec is used in this mp4 file?

Use MediaInfo ---> http://mediainfo.sourceforge.net/en

Great! Ok so I ran mediainfo on each of the 2 files. Now how do I identify the codec that is not working right on my linux machine?

Here is the output of mediainfo: http://i653.photobucket.com/albums/uu25 ... odbad2.jpg

Now how do I identify the codec that is not working right on my linux machine?

Hi
It looks like both those files use the same codecs.

"AVC" means MPEG-4 Part 10. For example, x264.
(If you use MediaInfo View > Text it shows more detail).

The two files are different Width/Height with different bitrates (Kbps) and framerates (fps) and they have different level settings (L3.0/L4.0).

Thanks for the reply. I compared the text output of the 2 files and saw other differences such as the codec ID and format and encoding settings (the file that won't play is AVI (not mpeg-4), H264 not avcl, and has encoding setting of 12 threads not 6.

The ultimate question is what can I do to get the broken file to play on linux vlc? I've tried changing some settings to no avail. Do I need to update a video codec or do I need to find a magic setting that needs to be tweaked?

Here is the text output:

file that doesn't play: file that does play:

The ultimate question is what can I do to get the broken file to play on linux vlc?

Hi
It looks suspicious that the troublesome file is AVI.
That's unusual (but not impossible) for files with AVC video and AAC audio.
Maybe that's why Linux VLC doesn't like it.

If I had this problem I would try to fix it with FFmpeg:- I would then expect MediaInfo to show "new_titanictest.mp4" as MPEG-4 instead of AVI.

Thanks again. Well I downloaded ffmpeg and converted the file per your syntax, however linux vlc still choked on the file (even though mediainfo now shows it as MPEG-4 instead of AVI).

What else can I try?

By the way I put the file out here if anybody wants to download and duplicate the error in linux (I'm running ubuntu 10.04):
http://krissbrown.net/titanictest.mp4

Avi is the encapsulation of the file, not to be confused with the codec. Typically avi files have the codec divx which is a certain mpeg4 variant. Other encapsulations are PS (typically for mpeg2 files) or TS (for files obtained from dvb records, with mpeg2 or mpeg4).

Stating the obvious maybe, but make sure you use the same versions of VLC and FFmpeg/libav on Linux as on Windows, if it works on Windows...

H.264 High in AVI, is wrong in every way possible.

Wrong in every way possible? You lost me. Would I have better luck if I update the codec for h.264 in my linux vlc?

http://krissbrown.net/titanictest.mp4

This is one of the worst sample files I've ever seen.

This is an AVI with an MP4 extension.
In this case AVI is bad because the video stream is H.264 encoded and AVI can't properly handle B-frames. It also gives some error messages like this: The video stream is strange. It is very jerky at the beginning untill around 0:09 and then seems to become quite stable. According to the resolution, it seems to be a BD rip but it is 25 FPS. There is no BD at 25p, it's not in the specs, and a quick search shows that there is no 50i version of Titanic. So why has it been encoded at 25 FPS rather than the original FPS ? Anyway, muxing it at 23.976 or 24 FPS or playing it at 25 FPS still gives a bunch of errors like these: The audio stream is just broken. It appears to be HE-AAC at 128 kbps and 48kHz. There is no reason to use HE rather than LC at this resolution. I wasn't able to find anything that would play it and VLC gives a load of error messages: So to sum it up, this file is broken at every stage. The rip must be done again with the proper FPS for the video, a standard audio and an MP4 or MKV container for the H.264 video.

So to sum it up, this file is broken at every stage.

Thank you!

Lotesdelere , thank you for the technical analysis. I take no responsibility for the file's shortcomings since I didn't create the file.

Nevertheless, the point is that windows VLC managed to play the file whereas Linux VLC choked on the file. So windows VLC is somehow using code that is more fault tolerant, which is a very huge benefit. Just think, if your web browser were not fault tolerant, you wouldn't be able to view a lot of websites because of incorrect html/javascript. Likewise, I'd like to maximize the fault tolerance of Linux VLC for whenever I want to view "faulty" movies.

Or alternatively, is there a utilty to enable me to easily repair the file? I unsuccessfully tried fixing with ffmpeg already but maybe I need to pass it special command options.

Nevertheless, the point is that windows VLC managed to play the file whereas Linux VLC choked on the file. So windows VLC is somehow using code that is more fault tolerant, which is a very huge benefit.

In the vlc preferences (just for ffmpeg and h264 I believe) there is an option how vlc treats faulty files. If you chose for your linux vlc version the same setting of the option as in the windows vlc version (and if both vlc versions are identical with same ffmpeg versions) it should work in both cases.

Thanks! But I'm having trouble finding this option. I dont see anything about "faulty" files under INPUT/CODECS -> x264. What would the setting be called and where is it?

For vlc-2.0.x the option is:

preferences => all => Input/Codecs => Video Codecs => FFmpeg

and here the option is: "Error resilience" with values between 0 and 4.
when you move the mouse-pointer over this option it shows a small text with some explanations (at least with me). They actually say that there is a buggy M$ encoder creating some trouble and probably if your file comes from this encoder it is better to chose "0" (no error resilience). Actually to my understanding error resilience refers first to transmission error (e.g. antenne reception of DVB-T with mpeg4 etc.) but using a high error resilience may create problemes with buggy files.

In any case you can try all the values of this option and see what it does.

I am not sure but it may be possible that the differences you observed between windows vlc and linux vlc may simply be due to a different setting of this option.


PS: in vlc x264 is to my understanding used to "encode" h264. For decoding of h264 vlc uses FFmpeg.

Thanks again. This is VLC 1.0.6 for Linux, but I found error resilience under input/codecs => other codecs => FFmpeg.

Unfortunately, vlc still choked on the file using all values from 0 to 4.

Might any of the other settings make a difference?

Also is it possible to compare the version of the FFmpeg library module between Linux and Windows?

So windows VLC is somehow using code that is more fault tolerant, which is a very huge benefit.

Or alternatively, is there a utilty to enable me to easily repair the file? I unsuccessfully tried fixing with ffmpeg already but maybe I need to pass it special command options.

VLC for Windows is showing some of the images but many are dropped. No audio is heard, at all, by any player I've tried. VLC for Windows is not playing the file, it's just running it, more or less.

As I said this file has been badly encoded for both the video and the audio streams. Nothing can repair it, it must be reencoded again from the source. Once again, this file is broken, deal with it.

Ok everybody, please bear with me. I've found out some more info.

First of all, that file titanictest.mp4 was created by me using a program called avidemux. All I did was trim the movie so that I'd have a short sample clip. Both the complete movie and the sample clip stuttered and pixelated on my Linux system. I wonder if avidemux butchered the file?

I see that mediainfo shows different info on the original titanic move file (shows it as MPEG-4 not AVI) The original movie that I created the clip from plays apparently flawlessly on windows vlc. And not only that, but I discovered it plays apparently flawlessly on a DIFFERENT computer running the same exact live usb version of ubuntu linux with the same exact version of VLC (1.0.6 goldeneye).

The only difference is that other computer has twice as much ram (2 gigs), and is duo core. The computer with the stuttering/pixelating is a 2.4 MHz computer with 1 gig ram, more than enough horsepower to play other movie files.

So WHY would VLC have a problem playing the same file on a different computer?

First of all, that file titanictest.mp4 was created by me using a program called avidemux. All I did was trim the movie so that I'd have a short sample clip.

OK, so what we need is a sample of the original file.

Use DGsplit and read here about how to do it:
viewtopic.php?f=14&t=57724&p=193335#p193335
It's a Windows program but it should run fine through WINE.
50 MB max should be enough.

Ok I used dgsplit to create a new 51 Meg sample file:
http://www.krissbrown.net/titanictest3_0.mp4

This file plays fine on not only windows but also one 2.4 GHz laptop running ubuntu 10.04 live USB distro, VLC 1.0.6, but pixelates/stutters on a similar machine running same exact live usb version of linux/VLC 1.0.6 which is able to play other video files flawlessly. That machine also did the same thing when I tried a more recent VLC 1.1.13.

I'm wondering what the hardware would have to do with it. Any ideas?