View Full Version : New ideas for MPEG2DEC3 or MPEGDecoder
bilu
5th January 2004, 01:13
Compiled from other threads, both ideas are interesting, and a new thread is good to compile other ideas around:
1) FILM hint for Telecide and others, based on RFF flags just like DVD2AVI does (idea by mf, http://forum.doom9.org/showthread.php?s=&threadid=68024);
2) MPEG-2 info useful for conditional filtering, like I, P and B-frames (idea by
scharfis_brain, http://forum.doom9.org/showthread.php?s=&threadid=68024). Something as useful as this:
XviD Stat file import plugin for AviSynth 0.90
http://forum.doom9.org/showthread.php?s=&threadid=68027
Best regards,
Bilu
spyder
11th January 2004, 18:37
The rff info would be nice :)
Kurosu
11th January 2004, 20:30
MPEG2DEC3 doesn't know every frame properties before decoding it (maybe the rff flags are already known but I have no interest in spending time decyphering CMPEG2Decoder::Open from vfapidec.cpp). Say your script looks like this:
function Translate (int a)
{
return (a == 1) ? "I" : (a == 2) ? "P" : (a == 3) ? "B" : "Unknown"
}
clip=mpeg2source("test.d2v", id=1)
ScriptClip(clip, "Subtitle(Translate(FrameType(id=1)))")
Now imagine FrameType returns the info it reads from the MPEG2Source object. Problem: from frame n, it is invoked before frame n is requested from MPEG2Source. ie: the info FrameType gives you for frame n from MPEG2Source is in fact for frame n-1. ie: on first frame, unknown is returned (because FrameType returns an uninitialized data).
Solutions:
1) force execution of the frame decoding before hand.
2) Have scriptclip have a switchable behaviour of requesting the frame n before evaluating (seems not to be the case yet)
For getting anything from MPEG2Source (or MPEGDecoder for that matter), I think 2 is the solution (as the exact same settings works for me once the proposed changed is applied to conditional.cpp) because it would fix any other problems where filters are expecting data from other filters in the chain.
If someone is interested in adding something, I suggest checking my work with those additionnal/modified files (http://kurosu.inforezo.org/avs/example.zip) (check interfaces class, how the object is stored in MPEG2Source constructor, and how the AVSValue function FrameType is made) from MPEG2Decoder source.
Note:
1) I'll be hardly available for explainations, so you are probably better starting from scratch
2) The simplest workaround is to use clip.trim(1,0) but that's unsatisfactory.
3) If you start using a lot of trims, I think it is better to write a plugin and D2V parser from scratch.
sh0dan
12th January 2004, 02:29
FrameEvaluate has a boolean modifier "after_frame=true/false" that will make FrameEvaluate execute the script AFTER the frame has been fetched from the filter above, if changed to true.
Since Scriptclip returns the value of the returned script it naturally cannot be executed after the filters above has been evaluated, since it itself is the script being evaluated.
The breakage of the non-linearity is a much bigger problem though, as many (temporal) filters will break the connection.
Kurosu
12th January 2004, 10:08
I don't see the difficulty in adding (and harmless, as further calls will just be caught by the the Cache filter - besides, what is the difference with a random access to the filter in any case?):
dst = clip->GetFrame(n, env);
before the try/catch block where the script argument is evaluated. Or was it working by pure luck ? Anyhow, having a filter inversing the natural flow from bottom to top is the neater solution, whichever it is.
sh0dan
15th January 2004, 18:41
There is a new CVS Binary up. It contains a new feature:
ConditionalReader (http://www.avisynth.org/index.php?page=ConditionalReader). This will allow you to input per-frame settings from a text file, that will be put into a variable, which is updated each frame.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.