View Full Version : pseudo avi codec ->avisynth
boyer98
9th April 2003, 10:21
Many programs (studio8 by pinnacle, Vegas by sonic foundry...) can’t export to mpeg2 directly with great quality; they can only export to avi. Why doesn’t build a “pseudo” avi codec that make a dummy avi file but sends data to a frame server like avisynth? I imagine something like premiere plug-in but using by all programs.
Boyer98
lamer_de
9th April 2003, 10:44
please search. This topic has been discussed before.
ATM, the only way to do it is to use VFAPI. There is some development on ffvfw aswell, but according to DDogg it's not fully working atm. Have a look inthe NLE forum, it's all explained there.
CU,
lamer_de
sh0dan
9th April 2003, 11:30
@boyer98: As lamer suggests - use search - Conclusion: It is simply not possible. Every app. need a specific export plugin.
@lamer_de: VFAPI is the other way around - AviSynth -> Pseudoavi -> Some app. Same goes for ffvfw.
lamer_de
9th April 2003, 13:08
doh, I should learn to read. i guess I only read Premiere avi avisynth and my mind made upo some story out of his own. Sorry for that. nonetheless, the other way round has been discussed aswell ;-)
CU,
lamer_de
DDogg
9th April 2003, 14:13
SatishKumr, (http://www.debugmode.com/) is working on the problem of frameserving from Vegas. From what he has said to me, he thinks he has a workable solution but is hung up waiting on information about Vegas internals from SonicFoundry.
I know he knows his stuff (see his bio)because as an experiment he was able to whip up a render codec (in just a few hours) that allowed a rudimentary level of serving to VirtualDub. He did not think that was worth pursuing because of the lack of frame-seeking capability.
Let's just keep our fingers crossed.
boyer98
10th April 2003, 07:16
the problem is:
genereric video application->pseudo codec frameserver->avisynth
There is a solution? I don't find a generic one.
Thank you
Boyer98
DDogg
10th April 2003, 13:56
boyer98, this may be an example of the blind leading the blind so take it for what it is worth.
You question and thought is not as simple as it may seem to you. I wish it were. The way I understand it, it is impossible to have two way communication/frame-seeking ability in such an "export" codec.
I actually have a very rough test version of something like this on my machine that SatishKumr wrote as a quick test exercise. It does allow any program that can access a VFW codec to attempt to frameserve. The problem is it is not practical because of the frame-seeking problem, or maybe another way to put that is the communication problem.
The only thing it will work with is VDub as long as you do not attempt to seek or even breath hard on it. Any program that interrupts the pure stream from the serving codec by way of closing or re-opening the file or anything that needs a frame-number will cause it to fail. The codec has no way of error checking. In other words, it has no way to communicate with the receiving application. All it can do start serving when the first frame is requested and keep on serving until the last.
What does that mean? Well, any encoder that does a two pass would fail. TMPG fails, even on a one pass, because I am told it closes and reopens the input file for some reason. It seemed every application we tried had some behavior that caused a failure.
Maybe somebody that actually understands the guts of the problem could explain it better and with more detail. Hopefully the above is enough for you to get a general feel for the complexity of the problem, at least as I understand it.
Belgabor
10th April 2003, 20:38
Well, if I understand it corretly it could be easily described as a push/pull problem. If you write a codec to frameserve, the 'encoding' app would push frames into it, while the client app would pull frames, so seeking aside, the whole problem is how a 'encoding' app can cope with being delayed till the client app starts pulling frames.
Hope this makes some sense ;)
Atamido
11th April 2003, 01:34
It sounds like this would be much more feasible if you were using a DShow codec. I think DShow supports push/pull methods from both sides, so you could be a little more flexible with the frameserving. Imagine just inserting a frameserving codec into a DShow graph and frameserving to VDub. Somebody has probably done this before.
vhelp
11th April 2003, 01:44
Hi Belgabor..
You pretty much described what I'm looking for.. to learn how to
create a "frameserver" app. ie, say I write an app..
* that opens an AVI source
* bla bla bla code, then
* take my AVI source from my app, and
* feed (frameserve) it into an encoder app ie, TMPG or CCE for ie.
myclip.avi --> myApp[myclip.avi] --> frameserved --> TMPG
Just like:
myclip.avi --> AVIsynth[myclip.avi] to myclip.avs --> frameserved --> TMPG
Do you (or anyone else) have any suggestions on some good pointers
or web links to check out and study on this some more ??
I would really appreciate any assistance on this. For now, I am
currently sifting through the search, which found 70 matches
on: "create a frameserver"
** ("frameserver" retuned 509 match :eek: ) Ouch!!
Thanks for any leads.
-vhelp
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.