PDA

View Full Version : SDK for making RTV files...


vojtek11
03-23-2005, 08:54 AM
Has anybody ever tried to make own RTV file using C/C++? I'm trying for some time to make a TGA->RTV converter. It seems that SDK distributed by Newtek is completely useless. Short manual says something about a set of functions. Those functions are not present in the header file. Functions available in header file are not available in library. Simple initialization :

RTVFile myFile;

causes several errors during linking (function not found).

Anybody know how to use it?

Thanks,
Vojtek

vojtek11
04-16-2005, 03:03 AM
I have a feeling that my questions are too heavy for VT-Script discussion. But the funny thing is - apparently they are too difficult for Newtek's support as well. Newtek has never ever answered any of my questions regarding SDK...

I'm wondering - does companies like Adobe or Discreet have a better resources provided by Newtek to write support for RTV files for some of their software? Because with SDK provided for public by Newtek You can do nothing. Completely nothing.

I realize that providing SDK is not an obligation for Newtek, but I would rather have no SDK at all to save time wasted on useless, lame documentation, millions of bugs and compatibility errors.

This is sad people. Just sad.

UnCommonGrafx
04-16-2005, 08:33 AM
Vojtek,
I can say without doubt that at least one person outside of 'The Fold' has written an rtv writer: Bob Tasa. So, it's not impossible. ;)

IF you are a coder, the examples in the sdk ought to get you where you want. Granted, the SDK could use a bit o'cleanup, it can get you what you want.

Good luck.

vojtek11
04-16-2005, 02:11 PM
I'm dying to see any of those "examples" You mentioned. I have both SDK - for VT3 i VT4 (I use VT3, but RTV library and specification is identical). It's true that for VT4 Newtek put more efforts in documentation, but it is still completely useless. All data that was put there is just copies of header files. Nothing more than that. And there is no single example with RTV implementation that would suggest any practical usage.

For a couple of days I'm trying different approach. Newtek mentioned that RTV coding is identical to uncompressed UYVY AVI file FourCC codec. Unless I'm doing something terribly wrong, I made dozens of those AVI files - all according to specification and NONE of them look like RTV. Skipping the file header, bytes describing frames are in completely different order. I'm losing hope... :(

John Perkins
04-16-2005, 02:28 PM
I wouldn't worry about this being the tscript forum, it's not used much and many of the people interested in tscript are in need of C even if they don't know it yet.

I'm in a similar position after having given up repeatedly. I've made RTV work in the past, but I always get frustrated with the SDK. Right now I'm more interested in adding missing functionality in tscript and GUI's for my own plugin apps.

I talked to Aussie last week and he's interested in getting some kind of chat going for people like us to exchange ideas and help. I'll talk to him at the party tomorrow.

I'll gladly work with you to help us understand this SDK.

Email me at jeperk@gmail.com and I would love to compare notes.

John Perkins
04-16-2005, 02:32 PM
BTW, there are no examples in the VT4 SDK and many of the older examples work once or twice then lock the VT.

Something changed because they worked on VT2 and I think VT3.

The current SDK for download is missing some header files and also doesn't fully work with VC7 (.net) but NewTek has one that does.

They really need someone to focus on devs so that they get more third-party support. It sure didn't hurt the Amiga Toaster.

John Perkins
04-16-2005, 07:24 PM
Here is how I have made RTV files. It is based on the output with alpha example from the VT3 SDK so that I have something to write and a preview.

My changes are in //------------------------------------ comments in three places.

I've also attached the file because I don't know how to keep the formatting in the forum. Rename it to .cpp (can we please be allowed to upload .c, .cpp, .h, .toast,etc?)

Oh yeah, don't forget to change the filename in the create file header, write fields and close sections.

Hope this helps somewhat. Just replace my checkerboard with your frame from an AVI.

P.S. - I forgot to set HasAlpha to true in the header since I decided to write an RTV with alpha. It works either way though.


//******************************
// (c)2000-2003 NewTek, inc.
// All rights reserved.
//******************************

//************************************************** ************************************************** *********
// This example shows how to send BGRA frames to the VideoToaster card.
// This could be accelerated drastically by :
// (1) Using UYVY natively to render frames
// (2) Using YUVA to render frames, this the conversion to UYVY is very fast.
// (3) Render alpha into the output buffer instead of the BGRA image
// For any help at all with this example, email across@newtek.com

//************************************************** ************************************************** *********
// include all the standard windows stuff
#include <windows.h>
#include <stdio.h>

//************************************************** ************************************************** *********
// The VTNT include files that are required
#include <newtek/hubmedia.h>
#include <newtek/hubmedia_protos.h>
#include <newtek/newtekrtme_protos.h>
#include <newtek/beethoven_protos.h>
#include <proof/proof_lib.h>
#include <newtek/comp_convert.h>
#include <newtek/vid_d1.h>
#include <newtek/nt_tools_protos.h>
#include <newtek/rtme_hub_names.h>
#include <rtvlib.h>

