Tags:
create new tag
, view all tags

[g]mplayer Sometimes Freezes at First Frame on Some Videos

ffmpeg gives message: "Seems stream 0 codec frame rate differs from container frame rate: 1000.00"...

See:

Contents

ToDos

I want to add names from the ffmpeg and mplayer mailing list to the suggestions made to me. (I.e., give them credit.)

Disclaimer: My Limited Video Knowledge / Experience

I need to find a better way to say this, but I want to indicate that I am not very knowledgable about playing or converting videos. So, almost all of the following represents a learning experience for me. There are, quite likely, errors in the following, or things that I found somewhat surprising but that others would say, "Duh, of course." Still, I couldn't find any real helpful information to help me address the problem, so I started this page in hopes it may help others (and also serve as a reference / reminder for me).

Wish List

In view of the difficulty I had in solving this problem, I can think of some things that might have helped me. I'll call it a wish list, but some of the things I describe may exist, I just haven't found them.

  • good "entry level" documentation on videos (on Linux, using mplayer and ffmpeg) that answer my questions without forcing me to wade through the answers to everybody else's questions wink
  • that includes a good understanding of where the 1000 fps container frame rate comes from--one or more sources (including some of the responses to my questions on the mail lists) indicated that it is meant to indicate a variable frame rate (iiuc)--but what is the point if the codec recognizes a specific frame rate (in these cases, 29.92 fps)
  • tools to view and change specific things about a file--it would be nice if there were an application (GUI) that did things like read the information about (i.e., contained in) a video file and told me about problems, and then let me make manual changes to address those problems (where feasible). Obviously, I wouldn't want to change the time stamp on each frame of a video manually, but, assuming the container frame rate is only present in one (or a few) locations in a file, it would be nice to be able to easily change that without, for example, running ffmpeg to do a conversion on the entire file. (This relates to my surprise when running the ffmpeg command (below) on the file which I expected to do something like this--that is, just change the container frame rate from 1000 fps to 29,92 fps, which is already the codec frame rate--imagine my surprise when increased the file size by 25%. (Of course, iiuc, one of those frame rates is not explicitly in the file, but is calculated somehow based on the timestamps on each frame of the video.)

Update: there is a program called ffprobe (iirc) which might be helpful to look at the content of files in detail.

New Insight: Are the problem files compressed?

ToDo: Deal with the following wink

I found that, for one of the problematic files, I somehow acquired two copies, but one is about 3 times the size of the other and works fine. Now looking back at the other problematic files, I see that they are all on the order of 1/3 the size of what the non-problematic files are for a given playback duration. So maybe the problematic files are compressed?

If so, maybe I can use ffmpeg (or something) else to create an uncompressed version of the problematic files.

I should also look at all the non-problematic files and see if any of them are about 1/3 the size I'd expect--maybe there is a variation of a compressed file that does not create a problem on playback?

Ahh!--h264 is a compressed video format. (I thought most of my good (i.e., non-problematic) videos are also h264, but maybe I'm wrong about that, or maybe h264 has a selection of compression schemes, some more compact (and more time consuming to decode) than others? Looks like I'm going to learn a fair amount about h264 before I'm done.

But, going a step further, considering that video that I have two copies of, one 1/3 the size of the other, and where the big one works fine and the little one doesn't, both use h264. I had read about variations in the h264 specification, this is presumably an example of one and looks like it is biting me.

Problem

Some videos I try to play on [g]mplayer sometimes freeze at the first frame (sometimes later) although the audio (usually) plays fine.

I suspect that the reason they sometimes freeze and sometimes don't relates to the load on my system. Sometimes if the video starts playing, but I do something to spike the load on the CPU, the video freezes at that point.

I've noticed that, for all the videos that cause problems for me, mplayer thinks the container frame rate is 1000 fps.

Also, those same videos are all encoded as h264 video.

When I try to convert (transcode) the videos in ffmpeg, I typically see the message:

"Seems stream 0 codec frame rate differs from container frame rate: 1000.00"...

Another clue to the problem is that, when one of those videos starts to play, there is a significant delay before the video starts--much longer than the delay for a non-problematic video.

I think a primary cause is that my system is heavily loaded and thus marginal for videos. Nevertheless, I wanted to find a solution that did not involve replacing my system, and I've found several. Some I've tested, some I haven't.

My operating system is Linux (Debian 5.0 / Lenny) and my computer uses a Celeron(R) 3.06 GHz cpu and has 1.5 GB of RAM. However, I keep a lot of things open on the 8 desktops I switch between. Also, I have a dual head system, and I've set things up so that when I play videos, they play on the 2nd head on all eight desktops (and, thus, just add to the load on the already heavily loaded system).

Clearly, one day I will upgrade, but it won't be soon.

Solutions

Overview

The (potential) solutions:

  • upgrade (g)mplayer to the latest version--not tested
  • get an upgraded video card that takes more of the load of displaying a video--not tested
  • convert the video to a different format that works more reliably--done, tested, I prefer the next two solutions
  • use a per file configuration for mplayer that corrects the 1000 fps designation and helps mplayer recognize the format sooner--done, tested, works somewhat, and is my current preferred solution
  • reduce the load on my system--done, tested (in combination with the above)--I've reduced the load significantly on my system by adding the noscript plugin to Firefox (well, it's called Iceweasel on a Debian system)--I'll probably create a page extolling the virtues of noscript--my preferred solution includes using noscript, I'm not sure the problem will go completely away without noscript, and I've found very few downsides to using noscript
  • upgrade my OS--it will happen, but not all that soon--not tested
  • upgrade my hardware and OS--it will happen, but not all that soon--not tested

