VFR for Fansub Encoders - how, why, WTF?

[dj_tjerk]

Well.. i started wondering about vfr too, especially about overlayomg afx stuff (mostly kara's). Isn't it possible to dublicate frames in the OP or ED to reach that certain maximum framerate (or just the framerate you output the AFX clip in), overlay the AFX clip, and then remove the duplicates again (sounds weird, probably is).

And in case of NTSC source, to do the same but somehow output interlaced video out of AFX (wonder how i do that.. )

[TheFluff]

Well, I've been thinking about it and it's really not all that funny. As long as you're only doing signs, you'll be fine with the aforementioned way (ignoring the VFR and using a plain AVI), but the really funky stuff is, again as mentioned, AFX karaoke. You basically have three options (that I know of, if you can come up with more please do tell) if you want to do this:

1. Make the the video section you are applying the karaoke to CFR, at least "locally" so to speak (which means, no framerate changes during the karaoke).

2. Go 120fps for the AFX workraw, and by 120fps I mean 120 CODED FRAMES per second (URGH and BLEH), and then decimate section-wise manually. This pretty much explains itself, but it's mindnumbingly stupid. If you have other framerates than 23.976 and 29.97 (no, except if you want to preserve WMV's dedup-ness) you get to have lots of fun finding the appropriate framerate (Hint: The framerate you end up choosing for the AFX workraw will have to be evenly divisible by all framerates you're planning on using. There's a mathematical term for this but I don't know it in English at the moment because I'm tired and stupid).

3. Time the karaoke in Aegisub and export it with timecode conversion for VFR hardsubbing on. Then import it into AFX and do your normal thing, and hardsub as usual, pretending nothing is wrong. This is a theoretical solution I thought of a couple of days ago, and I haven't tested this at all. It's quite possible (read: very likely) that it will look kinda funky around framerate changes. It's also possible that it won't work at all.

And since I've never ever used AFX I have no idea what it does or doesn't do with interlaced video. I am, however, firmly convinced that interlaced video is an evil abomination that needs to die.


Edit: Martino, your program could potentially be useful for some extremely rare broken WMV raws that have their timecodes shifted by one frame for some inexplainable reason. Last time I poked at one I ended up writing a perl script to fix the timecodes file...

[martino]

What I had actually intended that program for was for, well, I'll give a practical example in a more simplified approach (but yeah, I guess what you wrote there could be a possible way of using it too);

Where the episode would for example be of the format OP-ED-ED and you wanted to use AFX karaoke for the OP (for now I'll assume that the ED won't need karaoke).
First you would cut out the OP from the 119.88fps raw and decimate it by 4 to get a 29.97 cfr section in order to be able to overlay AFX on it.
Then you would cut out the EP+ED section from the raw without decimating it, and afterwards running it through avi2cfr to obtain the decimated "vfr" avi and timecodes.
But now if you want to join them together the timecode isn't correct, because it doesn't take into account the fact that there is another section placed before it. So that's where my program would allow the user to shift the frames in order to reflect the changes.
Then you just overlay, encode and mux.

Anyway, this was my line of thought which made me write the program. Also, I haven't seen something that would have done the same so I decided to go forward with it. Plus it's not like everyone knows how to write a script/program that would do something like (it took me some time to figure out how to do it). I know where I could use it, and hopefully will, but as I said in my post I wonder as to whether people would actually find it useful or whether it's another one of those useless applications...

P.S. Also, what if you wanted to add notes at the start, that would require a shift as well, right?

[Quarkboy]

Originally Posted by Mentar

Quarkboy, you really don't want to toy around with tdecimate() on stuff like this. If you want to force CFR for your target, Nicholi's solution is BY FAR the most reliable and simple method to do it.

If you want to keep the VFR alive, transform the source to lossless avi and extract the mkv timecodes. With Aegisub you have a reliable tool for typesetting and timing in VFR environments without problems. And AFX really doesn't care about what framerate the video actually is, so you can easily work on the lossless avi (which is CFR by definition) regardless of the fact that when remuxed with the timecode file it turns VFR again.

Things have become really convenient today. The old times when you had to painstakingly write timcode files by hand are long gone

The simple Directshow solution introduces a huge amount of jerkiness to pans.