void main(void)
{ // In PAL ?
bool PalOutput=false;
bool HasAlpha=true;

// PAL resolution : 720x576 even field first
// NTSC resolution : 720x480 even field first
// NTSC resolution : 720x486 odd field first
unsigned CurrentXRes =720;
unsigned CurrentYRes =PalOutput?576:486;
unsigned CurrentYRes_Field =CurrentYRes/2;

// Create the output
RTMEOutput *MyOutput=rtme_output_Create( "Yo",0,0,
(PalOutput? RTME_OUT_CREATE_VID_IS_PAL:
(CurrentYRes==486?RTME_OUT_CREATE_VID_IS_NTSC_486: 0)
)|(HasAlpha?RTME_OUT_CREATE_HAS_ALPHA:0)|
RTME_OUT_CREATE_NO_AUTO_SELECT // Do not automatically select myself onto program row !
);
if (!MyOutput) throw "Error! Could not create the output.";

// Its useful to have one of these lying around since it allows us to access the T2 virtual switcher
SwitcherClient *sc=switcherclient_Create(NULL);

// We are going to allocate BGRA buffers
byte *BGRABuffer=(byte*)malloc(CurrentXRes*CurrentYRes* 4);

// See the note about this below.
//rtme_output_SetMaximumLeadTime(MyOutput,4);

//------------------------------------ Create a new RTV file and write the header info ------------------------------------------------

// Step 1) Create a file header
bool MakeRTVHeader = BuildRTVFile( "S:\\MyRTVFile.rtv",
CurrentXRes, // (Valid entries 720)
CurrentYRes, // (Valid entries 480,486,576)
true, // bool HasVideo
false, // bool HasAlpha
false); // bool HasAudio - always false
if (!MakeRTVHeader) throw "Error! Could not write RTTV header.";


// -------------------------------- End Create RTV File ----------------------------------------------------------------------------------------


// Create some frames of an animation on the DSK
for(unsigned i=0;i<200;i++)
{ printf("Frame %d\n",i);

// Fill in the buffer with something
// This is some junk I made up !
byte *Scan_BGRA=BGRABuffer;
byte R[2]={ 0,0 };
byte G[2]={ 0,0 };
byte B[2]={ i/2,i/2+128 };
byte A[2]={ 0,255 };
for(unsigned y=0;y<CurrentYRes;y++)
for(unsigned x=0;x<CurrentXRes;x++)
{ Scan_BGRA[0]=B[(((x+i)/16)^((y+i)/16))&1];
Scan_BGRA[1]=G[(((x-i)/16)^((y+i)/16))&1];
Scan_BGRA[2]=R[(((x+i)/16)^((y-i)/16))&1];
Scan_BGRA[3]=A[(((x-i)/32)^((y-i)/32))&1];
Scan_BGRA+=4;
}


// We now get a buffer from the RTMEOutput queue. You can create these as fast as you want
// they are queued up on output and sent so that no frames are dropped. This allows you to
// simply run as fast as you want and not worry about timing. If you wish to stop the actual
// rendering of BGRA frames to run to far ahead of the output, you can comment in the
// rtme_output_SetMaximumLeadTime call above. Note that we should have this inside a loop
// because if we run to far ahead of output it will return NULL.
void *pbuf;
long size,bufferID;
while(true)
{ bufferID=rtme_output_AllocFrame(MyOutput,&pbuf,&size);
if (bufferID) break;
Sleep(10);
}

// We get the individual fields
long Dummy;
byte *Video_Field0=(byte*)rtme_output_GetFrameFieldBuff er(MyOutput,bufferID,&Dummy,0);
byte *Video_Field1=(byte*)rtme_output_GetFrameFieldBuff er(MyOutput,bufferID,&Dummy,1);
byte *Alpha_Field0=(byte*)rtme_output_GetFrameAlphaBuff er(MyOutput,bufferID,&Dummy,0);
byte *Alpha_Field1=(byte*)rtme_output_GetFrameAlphaBuff er(MyOutput,bufferID,&Dummy,1);

// We now simply fill in the buffer. Note that the code below is relatively generic and should
// get the field orders correct for all supported Toaster types and resolutions. The order is
// such that it should be CPU cache friendly.
byte *SourceLine=BGRABuffer;
for(y=0;y<CurrentYRes;y++)
{ // Which field are we on ?
byte *VideoFieldToUse=(CurrentYRes==486)?((y&1)?Video_Field0:Video_Field1):((y&1)?Video_Field1:Video_Field0);
byte *AlphaFieldToUse=(CurrentYRes==486)?((y&1)?Alpha_Field0:Alpha_Field1):((y&1)?Alpha_Field1:Alpha_Field0);
// Handle the Alpha line
if (VideoFieldToUse)
{ // Move to the beginning of the video output line
VideoFieldToUse+=(y/2)*CurrentXRes*2; // Note that UYVY has 2 bytes per pixel
// Use our special MMX functions
encode_bgra_ycbcr8(VideoFieldToUse,SourceLine,Curr entXRes);
}
// Handle the alpha line
if (AlphaFieldToUse)
{ // Move to the beginning of the alpha output line
AlphaFieldToUse+=(y/2)*CurrentXRes;
// This is abour as fast as is possible, no need for assembly here, the compiler does a good job
byte *BGRA_AlphaScan=SourceLine;
byte *AlphaFieldToUseEnd=AlphaFieldToUse+CurrentXRes;
while(AlphaFieldToUse<AlphaFieldToUseEnd)
{ AlphaFieldToUse[0]=BGRA_AlphaScan[3];
AlphaFieldToUse[1]=BGRA_AlphaScan[7];
AlphaFieldToUse[2]=BGRA_AlphaScan[11];
AlphaFieldToUse[3]=BGRA_AlphaScan[15];
AlphaFieldToUse+=4;
BGRA_AlphaScan+=16;
}
}
// Increment the source buffer position
SourceLine+=CurrentXRes*4;
}

// --------------------------- Write the fields to our RTV -----------------------------------------------------------------------

// Step 2) Write any number of frames into the file using
bool MyWriteRTV=WriteRTVFile( "S:\\MyRTVFile.rtv",
i, // FrameNo
Video_Field0, //void *Dest_Field0,
Video_Field1, // *Dest_Field1,
Alpha_Field0, // *Dest_Alpha0,
Alpha_Field1, //*Dest_Alpha1,
NULL, // *Dest_Audio, It is not recommended that you use this parameter
false);// SendToToaster=false This is not supported, it remains for compatabily


// ----------------------- End Write the fields -----------------------------------------------------------------------


// Now simply send the frame to the output !
rtme_output_SendFrame(MyOutput,bufferID,size);

// Once the first frame is ready we can select ourselves onto the actual output
if (i==0)
{ // Wiat for the first frame to have definitely been delivered !
// THis is a hack. I will find a neater way to do this.
Sleep(1000);
// We need to enable the DSK
long DSKEnabled=1;
switcherclient_SetSwitcherParam(sc,RTME_SWIT_DSK_E NABLE_CHILD_NAME,SVT_LONG,&DSKEnabled);
long DskAlphaFade=255<<16;
switcherclient_SetSwitcherParam(sc,RTME_SWIT_KEYBA R_POSITION_CHILD_NAME,SVT_LONG,&DskAlphaFade);
// Select myself onto the DSK
long MySwitcherRowNumber=rtme_output_GetSwitcherInputNu mber(MyOutput);
switcherclient_SetSwitcherParam(sc,RTME_SWIT_INPUT _DOWNKEY_CHILD_NAME,SVT_LONG,&MySwitcherRowNumber);
}
}


//------------------------------------------ Close the RTV file --------------------------------------------------------------

bool CloseMyRTV = CloseRTVFile( "S:\\MyRTVFile.rtv" );
if (!CloseMyRTV) throw "Error! Could not close RTV.";

//---------------------------------------- End Close RTV -----------------------------------------------------------------------------


// Free the BGRA buffer
free(BGRABuffer);

// Close the output
rtme_output_Delete(MyOutput);

// Close the switcher client since I no longer need to access switcher stuff
switcherclient_Delete(sc);
}

