[Ffmpeg-devel] Modify ffplay for realtime playing

Phuoc Do pdo.cloud
Wed Apr 25 09:35:58 CEST 2007

Hello again,

I confirm the points made by Michael and Relmar. After some more debugging
into the issue, I realized that the stream stopped playing is not because of
packet corruption. The stream stopped playing because the reader reached the
end of the stream. Here is the piece of code the it gets stuck in:

        /* if the queue are full, no need to read more */
        if (is->audioq.size > MAX_AUDIOQ_SIZE ||
            is->videoq.size > MAX_VIDEOQ_SIZE ||
            is->subtitleq.size > MAX_SUBTITLEQ_SIZE ||
            url_feof(&ic->pb)) {

            /* wait 10 ms */
            fprintf(stderr, "skipping url_feof(&ic->pb) = %d\n",
        ret = av_read_frame(ic, pkt);
        if (ret < 0) {
            if (url_ferror(&ic->pb) == 0) {
                SDL_Delay(100); /* wait for user event */
            } else {

I added the fprintf statement and see that the value of url_feof(&ic->pb) is
1. I guess ffplay is reading faster than the incoming stream. Though I am
pondering with the appropriate solution in this case. I'm thinking of
reopening the stream but that seems to produce too much overhead. Is there a
way I can seek forward and ignore eof?


On 4/20/07, Phuoc Do <pdo.cloud at gmail.com> wrote:
> I might be doing something wrong then. ffplay is not playing the streams
> correctly. Here is my setting. On a remote machine, I run my test video
> file: mpeg4 video 384 kbs and mp2 audio 64 kbs. I use VLC and encapsulate
> the streams in ASF container format. VLC outputs the resulted stream to a
> http address and port. On my local machine, I tried to use VLC and MPlayer
> for playback. In both players, the stream stops playing after about 5
> seconds. I then tried ffplay for playback. ffplay also stops after a few
> seconds. I noticed that A-V value gets larger overtime. My remote machine
> has a DSL connection and my local machine has a cable connection. I used
> Wireshark to capture the network packets and it shows that some of the TCP
> packets have wrong header information. That's why I am thinking that some
> bits are flipped and try to figure a solution to make ffplay more error
> resilient.
> Phuoc
> On 4/19/07, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>
> wrote:
> >
> > Hello,
> > On Thu, Apr 19, 2007 at 01:05:41PM -0700, Phuoc Do wrote:
> > > Sorry for the wording. It's not packet loss but the received packets
> > contain
> > > error, e.g. bits got flipped. So the header is corrupted in some
> > packets.
> >
> > That is not possible either with HTTP. Maybe you should try to read up
> > on at least the basics of the stuff you are using...
> >
> > Greetings,
> > Reimar Doeffinger
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at mplayerhq.hu
> > http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> >

More information about the ffmpeg-devel mailing list