A better solution I found was to first adjust the "default-duration" in the mkv itself to 1/29.97 s and then use directshowsource converting to fps=119.88. Then I do a standard 119.88 fps->23.976 fps decimation with tdecimate, which makes it much smoother.

And there's really no reason to use vfr for a show which is completely animated at 24 fps (only a few transitions in the opening and ending are at 30 fps).

[dj_tjerk]

Well, i've done some thinking again, and come up with a little question: what is the lowest possible framerate in an OP or ED. If the karaoke is flashy (or not even that flashy), adapting it to that framerate would make the kara itself very shocky.

Now for that converting the whole OP or ED to cfr, is that so much work to do? Like, a lot of work to do by hand? I guess with an extension to that InsertSign function it should be somehow possible, with setting extra parameters, to rewrite the timecodes file and decimate either the karaoke or the OP/ED to a certain framerate.

And for outputting vfr out of AFX, i don't know if it's really possible, but having a project, loading a timecodes file (with the framenumbers adapted to frames of OP/ED, first frame is 0 and so on) with a script in AE, which then uses the timewarp function on a composition to change the speed. I don't know how well that timewarp stuff works in AE, if it's still shocky or what, but it should work when you output the video to a cfr clip and then use overlay. (I hope every episode has the same framerates then, cause rendering some kara's over and over again ain't that much of a pleasure, except if you prerender it. But then, using timewarp then would be the same as decimating it)

Now I'm not an encoder, so I would like to know what's the best solution here (from the above maybe ;P)

[Devastator]

Originally Posted by TheFluff

2. Go 120fps for the AFX workraw, and by 120fps I mean 120 CODED FRAMES per second (URGH and BLEH), and then decimate section-wise manually. This pretty much explains itself, but it's mindnumbingly stupid. If you have other framerates than 23.976 and 29.97 (no, except if you want to preserve WMV's dedup-ness) you get to have lots of fun finding the appropriate framerate (Hint: The framerate you end up choosing for the AFX workraw will have to be evenly divisible by all framerates you're planning on using. There's a mathematical term for this but I don't know it in English at the moment because I'm tired and stupid).

Up to my knowledge, AFX only allows compositions with up to 99fps. If there is a way to create one with a higher fps, I wouldn't mind knowing. I believe you mean 'lowest common multiple' for the last part (ie. LCM(3,4,5,8) = 2 x 2 x 2 x 3 x 5 = 120 -- take the factors and throw out common ones, ie. 4's factors are 2 and 2, 8's are 2, 2 and 2, so you only need 3 2's).

[Nicholi]

Converting the OP/ED, or the whole episode itself, to CFR is quite an easy task. If you actually had a VFR OP/ED though and wanted to use AFX karaoke the easiest thing in my mind would be to just split up the segments. Anime typically comes in two flavors of framerates, the common 23.976fps and less common 29.970fps. Usually if anything I've found the entire OP is either one of those or the other. But sometimes it could of course happen that most of it is 23.976 and a few scenes are 29.970. In that case just separate the OP into those pieces and work on them accordingly.

I'm not an AFX user and I wouldn't know if you could just simply slow down/speed up the AFX within one AVI for the different zones of framerates. But that is essentially what you need to do, 29.970 plays faster then 23.976. If you had a transition to worry about, it would need to play faster there.

[dj_tjerk]

What options does avisynth have to convert framerates then? That would be a lot easier, as encoders know what they're doing, and karaokers usually don't when they're playing around with vfr.

Basically the options AFX has for timewarp:

Whole Frames Duplicates the last frame shown.
Frame Mix Creates a new frame by interpolating existing frames.
Pixel Motion Creates a new frame by analyzing the pixel movement in nearby frames and creating motion vectors.

Where 'Whole frames' is by far the most beautiful one or pixel motion with 'based on one frame'. Otherwise the effect really is the same as blending, with weird alpha/shadow/watery like effects.

Of course you can do timewarping for the source video too (basically the same for AE), but I don't really see the advantage of doing that instead of creating a cfr raw.

--EDIT
Seems I was wrong that only timewarping was an option, putting an 23.976 comp into a 99fps one or whatever, will give you perfect motion, except for video that is. But every layer that is rendered will go smooth (so it seems, text layers do it and so does trapcode particular). So now two questions remain, does overlay keep the framerate in mind (or does it overlay a frame with a frame), and do the OP/ED always have the same framerate (not constant, but always the same vfr)?

