Frame droping when behind (catch-up)

[tempost]

i just emailed BSPlayer contact email the following:

*******************************************
To: bst2k@gmx.net
Subject: Suggestion for new features

First of all i have to say that BSPlayer is the best player for divx
i have ever worked with !!!
and i really think that if you just add one little feature, it will
become perfect:

"Frame droping when behind"

The term is from a feature that i found in VirtualDub 1.5.2 under
Options->Drop frames when behind. this option alow'ss slow computer
to watch movies with minimal impact. instead of reseting the correct
frame every keyframe (or whatever, i'm really just an end-user)
when not being able to catch up, it's skipping frames to catch-up
with the audio.
This feature is very important not just to slow computers but also
to comuters that run with a background task that functions in a
non-liniear fashion (slowingdown the computer every once and a while)

I found that sorten players are already implementing this feature
like Divx Player (the one that comes with the divx bundle) which i'm
sometime use for lack of choice when it comes to hi-res videos.
i should point out that "Windows Media Player" dosn't have this
feature and this alone greatly reduce it's value in my eyes.

*The reason i can't use the Divx Player (2.1) is because of it's
bad frames/corrupt file handling: at best it will simply stop
showing the video, at worst it will crush taking explorer with him
(forceing me to rerun it manually through the Task Manager
(ctl+alt+del) - lackly for me i'm using Windows XP, but just
imagine what kind of hell is coming down on Windows 95/98).

P.S: i'm no programmer but becouse that VirtualDub is an Open-Source
project,you can learn how they did it and implement it easly (i hope)
in BSPlayer; Can You ?

P.S.S: love the new Overlay option for the Subs in 493, i don't use
subs but when i use overlay my videos seem's to run better/smother !

Thankes for hearing me out ! :)

*******************************************

I didn't know about this fourm so i thought i should run here too.
i proberly won't be commenting on your responses but i will check theis
fourm every once and a while.

Got any suggestions ?

[tempost]

I just went through the VirtualDub code and i decided to give some more
info on just how Frame Droping workes.
becouse i'm no programmer but i do read C++ (a bit ) i will try
to avoide code issues and stick to theory:

As i understand, Frame Droping is depended on the audio~video synch;
when the program detects that the audio is frozen (the video takes to
long to decompress and the program can't go on with the video) the
program takes a few steps.
Becouse BSPlayer proberly already can detect bad frames and drop them,
it should already have the capabilty to detect frozen audio as part of it's
bad frame analysis (have i mentioned this programming stuff is not my
strong side ?).

Lets take the asumption that the frozen audio has been detected and all
is well up to this point;

the following is a qoute from VirtualDub code(//note):
"Attempt to drop a frame before the decoder. Droppable frames (zero-
byte or B-frames) can be dropped without any problem without question.
Dependant (P-frames or delta frames) and independent frames (I-frames
or keyframes) should only be dropped if there is a reasonable
expectation that another independent frame will arrive around the time
that we want to stop dropping frames, since we'll basically kill decoding
until then."

"around the time" should be configured by the user (edit box) and be
depended on the quality of the video and it's FPS rate + the decoding
quality (low quality in decoding means better preformences which means
drping less frames) + user Frame Droping Quality choice (if the user set
low quality then the program dropes a lot of frames).

but lets do what VirtualDub did and ignore all this nice calculatins and just
fix a constant of 2 frames to be droped and when needed jump to the next
keyframe/other independed frame?*.

Well i guses that is it, the frames are drpped the audio is synched to the
video and a slow computer can run hi quality videos with reasonable
quality.

*as metioned in the VirtualDub note, their are special independet frames
that should be handled diffrently, on this i won't go through becouse
i'm not an expert on divx or avi or any video compressin/codeing and
all i know is that if you want a video to be capable of handleing coruption
that is usaly found on removeable media and network connections then
you should use a lot of keyframes every half a second or so (so only that
segment of the movie will be impared).

P.S: i don't know if this is avilable but if their is a like VBR video
(keyframes only appear in scenes that are constantly changing and the
the colors are changing rapidly - action scince fiction stuff) then the 2
droped frames constant becomes very logical.

[Amalfi Marini II]

Actually, those 29,976 fps movies can be played at 23,975 (actually many software based DVD players plays DVDs at that framerate), if this feature can be implemented into BSplayer, I think a little improvement can be achieved in slow computers, but I don't think it will be that magical. Anyway, the tests will tell the truth, the difference between 29 and 23 is 21%, and only testing will tell if we will get a 21% + of performance. This would be a really good step, and adding more and more of little improvements will make a difference to what BSplayer is today.

[tempost]

VirualDub mailed me !!! :D :D :D

This is the full email:
SOF
*************************************
On Tuesday, May 6, 2003, 2:25:53 PM, you wrote:

> I used your code notes to explaine frame droping in the fourm of
> BSPlayer Suggestins to explaine the need and usefullnes of
incorporating this feature to the player (like the Divx Bundle
> Player).
> I havn't used any of your code, just your notes and the idea;

> I can't see any problems with it but i thought i should ask if
this
> is O.K with you ? ;)