I plan to expound on all of these soon, but I got a phone call that I was waiting for and now need to deal with something else for a little while.

upgrade (g)mplayer to the latest version--not tested

I'm fairly certain this would work, but I haven't tried it because Debian 5.0 doesn't have a .deb package with the very latest mplayer in it. In fact, I'm told it is a quite old version.

mplayer developers have told me this will solve the problem, and I don't really doubt them in general, but, because I'm pretty sure my problem is due to a heavily loaded system, there is no guarantee this would solve the problem on my system.

upgrade the video card--not tested

People on the mplayer mail list have pointed out to me that I could upgrade my video card to one that did more video processing on-board. Examples include the nVidia 8400 (or higher) series that can utilize vdpau.

convert the video to a different format--tested, works

An ffmpeg command like the following converts the video so the container fps is set to 29.92 which matches the codec fps. (It leaves the video in h264 format.)

ffmpeg -i <infile>.flv -vcodec libx264 -acodec copy -r 29.92 <infile>_1000fix.flv

The video then plays fine, with perhaps a little degradation in video quality--rather difficult to see, and it may be my imagination.

The conversion does increase the size of the file by about 25%. And, really, both of those changes surprise me because I would have guessed the file is already at 29.92 fps and h264. (I didn't say it above, but one of my suspicions is that the only (or main) problem with the file is that there is something in or missing from the file that makes it take longer to recognize the format the file is in, and that contributes greatly to the stopping after the first frame problem.)

use a per-file configuration file for mplayer--tested, works

You can create per-file configuration files for mplayer. I've now created one for each of the problematic files. Name them the same as the problematic file name, but add an additional extension on the end ".conf". The default location for them is in ~/.mplayer.

The configuration files contain these two lines:

vc=ffh264
fps=29.92 # or 30000/1001

The file has, so far, consistently solved the problem of the video freezing, but I'm not sure it is really doing all I'd like it to do. It still takes longer for mplayer to start playing these files, and mplayer (and ffmpeg) still thinks the container frame rate is 1000 fps, but the video doesn't freeze.

reduce the load on my system with noscript for Firefox--tested, works

I was thinking about trying to do something about the load due to Firefox (or Iceweasel as it is named on Debian). Before I found noscript, I would go into the Iceweasel preferences and disable java and javascript unless I was on a page where I really wanted them. I was able to play the videos without freezing with java and javascript disabled.

But, going into the options so often to enable or disable java and javascript got old fast. I had visions of writing my own extension to Firefox--something simply to display two buttons somewhere on each tab to enable or disable java and javascript for a given tab by selecting or deselecting those buttons.

Then I decided to see if there was an existing plugin to do that. Without too much effort I found noscript--it sounded like it would serve the purpose, I tried it, and it is (mostly) wonderful.

I should create another WikiLearn page just to talk about it.

upgrade my OS--not tested

The big advantage of this might be that if I update to a later version of Debian I would probably have access to a more recent version of mplayer in a .deb package.

upgrade my hardware and OS--not tested

But, surely, a fast enough system (or more RAM) might do the job. (My system has 1.5 GB of RAM, but can be upgraded to a max of only 2 GB--I'm not sure that will make a big enough difference to solve the problem.)

Contributors

  • () RandyKramer - 2011-10-24
  • If you edit this page: add your name here; move this to the next line; and if you've used a comment marker (your initials in parenthesis), include it before your WikiName.

Revision Comment

%SECTION{last_revision}%
  • %DATE% —

Page Ratings

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2011-10-29 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look