
On Sat, Nov 25, 2006 at 11:53:16AM +0100, Michael Niedermayer wrote:
Hi
On Fri, Nov 24, 2006 at 10:58:20PM -0500, Rich Felker wrote:
On Sat, Nov 25, 2006 at 12:03:55AM +0100, Michael Niedermayer wrote:
[...]
* nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file
Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true?
Other containers don't support correct seeking with subtitles unless they have an index of all subtitles.
i dont think this is true, maybe someone who knows the details about subs in mpeg-ps/ts could clarify but my suspicion is that there are rules in the relevant specs which ensure that the correct subs are displayed after seeking, and most other containers which support subs have an index ...
I'm quite sure mpeg-ps/ts make no provision for this. Maybe Måns would like to back me up though? DVD players and other devices that seek on mpeg streams generally have _horribly_ crappy behavior under seeking and don't seek at all except to chapter boundaries or via 'fast read and skip decoding of nonkey frames'. I've never seen one with seek-to-time, probably because mpeg does not even make seek-to-time possible due to meaningless resetting timestamps...
just try:
Sub: K K Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF
you can either A. ignore the subs and seek purely based on the video stream (will not display subs after seeking) B. seek to previous keyframe of all streams (will not allow you to seek into the 2 hour segment without sub keyframes
Having the same subtitle displayed for 2 hours duration (or even more than 5-10 seconds duration) is nonsense. If you meant for the subtitle at the beginning in your example to only be briefly displayed, then no subs for the next 2 hours, EOR is what allows NUT to accomplish that!
my example is about a non nut container, and what is displayed or not between the keyframes of the subtitle stream is NOT known to the demuxer (and neither to the nut muxer which should mux that, unless it parses the subtitle stream ...)
I don't think it's unreasonable at all for the muxer to need to be passed durations for subtitles as well as starting timestamps. Without duration there's no way the demuxer could possibly support knowing whether the subtitle is still relevant when seeking. EOR is just a clean stream-oriented way to encode duration and prevent messing up the back_ptr system.
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 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. 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. :( Rich