[MPlayer-users] How do you play raw h.264 files in mplayer?

[Spidey / Claudio]

Since you are using a linear stream and a raw video file, I think you'll
have to tell mplayer as much info as possible before playing it correctly.
First, try to find out what is the correct framerate of this camera, maybe
it's 24.976 or something like movie cameras use nowadays. Secondly,
determine the exact codec of the video stream. I think you got that right
already.
Then, you'll have to feed mplayer or any player you have with the correct
parameters: tell it to don't expect a container, tell it the video codec and
that it's a single stream, tell it you are using a named pipe and a linear
stream, so it shouldn't seek unnecessarily.
I'm not a mplayer wizard, but reading it's man page and documentation should
give you the idea of how to do this. If you can't do this this way, you can
still use a "log rotation" software or something like that to rotate your
video files (say, 10 video files, a.h264 to j.h264), and use a playlist to
play these files in repeat playlist mode. Let's say you use 10 10mb files,
so the total disk usage will be 100mb. When you are watching the tenth, the
rotation software would delete and re-fill the first file, with new data.
You'd need a little delay in this setup, but just enough so that mplayer
doesn't error when changing the source file.

Claudio Roberto França Pereira (a.k.a. Spidey)
hardMOB - HTForum - @spideybr
Engenharia de Computação - UFES 2006/1


On Fri, Aug 12, 2011 at 09:13, David <wizzardx at gmail.com> wrote:

> >
> > My guess is that it's waiting for a keyframe or some other kind of header
> that is inserted in the stream periodically. If it's a live stream, it has
> to wait in real time, whereas if it's playing a file saved from the stream,
> it can read it in as fast as it likes until it finds what it's after.
> >
>
> My problem with that, is that mplayer can start playing the "piped
> into a file" version almost immediately (eg: 1 second after it's
> created), but when it's on a named pipe/stdin, then mplayer takes 10
> seconds (or much longer - somtimes never) to detect the stream type
>
> So I think that mplayer might have some slightly buggy "detect the
> stream type" logic when it comes to pipes (it assumes it can seek in a
> linear stream, constantly hits errors trying to do that,  but in the
> meanwhile it's missing headers on the pipe that it could get quickly
> if it was just patient and waited for a second or two).
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
>