On Sun, Nov 26, 2006 at 06:30:28PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Nov 25, 2006 at 01:38:39PM -0500, Rich Felker wrote: [...]
The only other possibilities are to give up on your correct seeking with subtitles (which you seemed to want the most of any of us) or throw in thousands of fake empty keyframes.
yes, ~1000 small (<10byte) keyframes whos position in time matches the video keyframes would be the correct solution, needing 10kb for 2 hours is negligible its a mere ~ 0.01 kbit/sec
It's not correct! To do this the muxer has to manufacture data as
my sugestion was not to make the muxer inject new frames but rather that you cannot seek to points where there are no keyframes (this is pretty much how things normally behave, ignoring subtitles ...)
Well the result of this is that _someone_ must inject new frames or else all movies with subtitles become completely unseekable...
with gaps/EOR OTOH its possible to seek to keyframes and gaps but if so why disallow it for non subtitle streams? what extra computations would be needed on the demuxer side for non subtitle EOR? (a muxer could always choose not to support EOR)
Nothing whatsoever on the demuxer side. The problem is on the player side. The player would either have to be able to either generate silence (for audio) or switch to a different sychronization system... Anyway the practical difference here is that EOR for subtitles is needed to implement in NUT something that is already existing practice: movies that do not constantly have a subtitle displayed. EOR for audio/video, while it could be nice, is not needed for any existing practice, only to add a new capability that did not exist before.
well! It also means seeking will be _incorrect_, in the sense that if you disable video and just enable audio and subs, seeks will go farther back than they need to in order to find the _useless_ blank subtitle.
which will cause a few milliseconds of useless computations after a seek
Depends on the behavior of the player, but hopefully yes. More fundamentally, the principle of "correct seeking" is violated, and if we're going to violate that we might as well not have put so much effort into ensuring that it works to begin with. You never cared much about it but I did...
PLEASE for the love of [insert deity here] stop bringing up old issues now; it's too late. It's easy to complain about these things now 1.5-2 years later when everyone's forgotten why the decisions were made the way they were and why they're essential to correct operation, but that doesn't mean we should go through the same process again now only to rediscover the same thing. :(
its a bad sign if you need to think about something for days to rediscover why it was needed,
If this is the case then all of NUT is a horrible horrible design. The point is that it's easy to satisfy all the conditions required on muxing and that it's easy to implement a demuxer. Understanding _why_ all the conditions are necessary was never intended to be easy, and IMO it's impossible to make a good set of conditions which are both easy to satisfy/interpret AND easy to understand the motivation behind. If not impossible, it would take us at least 6 more years...!
it means IMHO the thing is too complex already or the case which needs it is pretty obscure or the reasoning hasnt been documented, in which case disscussing the issue and documenting the reasoning seems like a good idea ...
OK if someone can come up with a list of requirements/features/etc. in NUT that seem unjustified, I will write up detailed documentation on what they're needed for. Maybe I'll be wrong and it will be easy to understand once I've written this... Rich