On Thu 24.06.2004 at 01:26:12PM +0200, Dirk Meyer wrote: > Matthieu Weber wrote: > > On Tue 22.06.2004 at 11:42:37PM +0200, Dirk Meyer wrote: > >> The question is: how does the length help us? We use the mpeg length > > > > It is nice to display in Freevo to show how long the movie is :) > > Ok, current mmpython knows the length. And it is used to prevent > mplayer from seeking after the end of a file still growing > (recording). Since mplayer is very bad at seeking TS/PES (seek 60 sec > results in a 300 sec seek), there is a safety space you can't seek > behind. It's working ok for me.
I read that mplayer actually makes the seek in the file/stream (not sure which) using (seek_time x video_bitrate / 8). So if the video bitrate is a max bitrate instead of an actual bitrate, it jumps far too much. I have the same problem seeking in DVDs. Btw, do you have programs in Germany which are subtitled with a SPU stream which is independant from the video stream (i.e. the player has to overlay the subtitles over the video before displaying) ? I try to implement this in mplayer, since most of the foreign shows in Finland are subtitled, and the public channels use this method a lot. I'm far from finished, but I wonder if this feature could be needed in other countries having DVB-T than Finland, and if I should eventually test it with data from abroad. > >> to prevent the user from seeking over the end of the file with > >> mplayer. But since mplayer outputs the PES time, we don't know were we > >> are. Or do we? We know the last PES time in the stream (I hope). But > >> did we have a reset between our time and mplayer time? How often does > >> this happen? > > > > About once a day I guess (the timer runs up to 22 hours at least, from > > what I've seen here). > > > > you can calculate the maximum: 2^33 / 90000 = 95443 seconds (about > > 26hours, 30minutes and 43seconds). > > I know. But it could be possible to terminate a PES and start a new > one. True. But it would have another PID in the TS, wouldn't it? If it has the same PID, it is the same stream, I'd say. My guess is that the only thing that could happen is to reset the PTS counter before it reaches its max value. But why would they do that? (If I ask the question, they will probably do it just to show me wrong :) > >> and why don't they include ntp timestamps? And why 33 bit with some > >> marker bits to confuse me? > > > > Probably because it's the minimum amount of bits you need to get over > > 24 hours counting with a 90 kHz clock (but *why* 90 kHz beats me). > > Why marker bits? Don't ask too much :) Actually, if the marker bits are wrong, is there any special step to take (e.g. discard the frame)? They could be use for basic error detection. Matthieu -- (~._.~) Matthieu Weber - Université de Jyväskylä (~._.~) ( ? ) email : [EMAIL PROTECTED] ( ? ) ()- -() public key id : 452AE0AD ()- -() (_)-(_) "Humor ist, wenn man trotzdem lacht (Germain Muller)" (_)-(_) ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
