[MPlayer-dev-eng] Playing growing MPEG files

[Doc Holliday]

On 12/29/2011 11:23 AM, Reimar Döffinger wrote:
> On Mon, Dec 26, 2011 at 03:14:56PM -0500, Doc Holliday wrote:
>> I have a small Qt-based GUI that runs on top of mplayer in -slave mode
>> and allows users to navigate to different positions in the file by means
>> of a slider (QSlider). The user drags and drops the slider handle and
>> the mplayer jumps to the appropriate position in the file and continues
>> playing from there.
>>
>> This all works great until they start playing a growing file, which
>> happens regularly and which I am trying to figure out solution for.
>>
>> Playing growing files with mplayer seems to generally work. However,
>> time length of the file is set in demux_mpg_open and is not updated
>> after that. So the new part of the file, which has been recorded after
>> the file was open is not accessible through the slider. Currently, the
>> user has to stop playing the file and start playing it again.
>>
>> My idear was to do the following:
>>
>> 1. Regularly call demux_get_time_length (eg in from print_status)
>>
>> 2. Which in turn calls demux_mpg_control(DEMUXER_CTRL_GET_TIME_LENGTH)
>>
>> 3. Inside demux_mpg_control I:
>>       a. Call stream_control(STREAM_CTRL_GET_SIZE)
>>       b. Update demuxer->stream->end_pos and demuxer->movi_end
>>       c. Save current stream position
>>       d. Call read_first_mpeg_pts_at_position( demuxer->movi_end -
>> TIMESTAMP_PROBE_LEN )
>>       e. Update final_pts and first_to_final_pts_len
>>       f. Restore current stream position
>>
>> Unfortunately, the above does not seem to work, as I end up with corrupt
>> screen and the file not playing. My guess is that there are some
>> internal structures/buffers that get messed up and interrupt the "flow"
>> through the file.
>>
>> I am wondering if the above is a workable approach and it's just a
>> matter of preserving a few other variables prior to calling
>> read_first_mpeg_pts_at_position or if there is another better or more
>> proper way of doing this.
>
> You can't use read_first_mpeg_pts_at_position because it flushes
> all buffered data.
> At least as importantly, your approach of seeking back and forth
> all the time will give abysmal performance e.g. over http, from
> a CD/DVD and in general anything networked with high latency.
> Even when playing from disk the cache flushes the seeks cause would
> be bad.
> What to do depends on what you need. The duration for MPG files is
> between "inaccurate" and "nonsense" anyway, so one option is to
> just make guesses based on the size.
> Or you could start a second MPlayer just with -identify to get the
> new time guess (note however that just because a file has the same name
> does not necessarily mean it is the same file as the one you are playing
> - someone might have deleted that for example).
> You could possibly add a command to update the duration of a file,
> though that would require a lot more changes than what you attempted,
> particularly for MPG.

Thanks Reimar. I found it out the hard way. :)

There is a small patch, written by Vlad, which will make mplayer wait 
for new data to arrive.

What I will do is fire up 2 mplayers at the same time and run one of 
them with -vo null -ao null, put it at the end of the file and set speed 
to 4X. This way it will constantly keep bumping into the last frame of 
the file and sit there waiting for fresh data. I will parse its output 
and use it to figure out the length.

The other mplayer will run normally.

-Doc