[xine-devel] demux_mpeg_block_estimate_rate oddities and changes

[R. B. <ro...@ds...>]

I was going over the changes to demux_mpeg_block.c since 0.9.13. The
interaction between it and the vcdx plugin was causing problems. And
on investigation a couple of things in demux_mpeg_block look odd to
me.

demux_mpeg_block_estimate_rate() relies on the seek() and/or read()
mechanism returning a failure to get it out of it's sampling loop; I
find this odd. 

The reason this was causing problems with VCDX is that when you seek
past the end of an existing track or an existing entry, there is a
mode in VCDX which will just update the track/entry information and
give you the next one if there is one. 

Before doing its estimate demux_mpeg_block_estimate() does query the
size of the entry. So I think a better behavior is to respect that
size and not try to seek or read outside of that. 

Another change that defensive programming suggests (and may speed
things up on occasion), is to *bound* the number of samples, which of
course also bounds the amount of time used in this routines. After
all, this is an estimate right? If the selection (as *can* and often
*may* happen in a VCD) is just one big track of 800MB, does it really
help to take hundreds of samples just to get an estimate of the bit
rate? I don't think so.

For the curious, the reason this worked before with VCDX is that it
never got used because there was a test on INPUT_CAP_VARIABLE_BITRATE
which was recently removed.

Finally, I'm curious as to what this is used for. If it is to speed up
guesses when trying to seek to a particular time, I know VCD's
have scan points for such purposes. Could these be used?

Below is a suggested patch to bound the number of samples (and thus
time) used by demux_mpeg_block_estimate_rate() and not try to seek
outside of the range of the sample.