[martino]

Originally Posted by Nicholi

Converting the OP/ED, or the whole episode itself, to CFR is quite an easy task. If you actually had a VFR OP/ED though and wanted to use AFX karaoke the easiest thing in my mind would be to just split up the segments. Anime typically comes in two flavors of framerates, the common 23.976fps and less common 29.970fps. Usually if anything I've found the entire OP is either one of those or the other. But sometimes it could of course happen that most of it is 23.976 and a few scenes are 29.970. In that case just separate the OP into those pieces and work on them accordingly.

Actually I have seen 19.98fps (119.88/6) section as well, but only once or twice and that was during the actual episode...

[Nicholi]

I think you are a little bit confused on what is actually happening to the video with overlays and fun...as well as VFR. So I'll try to explain as best I can

Avisynth Fun:
AssumeFPS - simply tells the video to run at a new framerate. Framecount is constant but the duration is changed. The exact same video is just told to play faster/slower.
ChangeFPS - changes the framerate by removing or adding (through duplication) frames. Results in a different framecount, but the duration will be unchanged. This is similar to what Decimate filters do.
ConvertFPS - changes the framerate by blending frames together. Instead of straight deletion/addition, new frames are created from neighbors and removed frames are blended into neighboring frames. Results in new framecount, duration is again unchanged.
DirectShowSource("blahfile",convertfps=true,fps=nu mber) - Uses convertfps while loading a file through DirectShow. Most notably used to load VFR content (120fps AVIs are NOT VFR content) and encode to CFR.
SelectEvery() - A simple way to decimate 120fps AVIs to result in CFR content. SelectEvery(4) for 29.970 and SelectEvery(5) for 23.976.

Those are essentially all the things in AviSynth which could mess with framerate, however you will normally find an encoder only using DSS, SelectEvery, or a normal Decimate filter.

When you overlay video in AviSynth it is frame by frame. Thus the video you are overlaying to (call it the source) and the overlay video itself (call it the AFX video) must have identical features. That means the resolution must be the same, the framerate must be the same, and at the time of overlaying in the avisynth script the colorspace must be the same (RGB). So you would not be able to overlay 99fps AFX video to a 23.976fps source video. You would have to decimate down the AFX video to 23.976 (which would cause it to look jerky because of missing frames) and then it could be overlayed.

The point I meant about "warping time" is that if you could you would warp the specific segments which are playing at a different framerate then the overall episode.