Of course, although I should add a few points.

VirtualDub's tri-modal concept of independent, dependant, and
droppable frames is only useful for MPEG, which has I/P/B frames.
B-frames do not exist in AVI and as such the drop routine is much less
useful, as decoding can only be skipped for frames right before a key
frame. For a format with a commonly short interval, such as 5-15
frames, this can still provide a smooth drop rate up to around 20%,
which is likely enough. Obviously, it works just fine for a codec
that has no delta frames (Huffyuv).

Given a longer keyframe interval of 200 frames common in
high-compression codecs, however, and a pipelining window of 32
frames, the decoding engine must decode 168 frames before it can
perform an "known-delay drop." (DivX Pro can encode
B-frames if told
to, but these are hidden within delay frames in the AVI and as such
players can't tell they exist or take advantage of them unless some
serious hacking is done to the data before passing it to the decoder.)
Since MPEG-4 is a relatively low bandwidth but computationally
intensive codec, the bottleneck is almost always the CPU instead of
I/O or video output and thus the decoder not being able to drop frames
over a long interval is a big problem.

There are a couple of stages in MPEG decoding that can be ommitted if
a frame needs not be displayed, namely color conversion and
post-processing (adaptive smoothing). However, color conversion is
not necessary if hardware color conversion hardware is available --
which it is on all modern video cards -- and with post-processing,
you're better off just turning it off for all frames so fewer frames
need be dropped in the first place.

--

http://www.virtualdub.org
The latest version of VirtualDub is V1.5.1 (build 15654).

*************************************
EOF

Notes:

1.The email was from <phaeron at virtualdub dot org>. (The link has been scrambled to foil email harvesters.)

2.As you can see in the email their are a few notes/corrections about the
independent frames i mentioned i really don't fully understand.

3.Actully i forgot to point out that BSPlayer is
desinged primary for Divx so Divx being MPEG-4 was
a too avious detail for me to include.
so aviously all the conversation here is in context to MPEG/Divx.

[tempost]

I think you are suggesting a slightly simpler way of droping frames.

FPS reduction proccess:
1.Determining which frames can be droped.
2.Droping frames to reach Forced FPS.

Audio~Video Based FPS reduction/Frame Dropping:
1.Determining which frames can be droped.
2.Calculating how many frames are necessary to drop to reach
Audio~Video Synch.
3.Droping frames to reach calculation results.

While both ways drop frames, the Audio~Video way uses the computer
for reaching the best results + the Audio~Video way isn't limited to any
fixed amount of FPS (23/29) and thus reaches better results (a very slow
computer might need 20FPS while a medium computer might need 26FPS).

Never the less when developing the Audio~Video Frame Droping, the FPS
reduction will be a step for the ultimate goal of not involving the user in
such knowledge required tasks by leting the computer make the best
choice for him.

[tempost]

http://ndub.sourceforge.net/

Does it changes anything :?: