RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-26 17:12:36 +00:00
Code Issues Releases Wiki Activity

even more cosmetics

Browse Source 
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@139 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
gabucino 2001-03-18 16:01:12 +00:00
parent ded812206a
commit 1ac1aa40ba
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
DOCS/tech/general.txt
View File

@ -51,19 +51,19 @@ Now, go on:
3. mplayer.c - ooh, he's the boss :)
The timing is solved odd, since it has/recommended to be done differently
for each of the formats, and sometimes can be done by many ways.
for each of the formats, and sometimes can be done in many ways.
There are the a_frame and v_frame float variables, they store the
just played a/v position is seconds.
A new frame is displayed if v_frame<a_frame, and sound is decoded if
a_frame<v_frame.
When playing (a/v), it increases the variables by the duration of the
played a/v. In video, it's usually 1.0/fps, but I have to mention that
doesn't really matters at video, for example asf doesn't have that,
instead there is "duration" and it can change per frames.
fps doesn't really matters at video, for example asf doesn't have that,
instead there is "duration" and it can change per frame.
MPEG2 has "repeat_count" which delays the frame by 1-2.5 ...
Maybe only AVI and MPEG1 has fixed fps.
So everything works perfect until the audio and video are in perfect
So everything works right until the audio and video are in perfect
synchronity, since the audio goes, it gives the timing, and if the
time of a frame passed, the next frame is displayed.
But what if these two aren't synchronized in the input file?
@ -110,8 +110,8 @@ Now, go on:
5.a Codec controller: this is the greatest hack in the whole :)
The libmpeg2 is so unstable, that I can't believe it.
Of course I don't mean it bullshit :) rather it only accepts
totally perfect, errorfree streams. If it founds error, it's
just a segfault ;) And don't start laughing, this is great this way,
totally perfect, error-free streams. If it founds error, it
just segfaults ;) And don't start laughing, this is great this way,
from the view of speed it would be 50-100% slower if stuffed full with
verifications. That's why I solved it by running it in a separate
process, and if it dies, who cares, just start another.
@ -121,11 +121,11 @@ Now, go on:
So the MPlayer doesn't have to care about this, it just pumps the
compressed stuff into the child, which displays it.
- shmem: the compressed data, and the uncompressed frames are both
in shared memory, so all 3 processes (mplayer, codeccontrol,
in shared memory, so all 3 processes (mplayer, codeccontrol,
libmpeg2 codec) sees 'em, so they can trade data fast.
- FIFO is used for the communication between them.
- If the child dies while decoding, the succesfully decoded data
isn't lost, they are inherited by the new child throught the
isn't lost, it's inherited by the new child through the
shared mem! So only a little error can be seen in the video,
it won't disappear or turn green, as in the older versions.