Ex.
If you aren't encoding from 120fps AVI madness, this could possibly be alot more work but the same result in the end. Jpn cappers are never consistent and never do things according to a standard, so who can say...it might even be easier if they capped with MKV and used normal timecodes. So I'm only thinking of the most common 120fps AVI situation. You have a 120fps video with an OP that has two 29.970 ranges, the rest of the OP is 23.976. I am assuming you plan to encode to VFR because you keep mentioning it (if its just CFR as the FINAL output, that is extremely easy and I'm just confused by your posts :P). Next you would load up an AVI script twice with SelectEvery(4) and (5) to locate the frame ranges where the framerates change. The next will just be random numbers to show you the point of how it all fits together in the end.
0-500 23.976
701-1000 29.970 (the framecounts are different because this is trimming at a different framerate)
901-1250 23.976
1501-2000 29.970
1751-2000 23.976

Then you would load up the final script like this.

24 = AVISource("Blahfile",audio=false).SelectEvery(5).AssumeFPS(23.976)
30 = AVISource("Blahfile",audio=false).SelectEvery(4).AssumeFPS(23.976)

24.Trim(0,500)++30.Trim(701,1000)++24.Trim(901,1250)++30.Trim(1501,2000)++24.Trim(1751,2000)

Now you have the OP all in one file with the different framerate segments preserved. You could do the above but instead of trimming them together, separate each range into its own AVI and make an overlay per range. Thats what I was originally referring to by separating them. However since we are talking about this mystical time warping idea, I think, it would possibly be much easier to deal with just one overlay.

So now the video could be loaded into Adobe Effects/whatnot, and you know visually (as well as by frame number) which scenes/ranges/areas are a different framerate. So you will work on the 23.976 ranges as usual, however for the 29.970 ranges you know that in the final output they will be playing at a faster rate then normal. So the "effects" will actually need to be slower then in the 23.976 ranges, so that when the final output is played the speed in the 29.970 range will match that in the 23.976 range. However at this point you won't be able to just time the audio to the video because it will be completely unsynced, unless you can have Adobe understand to play specific segments faster then the rest. If that can be done, then you do all the normal work, overlay the video, and finally mux with your timecodes. Which would look something like this

# timecode format v1
Assume 23.976
501,800 29.970
1151,1650 29.970

Followed by whatever other weird junk you might have to do in the episode itself and the ED which involves VFR. And your done. I'm betting Adobe can't do any of that magic though, and it would be easier if you just separated the segments completely and made an overlay for those specific segments. Also unless you are working closely with the encoder, and he knows what you are doing and is familiar with working with VFR...this could turn out disastrous n_n.

@martino
Well we all know 19.98fps anime doesn't exist , so as usual error on the part of the capper.

[dj_tjerk]

Well, that explained it quite a bit for me, but I try avoiding those 120fps avi's, they ugly.

The most easy option would be to let the insertsign function open the timecodes file and then decimate the karaoke according to it. The only problem you will then encounter is scene changes e.t.c. that don't overlap quite well. (I overlayed a 99 fps clip converted down (changefps, convertfps doesnt want to go any lower than 66fps then) to 23.976 on a clip of 23.976 fps and it something moved away off the screen 1 frame too late, maybe you wont have it with less of a framerate change).

Spitting out vfr (cfr but with slow down/speed ups according to the timecodes file) with AE by using timewarp is basically the same as using change- or convertfps. Indeed, it would be possible to just cut the kara into pieces and render those. Maybe the best solution but most time consuming.

I tried overlaying that 99fps clip too without changing the fps ,and it seems that it just overlays 1 frame of the base layer with 1 frame of the overlay, and keeps the framerate of the base layer, so nothing special there.

'Interpreting' vfr footage is possible in AE with timewarp (that when you play it audio and video keep in sync), but you will then again just be exporting cfr out of it (no extra frames in the higher fps zones which are speeded down with timewarp, or less frames in the sections with a lower framerate than your comp framerate).

On a side note:
Is it any use to convert cfr anime into vfr? I had like 400 frames less on 33000 frames, but most sections were ~10 frames with 19.18 fps.

[martino]

Originally Posted by Nicholi

@martino
Well we all know 19.98fps anime doesn't exist , so as usual error on the part of the capper.

Guess that makes sense, with the kind of RAW that I was working with...lol

dj_tjerk: As Nicholi explained a while before, anime doesn't come at any other framerates than 23.976 and 29.97, so that strange number 19.18...well, a capper's error? I guess...

From my perspective I don't see any advantage in encoding CFR anime into VFR. Let's just say that it's all done it 23.976, but there are only a few duplicate frames , I believe that going into the trouble of VFR is a bit overboard. You wouldn't be really getting rid of that many frames,
---PAUSE---
I'm not sure whether what I said above is actually right, I mean if the anime is done at 23.976, there wouldn't be any duplicate frames since you can't go any lower when it comes to the actual animation, or would there?
/me is still a n00b
---RESUME---
and how much is one duplicate frame, 8 bytes (I think it was mentioned somewhere earlier)? So for example with 400 frames you would save 3.125KB...which is more-or-less nothing.

[dj_tjerk]

Because I had nothing better to do I wrote this little script for AE that splits a renderqueue item in many segments. Of course it's a sucky solution to the problem of overlaying cfr over vfr, but it works (although I'm not even sure of that, lol).

Anyway, I think I documented it quite well, (just try running the script in an empty project) so there is no reason _not_ to share it. Maybe someone actually thinks it's useful. What it eventually spits out are many avi's which can be joined into an mkv, which then can be overlay()ed.

[Gkatzos]

Hi everyone. I am a newbie so be gentle.
I want your opinions on a timecode file. The video is the main episode of Naruto Shippuuden 004 (wmv 119fps). I just want to have a cfr video (the timecode file is only for figuring out what the hell is hapening with the video), either 23.976 or 29.970, with the less quality loss.
kore...

Spoiler for Timecode:

