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 ...
NUT's back_ptr is the mechanism by which NUT makes this possible, but without EOR it will ruin seeking in files without extremely frequent subtitles.
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 ...)
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 if you have several streams with normal keyframe distances (10sec / 300frame) and the keyframes are not aligned relative to each other then you _CANNOT_ seek correctly, EOR does not help heres a example: vid1 KFF...10sec...FFKFF vid2 FF..5sec..FKF...10sec... to seek and display both streams you will have to _DECODE_ 5 seconds of video which with high resolution will need about 5seconds ... if one stream is a subtitle stream and one a video stream then the VERY same happens example: syncp S S S S S backptr v------/ / / v-------------------- vid KFKFFFFFFFFFFFFFFFFFFFFFFFFFFK sub K F F F K F F F seek target ^ for the seek target the last syncpoint is choosen, its back ptr points to the second sync point, decoding from there will give you a video keyframe after that there are maybe 10 seconds or longer until a subtitle keyframe you MUST decode these video frames without displaying them if you want correct seeking -> you CANNOT seek correctly if keyframes in a subtitle stream are not very frequent or aligned to the other keyframes, EOR has no effect on this if OTOH keyframes are frequent or aligned then EOR isnt needed, so what EOR seems to do is it affects only a case which doesnt work with and without EOR [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is