[FFmpeg-devel] [Ffmpeg-devel] Modify ffplay for realtime playing

[Michael Niedermayer]

Hi

On Wed, Apr 25, 2007 at 12:35:58AM -0700, Phuoc Do wrote:
> 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 */
>             SDL_Delay(10);
>             fprintf(stderr, "skipping url_feof(&ic->pb) = %d\n",
> url_feof(&ic->pb));
>             continue;
>         }
>         ret = av_read_frame(ic, pkt);
>         if (ret < 0) {
>             if (url_ferror(&ic->pb) == 0) {
>                 SDL_Delay(100); /* wait for user event */
>                 continue;
>             } else {
>                 break;
>             }
>         }
> 
> 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?

eof_reached should be reset if more data becomes available ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070502/0e4938cc/attachment.pgp>