# timecode format v1
Assume 29.970030
5,240,23.976024
246,249,23.976024
290,293,23.976024
299,394,23.976024
590,629,23.976024
635,638,23.976024
659,678,23.976024
744,767,23.976024
818,821,23.976024
832,835,23.976024
846,853,23.976024
859,862,23.976024
873,876,23.976024
882,885,23.976024
916,919,23.976024
935,938,23.976024
954,961,23.976024
1017,1020,23.976024
1036,1039,23.976024
1045,1048,23.976024
1054,1057,23.976024
1148,1151,23.976024
1162,1165,23.976024
1181,1208,23.976024
1214,1281,23.976024
1417,1424,23.976024
1430,1573,23.976024
1654,1673,23.976024
1684,1703,23.976024
1734,1745,23.976024
1756,1763,23.976024
1799,1806,23.976024
1812,1815,23.976024
1826,1829,23.976024
1920,1927,23.976024
1933,1960,23.976024
1966,1977,23.976024
2008,2011,23.976024
2027,2030,23.976024
2036,2039,23.976024
2055,2058,23.976024
2109,2132,23.976024
2143,2146,23.976024
2157,2160,23.976024
2166,2217,23.976024
2298,2305,23.976024
2316,2375,23.976024
2386,2393,23.976024
2409,2412,23.976024
2433,2492,23.976024
2508,2523,23.976024
2534,2537,23.976024
2543,2546,23.976024
2557,2560,23.976024
2566,2569,23.976024
2580,2583,23.976024
2589,2592,23.976024
2603,2606,23.976024
2612,2615,23.976024
2626,2629,23.976024
2640,2675,23.976024
2681,2740,23.976024
2846,2849,23.976024
2855,2942,23.976024
3113,3148,23.976024
3154,3161,23.976024
3167,3186,23.976024
3202,3209,23.976024
3225,3232,23.976024
3318,3321,23.976024
3327,3334,23.976024
3340,3363,23.976024
3369,3380,23.976024
3501,3516,23.976024
3522,3541,23.976024
3547,3550,23.976024
3556,3559,23.976024
3640,3647,23.976024
3668,3671,23.976024
3677,3680,23.976024
3686,3709,23.976024
3715,3722,23.976024
3733,3736,23.976024
3757,3776,23.976024
3782,3793,23.976024
3804,3807,23.976024
3913,3952,23.976024
3963,3966,23.976024
3987,4146,23.976024
4162,4181,23.976024
4187,4234,23.976024
4240,4251,23.976024
4257,4276,23.976024
4282,4421,23.976024
4452,4455,23.976024
4476,4479,23.976024
4485,4492,23.976024
4498,4501,23.976024
4507,4530,23.976024
4536,4559,23.976024
# Total Frames: 4563

Kind of scary at first glance.

In virtual dub i figured that the 29.970 framerate exists not only in scenes with action but in still ones too. I decimated the video bothways and the result was more or less the same. I just want to listen to your advice and learn something usefull about these teenage mutant hybrid 119fps videos and how to cfr them
Thanks in advance, you are a great help anyway.

[martino]

Well, if you want to CFR something, then all you have to do is;

AviSource("file.avi").SelectEvery(5).AssumeFPS(23.976)

-For 23.976fps as output;

AviSource("file.avi").SelectEvery(4).AssumeFPS(29.97)

-And for 29.97fps as output.

When going to 23.976 and if some of the sections in the source are 29.97 (by looking at that timecode file you pasted this looks like the case) you will end up removing some of the non-duplicate frames, which will result in jerky motion. Usually as it has been explained before this is found either during the OP/ED and some pans. This can be of course avoided by using VFR, however you don't appear to want to do that from what you wrote in your post.

By having a look quick at that timecode file, looks like your source is mostly 23.976 with some 29.97 content, as it usually is with 119.88 source videos. So decimating it by a factor of 5 should give an output file with less jerky motion than if you decimated by a factor of 4. However you'd be better of by trying that yourself using your source.

Also, you mentioned wmv, so you will have to use DirectShowSource() for that (check the previous posts on how to correctly decimate those). Or, you can use VDub as you mentioned already...

[Gkatzos]

Thanks Martino.
I guess I’ll stick to the 23.976 frame rate. The previous timecode was for the main episode only, the OP & END were solid 23.976.
Is this the result of bad capturing or in Japan they air naruto shippuuden in hybrid framerate? And if they do, what do they gain? Better quality? Can their Tv handle this variable framerate?