John Perkins
04-17-2005, 04:19 AM
It turns out that half of the SDK is missing from the NewTek download...

The installer currently says it is version 5432 on the website and the correct one is 5522 or newer. You have to check the first time it says a version number because the second time they both say 5432.

I'll ask about hosting the updated version temporarily until they get it updated.

inquisitive
05-18-2005, 03:22 AM
It turns out that half of the SDK is missing from the NewTek download...

The installer currently says it is version 5432 on the website and the correct one is 5522 or newer. You have to check the first time it says a version number because the second time they both say 5432.

I'll ask about hosting the updated version temporarily until they get it updated.

I jus downloaded the SDK it says its version 5432 and i do not see any type of documentation, not text files nor html files? did i download the old sdk? or has it been updated and not yet linked?

vojtek11
05-18-2005, 03:33 AM
Yes. The SDK put by Newtek is incomplete. I've send them an email about it couple of weeks ago. As usual - completely ignored. Newtek is SO lazy or lame. I don't know which one - pick Yourself.

PeteF
05-20-2005, 11:35 AM
Sorry this is happening to you. Bob Tasa wrote and RTV plugin that worked with Premiere 6 and the VTNT format (before Toaster Edit was written), and it was a godsend. PPro was a different beast altogether, and I believe the ASIO audio requirement (which the newtek card is not complaint), prevented him from updating it. I had to render to an avi from that point on.

HD is todays reality, and so RTV is a mute point for me, so long as the VT remains in SD land. NT is all for having folks creating plugins for LW, just not sure why they are not as cooperative in the VT camp. Maybe the VT is taking a new direction, a.k.a. the Tricastor, and RTV is just not worth the effort? Not sure. Then again, changes are happening, and the VT will be updated to handle HDV rez, so then the RTV requirements will change anyhow? Still, their lack of responding to you in any shape or form is disheartening. Even if it's just a simple "Sorry, changes are in the works, and we'll get back to you.." even, "No", or words to that effect would be somewhat respectful.

NT is playing the role of caution these days. Keeping hush. Maybe you should call them directly, as email is regarded as legal and binding these days.