Sorry for the extra questions (they are probably answered somewhere) but all the shippuuden episodes so far have the same messed up framerates (without the OP & END being the cause). I am always referring to the hi quality raws in wmv format EDIT: I mean wmv in avi so in that case i won't use directshowsource.

Thanks again for the immediate response and your help

[martino]

AFAIK this is the result of animators and production studios each going their own way...resulting in this ugly mess. I can't explain it further (the whole theory) than that without confusing myself. Reading through this topic a few times should be more enlightening though...

[errorrrr]

Um... I'll share my method of converting a:

VFR h264-acc.mkv raws to a CFR file without losing audio sync... :x

Purpose of this is to give it to a afxer to use or for easier time with avi... since avi doesn't like VFR :x it seems increasingly common to see h264-acc type raws and that's what my groups are using for Kaibutsu Oujo :x

I use tools:

MEGui (I got it from doom9's forum)
MKVMerge
AVISynth/DirectShowSource

I wont' go into detail how to use MEGui

The cool thing about MEGui is that it supports nearly every single format there is (except h264 natively...)

What I do is just fire up MEGui, and open the .mkv... don't even bother to split the .mkv raw using mkv extract...

When it fires up the AVISynth script editor in MEGui, in the actual command line part just put an fps of the common multiples 24/30 x 5/4 = 120 (well actually 119.88fps) and put convertfps=true.

so it'd look something like this:
DirectShowSource("example[h264].mkv",fps=119.88,convertfps=true)

after you finish the script, you can output it to whatever format you like, mp4, or avi using xvid or x264 or whatever.

Also choose a profile. Profile heading begins with AE are designed for anime. they are automatically set for 2 passes.

## for the audio portion (i'll use acc ->mp3)

same thing input the mkv directly no need to split... then choose lame mp3, and choose a CBR bit rate... again, CBR is just easier to handle especially in Vdub. and enqueue both jobs. and start. sit back and watch it encode.

After your 119.88 fps is done, dump it back into megui, and this time in the AVISynth script page use:
DirectShowSource("example[h264].mkv",fps=29.97,convertfps=true)

and it'll decimate the frames. the resulting video stream will be smooth. before you put it back together, you can rename the 29.97 fps video and audio with the same name, and open the video. FDSHowfilter, if you have installed will fire both up, check if the sync match. if they do just use vdub to mux it into an avi or use mkv to mux it back for a CFR MKV.

You can do further encoding work with your new CFR source.

Hope this makes sense :x please point out my mistake... I did it based on trial and error and it worked with the raw so yea...

The problem i had using MKV extract is that the video extracted is like 3 min longer while the audio is like 1 min shorter... However I haven't experimented with timecodes too much, but i think i will in the future. For now this is the method for me :x also, to convert the .h264 stream into .mp4 you can use like YAMB which is a GUI for mp4box... anyways if anyone have an easier way to do the above please give me some pointers thanks~

[martino]

My apprach would be:
Why to go into all the trouble of re-encoding it to 119.88fps and then back to 23.976 or 29.97 when you can just encode it to XviD (for a workraw) without having to change the framerate or duplicate any of the frames, and using the timecodes in Aegisub for timing and typesetting. And after all AFX sees the stream as CFR (which it fundamentally is when in AVI), so there isn't really a problem with that (only the audio will be out of synch)... All you have to do is then is re-encode the final release, mux into a container with supports VFR, so MKV or MP4 and you're done.

I haven't done too many tests using my apprach with MKV RAWs, but AFAIK it worked well with the ones that I tried in the past.

[errorrrr]

Originally Posted by martino

My apprach would be:
Why to go into all the trouble of re-encoding it to 119.88fps and then back to 23.976 or 29.97 when you can just encode it to XviD (for a workraw) without having to change the framerate or duplicate any of the frames, and using the timecodes in Aegisub for timing and typesetting. And after all AFX sees the stream as CFR (which it fundamentally is when in AVI), so there isn't really a problem with that (only the audio will be out of synch)... All you have to do is then is re-encode the final release, mux into a container with supports VFR, so MKV or MP4 and you're done.

I haven't done too many tests using my apprach with MKV RAWs, but AFAIK it worked well with the ones that I tried in the past.

The problem is when you reencode for the final release you'll have a video-audio desync problem... unless you just chuck the script with the h264/aac raw.