An hour plus of HD in under one gig?
April 4, 2010 5:40 PM Subscribe
How do I make my ~70 minute HD video under 1 gigabyte?
I have a project that I shot in an HD format (1440 x 1080 HDV, to be exact) that I've been working on for awhile, but only rendered to standard-def for delivery on formats like DVD.
Anyway, I'm now rendering out an HD version of it, and I'd like to know HOW people get long HD videos under 1 gigabyte? This is a size restriction for the place I want to put the video.
I know it's possible, because I've downloaded TV from torrrent sides where the video was, say, 45 minutes long and some 350 megabytes. (The video I'm talking about is not pirated material, I am just using those as a basis for comparison.) The torrent guys seem to be using the XviD codec... is this the right way to do it? Is there a better way?
Should I render the video out to .mp4 first and then compress it with XviD?
I'm using Sony Vegas.
I appreciate any help here.
I have a project that I shot in an HD format (1440 x 1080 HDV, to be exact) that I've been working on for awhile, but only rendered to standard-def for delivery on formats like DVD.
Anyway, I'm now rendering out an HD version of it, and I'd like to know HOW people get long HD videos under 1 gigabyte? This is a size restriction for the place I want to put the video.
I know it's possible, because I've downloaded TV from torrrent sides where the video was, say, 45 minutes long and some 350 megabytes. (The video I'm talking about is not pirated material, I am just using those as a basis for comparison.) The torrent guys seem to be using the XviD codec... is this the right way to do it? Is there a better way?
Should I render the video out to .mp4 first and then compress it with XviD?
I'm using Sony Vegas.
I appreciate any help here.
x264 is the most efficient H.264 encoder currently available and will compress significantly better than XviD in any situation. An hour-plus 1080p (or worse, 1080i) video is going to look like garbage at a gigabyte total size (less audio!) even if you preserve anamorphism (1440w non-square pixels rather than 1920w square pixels). Even x264 with the most complex set of encoding options won't be able to achieve anything watchable other than maybe the simplest anime at that bit rate. All other extant encoders will fare even worse.
My sincere suggestion would be to resize to 720p or better still 480p or smaller unless you can overcome the file size limit - say, by splitting to multiple videos, each of a certain duration.
posted by Inspector.Gadget at 5:47 PM on April 4, 2010
My sincere suggestion would be to resize to 720p or better still 480p or smaller unless you can overcome the file size limit - say, by splitting to multiple videos, each of a certain duration.
posted by Inspector.Gadget at 5:47 PM on April 4, 2010
MKV seems to be the way the ahem "legal material" you are referring to. Ha. But how it gets there is beyond me. MakeMKV is a program that can convert Blu ray discs to Mkv files nicely. Maybe you could mount the file and use that.
posted by lakerk at 5:47 PM on April 4, 2010
posted by lakerk at 5:47 PM on April 4, 2010
MakeMKV is a program that can convert Blu ray discs to Mkv files nicely. Maybe you could mount the file and use that.
MakeMKV only remuxes; it does not transcode audio or video (though it can pull the lossy core of a DTS-HD or TrueHD track). Additionally, Matroska is only a container format, and while it has less overhead than an MPEG transport stream, it is also less compatible with various consumer/pro video editing applications.
posted by Inspector.Gadget at 5:51 PM on April 4, 2010
MakeMKV only remuxes; it does not transcode audio or video (though it can pull the lossy core of a DTS-HD or TrueHD track). Additionally, Matroska is only a container format, and while it has less overhead than an MPEG transport stream, it is also less compatible with various consumer/pro video editing applications.
posted by Inspector.Gadget at 5:51 PM on April 4, 2010
Response by poster: My sincere suggestion would be to resize to 720p or better still 480p or smaller unless you can overcome the file size limit - say, by splitting to multiple videos, each of a certain duration.
I think you are probably right here. When I watch an XviD rip of a TV show, it's not at 1080p usually anyway, is it?
Is 480p still considered HD?
I am sorry to sound so ignorant here; I've spent so much time dealing with this project bounced down to standard-def formats that I'm now out of my element here trying to get it to "look HD", even though it was shot in HDV.
posted by meadowlark lime at 5:56 PM on April 4, 2010
I think you are probably right here. When I watch an XviD rip of a TV show, it's not at 1080p usually anyway, is it?
Is 480p still considered HD?
I am sorry to sound so ignorant here; I've spent so much time dealing with this project bounced down to standard-def formats that I'm now out of my element here trying to get it to "look HD", even though it was shot in HDV.
posted by meadowlark lime at 5:56 PM on April 4, 2010
480p is not considered HD. 720p is. I thought these "files you downloaded" were legal. Not tv shows?
posted by lakerk at 6:00 PM on April 4, 2010
posted by lakerk at 6:00 PM on April 4, 2010
Is 480p still considered HD?
Not generally. 480i/p is NTSC DVD resolution. Of course, "HD" is just semantics anyway, given the proliferation of crap-quality "High Definition" video all over the internet.
When I watch an XviD rip of a TV show, it's not at 1080p usually anyway, is it
XviD is not efficient enough to be suitable for 1080p encoding. A few lesser (Bollywood, re-encoders, rank amateurs) release groups try it for 720p and have to settle for low-quality video or oversized files.
I'm now out of my element here trying to get it to "look HD", even though it was shot in HDV.
Resizing to 480p with a high-quality resizing algorithm will give you that "shot in HD" look if your source has it; this is very noticeable in recent lower-budget DVDs. You may still have to work around file size limits to retain sufficient visual quality, but you won't need to split into as many parts.
Tell us more about your project. Did you shoot in 1080i or 1080p? What is the framerate (or field rate, if interlaced) of the video? What does the destination format need to be? Does the destination website skip re-encoding the video if it is already Flash-compatible?
posted by Inspector.Gadget at 6:02 PM on April 4, 2010
Not generally. 480i/p is NTSC DVD resolution. Of course, "HD" is just semantics anyway, given the proliferation of crap-quality "High Definition" video all over the internet.
When I watch an XviD rip of a TV show, it's not at 1080p usually anyway, is it
XviD is not efficient enough to be suitable for 1080p encoding. A few lesser (Bollywood, re-encoders, rank amateurs) release groups try it for 720p and have to settle for low-quality video or oversized files.
I'm now out of my element here trying to get it to "look HD", even though it was shot in HDV.
Resizing to 480p with a high-quality resizing algorithm will give you that "shot in HD" look if your source has it; this is very noticeable in recent lower-budget DVDs. You may still have to work around file size limits to retain sufficient visual quality, but you won't need to split into as many parts.
Tell us more about your project. Did you shoot in 1080i or 1080p? What is the framerate (or field rate, if interlaced) of the video? What does the destination format need to be? Does the destination website skip re-encoding the video if it is already Flash-compatible?
posted by Inspector.Gadget at 6:02 PM on April 4, 2010
Response by poster: The thing that I am asking about is my own personal project, over which I own 100% of the copyright.
I am talking about (illegal rips) of TV shows because that's the only basis of comparison I have for HD files that are under one gigabyte.
I would want to make this file at least in 720p then because the point of the exercise is that they would be "HD".
posted by meadowlark lime at 6:03 PM on April 4, 2010
I am talking about (illegal rips) of TV shows because that's the only basis of comparison I have for HD files that are under one gigabyte.
I would want to make this file at least in 720p then because the point of the exercise is that they would be "HD".
posted by meadowlark lime at 6:03 PM on April 4, 2010
I would want to make this file at least in 720p then because the point of the exercise is that they would be "HD".
OK. If 720p is the lowest resolution you can go, how can you get around the file size limitation? Is your target streaming Flash video? If you can share, please provide a link to the website you plan to host the material on; that way, we can all read the file format guidelines to figure out the best way to get from Source -> Destination.
posted by Inspector.Gadget at 6:05 PM on April 4, 2010
OK. If 720p is the lowest resolution you can go, how can you get around the file size limitation? Is your target streaming Flash video? If you can share, please provide a link to the website you plan to host the material on; that way, we can all read the file format guidelines to figure out the best way to get from Source -> Destination.
posted by Inspector.Gadget at 6:05 PM on April 4, 2010
Response by poster: Resizing to 480p with a high-quality resizing algorithm will give you that "shot in HD" look if your source has it; this is very noticeable in recent lower-budget DVDs.
As a way of comparison, are the "HD" videos on Vimeo up there at 480p or higher?
The website I'm trying to put this on is, in fact, Vimeo. So I want it to look comparable to the quality of the best videos on there, if possible.
Tell us more about your project. Did you shoot in 1080i or 1080p? What is the framerate (or field rate, if interlaced) of the video? What does the destination format need to be?
It was shot in HDV, 1080i at a 29.97 field rate. In all the preivous SD renders of this project, I have de-interlaced it to 23.976 IVTC film using 2:3 pulldown into such file formats as .avi and MPEG-2.
Vimeo wants it in in H.264 aka mp4 format.
Does the destination website skip re-encoding the video if it is already Flash-compatible?
I don't know. You seem very knowledgeable about this, Inspector, do you know? How will it affect my strategy to get it to look good?
Thanks in advance for your help, and pardon any technical solecisms in the above text, the technical side is not my natural language.
posted by meadowlark lime at 6:11 PM on April 4, 2010
As a way of comparison, are the "HD" videos on Vimeo up there at 480p or higher?
The website I'm trying to put this on is, in fact, Vimeo. So I want it to look comparable to the quality of the best videos on there, if possible.
Tell us more about your project. Did you shoot in 1080i or 1080p? What is the framerate (or field rate, if interlaced) of the video? What does the destination format need to be?
It was shot in HDV, 1080i at a 29.97 field rate. In all the preivous SD renders of this project, I have de-interlaced it to 23.976 IVTC film using 2:3 pulldown into such file formats as .avi and MPEG-2.
Vimeo wants it in in H.264 aka mp4 format.
Does the destination website skip re-encoding the video if it is already Flash-compatible?
I don't know. You seem very knowledgeable about this, Inspector, do you know? How will it affect my strategy to get it to look good?
Thanks in advance for your help, and pardon any technical solecisms in the above text, the technical side is not my natural language.
posted by meadowlark lime at 6:11 PM on April 4, 2010
Vimeo wants it in H.264...
You might know this, but Vimeo will actually process multiple formats (see the bottom of the following link). It just might not look as good as their recommended settings.
posted by reductiondesign at 6:24 PM on April 4, 2010
You might know this, but Vimeo will actually process multiple formats (see the bottom of the following link). It just might not look as good as their recommended settings.
posted by reductiondesign at 6:24 PM on April 4, 2010
Best answer: You don't want to IVTC anything unless it's been telecined earlier. A true 60i source, like the one shot by cameras that comply with the original 1080i HDV spec (and not some later weirdness with non-native 24p) needs to be deinterlaced before resizing. Does your camera shoot in true 60i or does it hard telecine 24p?
Part of the reason that 60i stuff looks good is that it samples motion twice as often as 30p stuff (the trade-off is that 30p has more vertical resolution in every frame). Unfortunately, when re-encoding and thinking about space, bob-deinterlacing 60i to 60p to retain motion fluidity will work but will eat bitrate at only somewhat less than 2x what it would cost to do same-rate deinterlacing and use 30p. Since Vimeo needs progressive video, and you're worried about filesize, 30p would seem to be the way to go.
I don't know. You seem very knowledgeable about this, Inspector, do you know? How will it affect my strategy to get it to look good?
Vimeo apparently doesn't transcode some H.264-in-MP4 stuff, but I don't see any clear guidelines on how to end up with such a file. My best guess, from your requirements and their guidelines, is that your files need to be H.264-in-MP4, 720p, ~5000 kbits/s or better, featuring stereo AAC-LC audio. They ask for 44.1 kHz audio sampling, and since it sounds like they re-encode no matter what and using anybody's guess as to an audio workflow, better to do the resampling on your end. Therefore, here is my general strategy:
Initially, you have your 70-minute video. I assume it's on one HDV tape or card and you can actually get it on your desktop easily. If your source is not one big HDV camera-created file, there are numerous other ways to get to the same end. For instance, it's very easy to load a lossless intermediate AVI file into Avisynth (no indexing required!) and pass that to x264. Let me know.
1) You should download and install Avisynth, download and extract the DGIndex package, download the x264 executable, download and extract eac3to, and finally download the Yadif plugin for Avisynth and move Yadif.dll as well as DGDecode.dll (from the DGIndex package) over to your Avisynth plugins folder. If you're sure your source is in fact telecined, ignore Yadif and instead grab TIVTC and move it to your plugins folder. Finally, download and extract the NeroAACEnc executable to your eac3to folder and also grab and extract the patched version of YAMB.
2) Open your source file (m2t, mts, m2ts) in DGIndex. Go to "video" and make sure Field Operation is set to "Honor Pulldown Flags" (there shouldn't be any, but Force Film will mess things up and the third option is never useful unless you're debugging). Make sure you have "Demux all tracks" selected in the Audio menu. Go to File -> Save Project... and pick your output D2V.
3) When this finishes, open up your favorite text editor and make a file like this:
If your source was actually hard telecined, you'd do this instead:
4) Save this file as something.avs. It is an Avisynth script and can be used with x264:
5) Open a command prompt and navigate to where you put x264.exe. Try out the following script:
Now, CRF is not a targeted bitrate or file size, but it will give you good quality at reasonably low bit rates. If you need further refinement here, look to the x264 documentation for examples of how to do a nearly bit rate exact 2-pass encode.
6) That will take a while, maybe a few hours, for a 70 min project, depending on the speed of your PC.
7) You have your demuxed audio from DGIndex, named something something DELAY XXX ms.mp2. You need this in AAC-LC. Using eac3to from the command line, it's fairly easy:
8. When you have both your newly created video file and your newly created audio file, you can mux them to an MP4 file using YAMB. YAMB is a GUI app and reasonably user friendly. Remember to set the delay of your audio track appropriately unless DGIndex printed a delay of 0 ms to the file name of the demuxed audio. You can also use YAMB to split the output file to <1>
I realize that this is a lot to drop on your lap, but both x264 and Nero Digital AAC perform so well in comparison tests that it's a sin not to use them, particularly where your pristine encoded video will be mauled by some badly tuned Sorenson Spark encoder down the line.
posted by Inspector.Gadget at 6:57 PM on April 4, 2010 [7 favorites]
Part of the reason that 60i stuff looks good is that it samples motion twice as often as 30p stuff (the trade-off is that 30p has more vertical resolution in every frame). Unfortunately, when re-encoding and thinking about space, bob-deinterlacing 60i to 60p to retain motion fluidity will work but will eat bitrate at only somewhat less than 2x what it would cost to do same-rate deinterlacing and use 30p. Since Vimeo needs progressive video, and you're worried about filesize, 30p would seem to be the way to go.
I don't know. You seem very knowledgeable about this, Inspector, do you know? How will it affect my strategy to get it to look good?
Vimeo apparently doesn't transcode some H.264-in-MP4 stuff, but I don't see any clear guidelines on how to end up with such a file. My best guess, from your requirements and their guidelines, is that your files need to be H.264-in-MP4, 720p, ~5000 kbits/s or better, featuring stereo AAC-LC audio. They ask for 44.1 kHz audio sampling, and since it sounds like they re-encode no matter what and using anybody's guess as to an audio workflow, better to do the resampling on your end. Therefore, here is my general strategy:
Initially, you have your 70-minute video. I assume it's on one HDV tape or card and you can actually get it on your desktop easily. If your source is not one big HDV camera-created file, there are numerous other ways to get to the same end. For instance, it's very easy to load a lossless intermediate AVI file into Avisynth (no indexing required!) and pass that to x264. Let me know.
1) You should download and install Avisynth, download and extract the DGIndex package, download the x264 executable, download and extract eac3to, and finally download the Yadif plugin for Avisynth and move Yadif.dll as well as DGDecode.dll (from the DGIndex package) over to your Avisynth plugins folder. If you're sure your source is in fact telecined, ignore Yadif and instead grab TIVTC and move it to your plugins folder. Finally, download and extract the NeroAACEnc executable to your eac3to folder and also grab and extract the patched version of YAMB.
2) Open your source file (m2t, mts, m2ts) in DGIndex. Go to "video" and make sure Field Operation is set to "Honor Pulldown Flags" (there shouldn't be any, but Force Film will mess things up and the third option is never useful unless you're debugging). Make sure you have "Demux all tracks" selected in the Audio menu. Go to File -> Save Project... and pick your output D2V.
3) When this finishes, open up your favorite text editor and make a file like this:
MPEG2Source("C:\users\meadowlark lime\desktop\myproject.d2v")
Yadif()
# will deinterlace 60i to 30p and slightly blur field edges to eliminate artifacts
Spline36Resize(1280,720)
# now you have 720p; use Spline64Resize for extra sharpnessIf your source was actually hard telecined, you'd do this instead:
MPEG2Source("C:\users\meadowlark lime\desktop\myproject.d2v")
TFM().TDecimate() # match fields to make frames, eliminate 1-in-5 dupe
Spline36Resize(1280,720)4) Save this file as something.avs. It is an Avisynth script and can be used with x264:
5) Open a command prompt and navigate to where you put x264.exe. Try out the following script:
x264.exe --crf 20 --tune film --preset slow -o somefile.mp4 "C:\users\meadowlark lime\desktop\myproject.avs"Now, CRF is not a targeted bitrate or file size, but it will give you good quality at reasonably low bit rates. If you need further refinement here, look to the x264 documentation for examples of how to do a nearly bit rate exact 2-pass encode.
6) That will take a while, maybe a few hours, for a 70 min project, depending on the speed of your PC.
7) You have your demuxed audio from DGIndex, named something something DELAY XXX ms.mp2. You need this in AAC-LC. Using eac3to from the command line, it's fairly easy:
eac3to source.mp2 destination.m4a -resampleTo441008. When you have both your newly created video file and your newly created audio file, you can mux them to an MP4 file using YAMB. YAMB is a GUI app and reasonably user friendly. Remember to set the delay of your audio track appropriately unless DGIndex printed a delay of 0 ms to the file name of the demuxed audio. You can also use YAMB to split the output file to <1>
I realize that this is a lot to drop on your lap, but both x264 and Nero Digital AAC perform so well in comparison tests that it's a sin not to use them, particularly where your pristine encoded video will be mauled by some badly tuned Sorenson Spark encoder down the line.
posted by Inspector.Gadget at 6:57 PM on April 4, 2010 [7 favorites]
You can also use YAMB to split the output file to <1>
err, to <1 GB pieces to beat the filesize limit.
posted by Inspector.Gadget at 6:59 PM on April 4, 2010
err, to <1 GB pieces to beat the filesize limit.
posted by Inspector.Gadget at 6:59 PM on April 4, 2010
We're not here to discuss what the OP downloads. It's none of our concern if he's downloading content legal to his area or not, it doesn't affect the question.
As I look at hour long tv show rips on tvtorrents, I see they're hovering right at 1.07Gb, which is a 720p .mkv file that's actually 42-45 minutes long. I just tried to google up the scene release requirements for these shows, which might help you figure out what they're doing, but I wasn't immediately successful.
I would recommend that you consider splitting the file into two or more segments and then up them.
You can also snag one of the files you're talking about and load it into gSpot, and take the info it gives you to try your encoding.
posted by TomMelee at 7:01 PM on April 4, 2010
As I look at hour long tv show rips on tvtorrents, I see they're hovering right at 1.07Gb, which is a 720p .mkv file that's actually 42-45 minutes long. I just tried to google up the scene release requirements for these shows, which might help you figure out what they're doing, but I wasn't immediately successful.
I would recommend that you consider splitting the file into two or more segments and then up them.
You can also snag one of the files you're talking about and load it into gSpot, and take the info it gives you to try your encoding.
posted by TomMelee at 7:01 PM on April 4, 2010
I just tried to google up the scene release requirements for these shows, which might help you figure out what they're doing, but I wasn't immediately successful.
Don't bother. Anybody using 1 gig for ~1 hour 720p encode is doing it wrong and not complying with (often useless) scene standards to begin with.
You can also snag one of the files you're talking about and load it into gSpot, and take the info it gives you to try your encoding.
GSpot doesn't deliver much useful information about anything in a Matroska or MP4 container and is long outdated. On that front, MediaInfo is a far better choice.
posted by Inspector.Gadget at 7:03 PM on April 4, 2010
Don't bother. Anybody using 1 gig for ~1 hour 720p encode is doing it wrong and not complying with (often useless) scene standards to begin with.
You can also snag one of the files you're talking about and load it into gSpot, and take the info it gives you to try your encoding.
GSpot doesn't deliver much useful information about anything in a Matroska or MP4 container and is long outdated. On that front, MediaInfo is a far better choice.
posted by Inspector.Gadget at 7:03 PM on April 4, 2010
You'll want a data rate of 1-2 Mb/s - to give you an idea, I just compressed a video at 960x 540 (1/2 1080, still larger than SD video, but not full HD) and at .6mb/s it was about 5 megs/min. So at 2megabits/sec it'd be about 20megs/min about 50 min to the gig. The more compressed it is, the smaller the file size.
The math is (data rate (in megabits/sec) * #seconds)/8 = size
I ran (.6 * 360 seconds)/8 = 27 megs (and that's about how big the file was.) for five min.
Figure at full resolution you'll need around 1.5-2 Mb/s for x264 (or h.264) to look good.
posted by filmgeek at 8:06 PM on April 4, 2010
The math is (data rate (in megabits/sec) * #seconds)/8 = size
I ran (.6 * 360 seconds)/8 = 27 megs (and that's about how big the file was.) for five min.
Figure at full resolution you'll need around 1.5-2 Mb/s for x264 (or h.264) to look good.
posted by filmgeek at 8:06 PM on April 4, 2010
Figure at full resolution you'll need around 1.5-2 Mb/s for x264 (or h.264) to look good.
At 720p or 1080p? No. Not even close. It'll look like total crap.
posted by Inspector.Gadget at 8:11 PM on April 4, 2010
At 720p or 1080p? No. Not even close. It'll look like total crap.
posted by Inspector.Gadget at 8:11 PM on April 4, 2010
Inspector is way more of an expert than I am, but I use x264 and set the bitrate to whatever my budget is (using the same formula as filmgeek). I run two passes, which helps the encoder figure out where to best spend its bits.
Then again, I do technical videos with exactly 30 fps and no sound. So YMMV.
posted by miyabo at 8:16 PM on April 4, 2010
Then again, I do technical videos with exactly 30 fps and no sound. So YMMV.
posted by miyabo at 8:16 PM on April 4, 2010
960x540 is one quarter of 1920x1080, not one half. So you need more like 4-6Mbps, like I.G says.
posted by polyglot at 8:58 PM on April 4, 2010
posted by polyglot at 8:58 PM on April 4, 2010
Right, I would go with circa 5Mbps for 720p content. 1080p would get 8-10, depending on complexity. Bear in mind that these are intermediate files anyway, used only because Vimeo won't take a gigantic HuffYUV or similar file, and so it's even more important to err on the side of visual transparency so long as cutting into more than one file or similar techniques are avaulable and bitrate doesn't become a barrier.
posted by Inspector.Gadget at 9:03 PM on April 4, 2010
posted by Inspector.Gadget at 9:03 PM on April 4, 2010
Response by poster: Wow. I did not anticipate getting so many helpful and detailed responses from AskMe -- I considered going to a specialist video board but the stuff I got here was better than I got from those boards for other questions.
Thanks to everyone who participated, I think I'll be able to go ahead and dive in.
Thanks ESPECIALLY to Inspector.Gadget for for posting such a rich and detailed step-by-step instruction. At this point I have no idea if it'll be the right way to get me where I want, but you put across the info with such authority that I'm betting it will.
Also, those who said I could cut the video in two parts are right. Such a simple solution, the purist in me didn't want to do it but it might be best anyway. Quality of video has to trump everything. And maybe if the video is just a little bit over 1 gig I could get Vimeo to suspend the rule. Then again, maybe I'm better off going for highest possible video quality and making each ~35 minute part close to 1 gig.
Anyway, thanks to everyone for their help so far and I expect I'll be popping back into this thread to ask further questions. I promise to report on how the thing ended up and what method turned out best.
posted by meadowlark lime at 9:34 PM on April 4, 2010
Thanks to everyone who participated, I think I'll be able to go ahead and dive in.
Thanks ESPECIALLY to Inspector.Gadget for for posting such a rich and detailed step-by-step instruction. At this point I have no idea if it'll be the right way to get me where I want, but you put across the info with such authority that I'm betting it will.
Also, those who said I could cut the video in two parts are right. Such a simple solution, the purist in me didn't want to do it but it might be best anyway. Quality of video has to trump everything. And maybe if the video is just a little bit over 1 gig I could get Vimeo to suspend the rule. Then again, maybe I'm better off going for highest possible video quality and making each ~35 minute part close to 1 gig.
Anyway, thanks to everyone for their help so far and I expect I'll be popping back into this thread to ask further questions. I promise to report on how the thing ended up and what method turned out best.
posted by meadowlark lime at 9:34 PM on April 4, 2010
Response by poster: You don't want to IVTC anything unless it's been telecined earlier. A true 60i source, like the one shot by cameras that comply with the original 1080i HDV spec (and not some later weirdness with non-native 24p) needs to be deinterlaced before resizing. Does your camera shoot in true 60i or does it hard telecine 24p?
It shoots in native 60i, with no progressive option. I had never considered the problem of resizing before/while changing the frame rate, but then again, that's why you're the pro and I'm just some guy.
Inspector, will 30p look as "filmic" as 24p when streamed in Vimeo flash? I've been doing the 24p thing for the DVD versions and I thought it looked good.
posted by meadowlark lime at 9:37 PM on April 4, 2010
It shoots in native 60i, with no progressive option. I had never considered the problem of resizing before/while changing the frame rate, but then again, that's why you're the pro and I'm just some guy.
Inspector, will 30p look as "filmic" as 24p when streamed in Vimeo flash? I've been doing the 24p thing for the DVD versions and I thought it looked good.
posted by meadowlark lime at 9:37 PM on April 4, 2010
Response by poster: If your source is not one big HDV camera-created file, there are numerous other ways to get to the same end. For instance, it's very easy to load a lossless intermediate AVI file into Avisynth (no indexing required!) and pass that to x264. Let me know.
Okay, I haven't even spit out the complete HD file that will end up getting resized into the x264.
It's NOT a camera-created file. It's a dozen or so sub-projects that need to be rendered out as individual segments, then stuck back into Vegas to be stitched together, THEN rendered out to the intermediate file.
The stitching together process is not a problem, since I figured out how to do all that when I was working with this project as a standard def project (in .avi and mpeg-2).
HOWEVER, my question to you would be which lossless intermediate AVI codec should I use? YUV? And how much hard drive space should I expect 140 minutes (since it's got to be put out as individual segments first and then as a stitched-together final version) to take up?
Something tells me I'll be out buying a hard drive tomorrow.
posted by meadowlark lime at 9:48 PM on April 4, 2010
Okay, I haven't even spit out the complete HD file that will end up getting resized into the x264.
It's NOT a camera-created file. It's a dozen or so sub-projects that need to be rendered out as individual segments, then stuck back into Vegas to be stitched together, THEN rendered out to the intermediate file.
The stitching together process is not a problem, since I figured out how to do all that when I was working with this project as a standard def project (in .avi and mpeg-2).
HOWEVER, my question to you would be which lossless intermediate AVI codec should I use? YUV? And how much hard drive space should I expect 140 minutes (since it's got to be put out as individual segments first and then as a stitched-together final version) to take up?
Something tells me I'll be out buying a hard drive tomorrow.
posted by meadowlark lime at 9:48 PM on April 4, 2010
It may be worth noting that the scene releases marked "HDTV" are not HD files, just sourced from a Hi-Def TV broadcast. For a scene release to be HD, it needs to be tagged 720p... So the stuff you were originally looking at at 350Mb is likely to have been xxx.HDTV-xxx and not Hi-Def at all.
posted by benzo8 at 10:11 PM on April 4, 2010
posted by benzo8 at 10:11 PM on April 4, 2010
Response by poster: It may be worth noting that the scene releases marked "HDTV" are not HD files, just sourced from a Hi-Def TV broadcast. For a scene release to be HD, it needs to be tagged 720p... So the stuff you were originally looking at at 350Mb is likely to have been xxx.HDTV-xxx and not Hi-Def at all.
This makes a lot of sense. I believe you're right. Also, it shows a little absurdity in my quest to get an HD file when I can't tell the difference between HD and non-HD when watching it on my computer.
posted by meadowlark lime at 10:13 PM on April 4, 2010
This makes a lot of sense. I believe you're right. Also, it shows a little absurdity in my quest to get an HD file when I can't tell the difference between HD and non-HD when watching it on my computer.
posted by meadowlark lime at 10:13 PM on April 4, 2010
A true 60i source, like the one shot by cameras that comply with the original 1080i HDV spec (and not some later weirdness with non-native 24p) needs to be deinterlaced before resizing. Does your camera shoot in true 60i or does it hard telecine 24p?
If you are editing in Vegas it should automatically deinterlace the footage for you. Set deinterlace method to "interpolate" and make sure your rendering quality is set to good or best.
posted by afu at 2:02 AM on April 5, 2010
If you are editing in Vegas it should automatically deinterlace the footage for you. Set deinterlace method to "interpolate" and make sure your rendering quality is set to good or best.
posted by afu at 2:02 AM on April 5, 2010
Best answer: It's NOT a camera-created file. It's a dozen or so sub-projects that need to be rendered out as individual segments, then stuck back into Vegas to be stitched together, THEN rendered out to the intermediate file.
Yeah, then you should render to a lossless intermediate. Check out HuffYUV, which you can export to by installing and selecting the custom AVI export in Vegas. HuffYUV is far smaller than raw YUV and takes little extra time to encode.
Something tells me I'll be out buying a hard drive tomorrow.
This is probably a good idea. If nothing else, space considerations aside, it will keep you from hitting a disk bottleneck.
Fortunately, transcoding from the finished HuffYUV file into x264 is easy. Download and install ffdshow tryouts (you want the most recent 32-bit build. Once you've done that, in "ffdshow video decoder", go to the "Codecs" tab in the left sidebar and then in the main area set "HuffYUV" to "libavcodec". You can leave every checkbox in that sidebar empty, because you don't want to postprocess anything. Scroll down on the left to "output" and make sure "closest matching colorspace" is checked, "set interlace flag is unchecked", "High quality YV12 to RGB conversion" is checked (not really necessary in this case), and YV12 is checked.
Next, download the Haali Media Splitter packaege and either install or extract it to find AVSS.dll; drop this into yout Avisynth plugins folder.
Now open a text editor and do the following:
Save the script, and pass that to x264 just as you would have done with the other script above. Should work fine. As above, do it across hard drives if you can because both MPEG-2 -> HuffYUV and HuffYUV -> x264 will require less processing power / time than straight MPEG-2 -> x264. Let us know how it goes.
posted by Inspector.Gadget at 5:36 AM on April 5, 2010
Yeah, then you should render to a lossless intermediate. Check out HuffYUV, which you can export to by installing and selecting the custom AVI export in Vegas. HuffYUV is far smaller than raw YUV and takes little extra time to encode.
Something tells me I'll be out buying a hard drive tomorrow.
This is probably a good idea. If nothing else, space considerations aside, it will keep you from hitting a disk bottleneck.
Fortunately, transcoding from the finished HuffYUV file into x264 is easy. Download and install ffdshow tryouts (you want the most recent 32-bit build. Once you've done that, in "ffdshow video decoder", go to the "Codecs" tab in the left sidebar and then in the main area set "HuffYUV" to "libavcodec". You can leave every checkbox in that sidebar empty, because you don't want to postprocess anything. Scroll down on the left to "output" and make sure "closest matching colorspace" is checked, "set interlace flag is unchecked", "High quality YV12 to RGB conversion" is checked (not really necessary in this case), and YV12 is checked.
Next, download the Haali Media Splitter packaege and either install or extract it to find AVSS.dll; drop this into yout Avisynth plugins folder.
Now open a text editor and do the following:
DSS2("C:\path\to\my\losslessHuffYUVfile.avi")
# Spline36Resize(1280,720)
# uncomment above if you didn't resize in Vegas
# since you're joining clips in Vegas, deinterlace there to
# avoid weird field order or other problemsSave the script, and pass that to x264 just as you would have done with the other script above. Should work fine. As above, do it across hard drives if you can because both MPEG-2 -> HuffYUV and HuffYUV -> x264 will require less processing power / time than straight MPEG-2 -> x264. Let us know how it goes.
posted by Inspector.Gadget at 5:36 AM on April 5, 2010
Response by poster: So Inspector, per your latest comment, does that mean that I am superceding your prior instructions to use AviSynth to de-interlace? Or am I somehow combining both methods?
I just downloaded and installed HuffYUV, this should solve my nightmares about space and let me do everything with only one extra 1 TB hard drive.
posted by meadowlark lime at 9:40 AM on April 5, 2010
I just downloaded and installed HuffYUV, this should solve my nightmares about space and let me do everything with only one extra 1 TB hard drive.
posted by meadowlark lime at 9:40 AM on April 5, 2010
So Inspector, per your latest comment, does that mean that I am superceding your prior instructions to use AviSynth to de-interlace? Or am I somehow combining both methods?
Since you are going to be cutting and joining and maybe doing other transition effects, you should deinterlace as soon as possible to avoid field order problems and combing artifacts. You could load everything into Avisynth, deinterlace and resize there, and load the AVS script into Vegas using a Vegas plugin. The downside here, I believe, is that audio cutting and splitting won't be automatic unless you also feed Vegas the audio from each source through your AVS script and let Vegas handle it when you do the video. I can show you how to do this, but it adds some additional time in a text editor - potentially a lot of extra time, if the audio delay in all your source files isn't zero.
At the moment, I assume you have all your files in Vegas already. If this is the case, and Vegas lets you apply filters in a certain order, then make sure deinterlacing takes place first. You'll have to Google around and find out which same-rate deinterlace filter in Vegas yields the highest quality, as I am not certain. Once your video is 30p, now you're doing editing as usual in Vegas. You can likely also resize there, and then exporting your deinterlaced, edited, and resized project to HuffYUV will leave you with an AVI file that you can call with only the DSS2() line in my immediate previous post. If you choose this route in Vegas, you won't need to do any additional filtering in Avisynth.
I'm not sure where that leaves you with audio handling. If Vegas allows you to export the audio from your finished project as PCM, WAV, or W64, then go ahead and do that and feed it to eac3to as above instead of the MP2 audio - the command line will be the same save for the source filename. You can then mux with YAMB as usual. If Vegas allows direct export to AAC-in-MP4 (M4A) or MP3 instead, then that should be fine.
posted by Inspector.Gadget at 10:08 AM on April 5, 2010
Since you are going to be cutting and joining and maybe doing other transition effects, you should deinterlace as soon as possible to avoid field order problems and combing artifacts. You could load everything into Avisynth, deinterlace and resize there, and load the AVS script into Vegas using a Vegas plugin. The downside here, I believe, is that audio cutting and splitting won't be automatic unless you also feed Vegas the audio from each source through your AVS script and let Vegas handle it when you do the video. I can show you how to do this, but it adds some additional time in a text editor - potentially a lot of extra time, if the audio delay in all your source files isn't zero.
At the moment, I assume you have all your files in Vegas already. If this is the case, and Vegas lets you apply filters in a certain order, then make sure deinterlacing takes place first. You'll have to Google around and find out which same-rate deinterlace filter in Vegas yields the highest quality, as I am not certain. Once your video is 30p, now you're doing editing as usual in Vegas. You can likely also resize there, and then exporting your deinterlaced, edited, and resized project to HuffYUV will leave you with an AVI file that you can call with only the DSS2() line in my immediate previous post. If you choose this route in Vegas, you won't need to do any additional filtering in Avisynth.
I'm not sure where that leaves you with audio handling. If Vegas allows you to export the audio from your finished project as PCM, WAV, or W64, then go ahead and do that and feed it to eac3to as above instead of the MP2 audio - the command line will be the same save for the source filename. You can then mux with YAMB as usual. If Vegas allows direct export to AAC-in-MP4 (M4A) or MP3 instead, then that should be fine.
posted by Inspector.Gadget at 10:08 AM on April 5, 2010
Response by poster: At the moment, I assume you have all your files in Vegas already. If this is the case, and Vegas lets you apply filters in a certain order, then make sure deinterlacing takes place first.
My experience hasn't shown me that Vegas lets you select what orders filters happen in. In any case, I've always done the deinterlace at the render stage. Like afu said above, you can "automatically" deinterlace in Vegas simply by changing your project settings to some kind of deinterlaced video (30p, 24p) and then all the video you've put in there is de-interlaced.
How does that affect your instruction?
Also, not to confuse things, but are you aware of Debugmode Frameserver? It allows you to "push" video from one application to another without having to render it to an intermediate file. I'm wondering if that should come into play here?
posted by meadowlark lime at 10:24 AM on April 5, 2010
My experience hasn't shown me that Vegas lets you select what orders filters happen in. In any case, I've always done the deinterlace at the render stage. Like afu said above, you can "automatically" deinterlace in Vegas simply by changing your project settings to some kind of deinterlaced video (30p, 24p) and then all the video you've put in there is de-interlaced.
How does that affect your instruction?
Also, not to confuse things, but are you aware of Debugmode Frameserver? It allows you to "push" video from one application to another without having to render it to an intermediate file. I'm wondering if that should come into play here?
posted by meadowlark lime at 10:24 AM on April 5, 2010
Response by poster: By the way, I just talked to the Vimeo people and apparently the file limit on single videos has been raised to 2 Gigs, so it seems I should be able to get this thing looking nice without resort to splitting.
posted by meadowlark lime at 10:26 AM on April 5, 2010
posted by meadowlark lime at 10:26 AM on April 5, 2010
How does that affect your instruction?
Make sure Vegas is actually doing the work and the quality is OK. Dumb blend deinterlacing often looks horrendous.
It allows you to "push" video from one application to another without having to render it to an intermediate file. I'm wondering if that should come into play here?
That's what Avisynth does. You can go source files -> Avisynth -> Vegas -> HuffYUV -> Avisynth -> x264 if you wish; the second chain is necessary only because Vegas won't use x264 natively. Since your project is already in Vegas, and you haven't raised any issues with Vegas' native deinterlacing, the first chain is apparently unnecessary here.
By the way, I just talked to the Vimeo people and apparently the file limit on single videos has been raised to 2 Gigs, so it seems I should be able to get this thing looking nice without resort to splitting.
For a 70 min project I'd still split it in half, especially given that it will be transcoded when you upload.
posted by Inspector.Gadget at 10:46 AM on April 5, 2010
Make sure Vegas is actually doing the work and the quality is OK. Dumb blend deinterlacing often looks horrendous.
It allows you to "push" video from one application to another without having to render it to an intermediate file. I'm wondering if that should come into play here?
That's what Avisynth does. You can go source files -> Avisynth -> Vegas -> HuffYUV -> Avisynth -> x264 if you wish; the second chain is necessary only because Vegas won't use x264 natively. Since your project is already in Vegas, and you haven't raised any issues with Vegas' native deinterlacing, the first chain is apparently unnecessary here.
By the way, I just talked to the Vimeo people and apparently the file limit on single videos has been raised to 2 Gigs, so it seems I should be able to get this thing looking nice without resort to splitting.
For a 70 min project I'd still split it in half, especially given that it will be transcoded when you upload.
posted by Inspector.Gadget at 10:46 AM on April 5, 2010
Response by poster: Inspector, after some delays and slow computing I've finally gotten to the stage where I have the complete movie as a HUFFYuv and tried to put it through the x264 renderer via AviSynth.
Everything seemed to be going well, but when the final mp4 was created and I tried to open it with quicktime, the error I got was: "Error -2002: a bad public atom was found in the movie."
?!?!?
I opened it with VLC because that usually opens ANYTHING. It did indeed open and play the movie, but the movie was flipped VERTICALLY AND HORIZONTALLY.
Any idea what could have happened here? I've never seen an error like this so I'm quite sure it didn't come until the x264 step. (In other words, the HuffYUV played fine in Vegas.)
posted by meadowlark lime at 9:12 AM on April 9, 2010
Everything seemed to be going well, but when the final mp4 was created and I tried to open it with quicktime, the error I got was: "Error -2002: a bad public atom was found in the movie."
?!?!?
I opened it with VLC because that usually opens ANYTHING. It did indeed open and play the movie, but the movie was flipped VERTICALLY AND HORIZONTALLY.
Any idea what could have happened here? I've never seen an error like this so I'm quite sure it didn't come until the x264 step. (In other words, the HuffYUV played fine in Vegas.)
posted by meadowlark lime at 9:12 AM on April 9, 2010
Quicktime is very peculiar about the sorts of MP4 files it will accept. Quicktime compatibility is a nightmare. I wouldn't use that to gauge a file's playability.
VLC is broken generally; it'll decode anything, but accuracy is not guaranteed. Try something like Media Player Classic Home Cinema. If your file is still flipped backward, then Vegas is doing something weird when exporting to HuffYUV. As a workaround, add the following lines to the end of the AVS script that you use to encode the HuffYUV file to x264:
posted by Inspector.Gadget at 9:21 AM on April 9, 2010
VLC is broken generally; it'll decode anything, but accuracy is not guaranteed. Try something like Media Player Classic Home Cinema. If your file is still flipped backward, then Vegas is doing something weird when exporting to HuffYUV. As a workaround, add the following lines to the end of the AVS script that you use to encode the HuffYUV file to x264:
FlipVertical()
FlipHorizontal()posted by Inspector.Gadget at 9:21 AM on April 9, 2010
Response by poster: Thanks, I'll try that and get back to you!
One more thing, the mp4 file ended up at 2.76 gigs after x264 encoding. Is the function of the Haali Media Splitter that I can "split" that file and create 2 new mp4s without re-rendering or re-encoding? I haven't even opened the file.
As a basis for comparison, can you offer a command line to send via AVS/x264 that would guarantee the file would come in under 2 gigs? Something more specific than the --crf 20 command? I'd like to play with different file sizes, and try 1 file vs. 2 files, before I decide which one to post online.
Thanks again for sharing your vast knowledge.
posted by meadowlark lime at 9:36 AM on April 9, 2010
One more thing, the mp4 file ended up at 2.76 gigs after x264 encoding. Is the function of the Haali Media Splitter that I can "split" that file and create 2 new mp4s without re-rendering or re-encoding? I haven't even opened the file.
As a basis for comparison, can you offer a command line to send via AVS/x264 that would guarantee the file would come in under 2 gigs? Something more specific than the --crf 20 command? I'd like to play with different file sizes, and try 1 file vs. 2 files, before I decide which one to post online.
Thanks again for sharing your vast knowledge.
posted by meadowlark lime at 9:36 AM on April 9, 2010
Response by poster: *Minor correction to above. When I say "I haven't even opened the file", I mean I haven't opened Haali Media Splitter and so I don't know what it does.
posted by meadowlark lime at 9:37 AM on April 9, 2010
posted by meadowlark lime at 9:37 AM on April 9, 2010
Haali Media Splitter, when installed, works to "split" the MP4 container: it sends the video stream to a video decoder and the audio stream to the audio decoder in a playback framework called DirectShow. It is used in playback and in loading files (MKV, OGM, etc.) into Avisynth with DirectShowSource() and DSS2(). It has nothing to do with separating a file into two different files. In fact, for your workflow, I don't think you even need the splitter installed: you merely need AVSS.dll to use DSS2().
You can divide the final MP4 file into size- or timecode-based segments with YAMB as I describe above. Remember, since 2 gigs is the limit for a single file, you can go above this with splitting. I am certain that ~70 mins at 720p30 will not look good with the bitrate limit imposed by a 2 gig max, especially after transcoding again on upload.
To get a given file size, you need to calculate the average bitrate that you can use to encode the file as well as account for audio size and container overhead.
-What is the exact duration of your final project in hours, minutes, and seconds?
-If you have already encoded the audio, what is its file size?
-If you have not encoded the audio, I'll assume the audio length is the same as the video length and will calculate a good audio bitrate for you to use appropriately (VBR for audio is really far superior if it's not eating too much space).
posted by Inspector.Gadget at 9:48 AM on April 9, 2010
You can divide the final MP4 file into size- or timecode-based segments with YAMB as I describe above. Remember, since 2 gigs is the limit for a single file, you can go above this with splitting. I am certain that ~70 mins at 720p30 will not look good with the bitrate limit imposed by a 2 gig max, especially after transcoding again on upload.
To get a given file size, you need to calculate the average bitrate that you can use to encode the file as well as account for audio size and container overhead.
-What is the exact duration of your final project in hours, minutes, and seconds?
-If you have already encoded the audio, what is its file size?
-If you have not encoded the audio, I'll assume the audio length is the same as the video length and will calculate a good audio bitrate for you to use appropriately (VBR for audio is really far superior if it's not eating too much space).
posted by Inspector.Gadget at 9:48 AM on April 9, 2010
Response by poster: Total length is 73 minutes, 19 seconds. Audio is same length. I have not separated or transcoded the audio, it is currently still part of the HuffYUV as uncompressed audio.
Would you be able to give me a command to TRY and make the whole package under 2 gigs, and then another to split it into 2 parts, each one approaching 2 gigs?
The mp4 I've made already was 2.77 gigs, and that's without taking the audio out and recompressing it to Nero. (I would imagine that would save another few hundred megabytes, yes?) So given all that, wouldn't just a little more compression on the video give me a 2 gig file quite neatly?
However, if you are right that I should split it, I will. I figure if I'm going to split it into two ~36 minute parts I might as well make the video quality as high as possible for each part.
I wasn't clear how to use YAMB to split the file, but I will get that program and play with it to see if it's as user-friendly as you see.
This is probably asking too much, but if I'm splitting the whole thing into two parts, will I be able to ADD a title card at the end of part one saying "End part one, please click the link in the sidebar to see part two"? Or will I have to go back into Vegas, add that title card there, and re-render the whole thing out again as a HuffYUV before proceeding?
I've figured out by now that this is a really involved process and I'm willing to take my time to try all variations before I post it online.
posted by meadowlark lime at 12:44 PM on April 9, 2010
Would you be able to give me a command to TRY and make the whole package under 2 gigs, and then another to split it into 2 parts, each one approaching 2 gigs?
The mp4 I've made already was 2.77 gigs, and that's without taking the audio out and recompressing it to Nero. (I would imagine that would save another few hundred megabytes, yes?) So given all that, wouldn't just a little more compression on the video give me a 2 gig file quite neatly?
However, if you are right that I should split it, I will. I figure if I'm going to split it into two ~36 minute parts I might as well make the video quality as high as possible for each part.
I wasn't clear how to use YAMB to split the file, but I will get that program and play with it to see if it's as user-friendly as you see.
This is probably asking too much, but if I'm splitting the whole thing into two parts, will I be able to ADD a title card at the end of part one saying "End part one, please click the link in the sidebar to see part two"? Or will I have to go back into Vegas, add that title card there, and re-render the whole thing out again as a HuffYUV before proceeding?
I've figured out by now that this is a really involved process and I'm willing to take my time to try all variations before I post it online.
posted by meadowlark lime at 12:44 PM on April 9, 2010
2 gigs is going to be borderline if x264 thought the source was compressible enough that even with raw PCM audio you came in under 3 gigs. Your source must be very simple to compress in terms of light on noise/detail. Let's try for 2 gigs, then.
For 79m 19s, you can do video at a bitrate of 3775 kbps per second and audio at 128kbps and come out as 2 gigs exactly. We'll undercut that slightly so you don't come out just over and have to redo the whole thing.
1) First, you need to get your audio out of Vegas. If Vegas can export as a stereo WAV file (with the 48 kHz / 16 or 24 bits of the source audio), then that's the way to go. Raw PCM will work as well.
Get your file in the appropriate format:
or
Next, we need to pass more advanced argument for CBR audio, so:
2) To hit a given bitrate with x264, you must run a 2 pass operation. This is simple enough, but requires that you actually fire off two commands, the second once the first has completed:
Followed by:
3) Once you've run these, you'll have an MP4 video file and an M4A audio file as you did before. You can mux them with YAMB; simply click the topmost bar in the right pane, add the two files (video first; you can put it first with the Up button), and remember to set an audio delay for the audio if for some weird reason you have one that Vegas tells you about (doubtful). Then make sure your output file is named something other than the name of an input file, click next, and wait a few minutes. You now have a file that should pass size muster and be comparable in quality to the first one you encoded.
Addendum) If the video quality sucks, then you can safely double the video bitrate (the audio bitrate will remain the same) when encoding a new file from the HuffYUV source and still come out well under 4 gigs; you can then mux as above and then open YAMB again and use the splitting function to split by file size (the function is intuitive and accessed by clicking the second item in the left toolbar and then the correct entry in the right pane).
If this is the case, then you can add a title card using Avisynth's Blackness() and TextSub() commands in your final HuffYUV->x264 script, but you will have to delay your audio on muxing by the length of the titlecard used in a given file. And of course, delays are cumulative, and you'll need to calculate the split point in advance. You might at that point be better served encoding two separate audio and video files, so that you can eliminate audio delays and split the original WAV file with eac3to before encoding. All in all, I think the title card is a waste given the link-ready interface of Vimeo and my suspicion that their transcoding toolchain is likely to mishandle audio delays in one way or another.
posted by Inspector.Gadget at 8:20 PM on April 9, 2010
For 79m 19s, you can do video at a bitrate of 3775 kbps per second and audio at 128kbps and come out as 2 gigs exactly. We'll undercut that slightly so you don't come out just over and have to redo the whole thing.
1) First, you need to get your audio out of Vegas. If Vegas can export as a stereo WAV file (with the 48 kHz / 16 or 24 bits of the source audio), then that's the way to go. Raw PCM will work as well.
Get your file in the appropriate format:
eac3to somefile.pcm somefile.wav -resampleto44100or
eac3to somefile.wav someoutfile.wav -resampleto44100Next, we need to pass more advanced argument for CBR audio, so:
neroaacenc -cbr 128000 -lc -if somefile.wav -of somefile.m4a2) To hit a given bitrate with x264, you must run a 2 pass operation. This is simple enough, but requires that you actually fire off two commands, the second once the first has completed:
x264 --pass 1 --stats "x264_2pass.log" --bitrate 3770 --tune film --preset slow --thread-input -o somefile.mp4 "C:\users\meadowlark lime\desktop\myproject.avs"Followed by:
x264 --pass 2 --stats "x264_2pass.log" --bitrate 3770 --tune film --preset slow --thread-input -o somefile.mp4 "C:\users\meadowlark lime\desktop\myproject.avs"3) Once you've run these, you'll have an MP4 video file and an M4A audio file as you did before. You can mux them with YAMB; simply click the topmost bar in the right pane, add the two files (video first; you can put it first with the Up button), and remember to set an audio delay for the audio if for some weird reason you have one that Vegas tells you about (doubtful). Then make sure your output file is named something other than the name of an input file, click next, and wait a few minutes. You now have a file that should pass size muster and be comparable in quality to the first one you encoded.
Addendum) If the video quality sucks, then you can safely double the video bitrate (the audio bitrate will remain the same) when encoding a new file from the HuffYUV source and still come out well under 4 gigs; you can then mux as above and then open YAMB again and use the splitting function to split by file size (the function is intuitive and accessed by clicking the second item in the left toolbar and then the correct entry in the right pane).
If this is the case, then you can add a title card using Avisynth's Blackness() and TextSub() commands in your final HuffYUV->x264 script, but you will have to delay your audio on muxing by the length of the titlecard used in a given file. And of course, delays are cumulative, and you'll need to calculate the split point in advance. You might at that point be better served encoding two separate audio and video files, so that you can eliminate audio delays and split the original WAV file with eac3to before encoding. All in all, I think the title card is a waste given the link-ready interface of Vimeo and my suspicion that their transcoding toolchain is likely to mishandle audio delays in one way or another.
posted by Inspector.Gadget at 8:20 PM on April 9, 2010
For 79m 19s,
Sorry, 73m 19s, which is what I correctly used in my calculations (which, unlike the divide by KB method, took account of the MP4 container overhead).
posted by Inspector.Gadget at 8:21 PM on April 9, 2010
Sorry, 73m 19s, which is what I correctly used in my calculations (which, unlike the divide by KB method, took account of the MP4 container overhead).
posted by Inspector.Gadget at 8:21 PM on April 9, 2010
Response by poster: Thank you, Inspector, trying this two-pass method now. Hoping to get my final file in shape today!
posted by meadowlark lime at 11:33 AM on April 10, 2010
posted by meadowlark lime at 11:33 AM on April 10, 2010
I must have been very tired when I posted earlier...
Internet/Standard Definition 640x480, 24 fps 1-2 Mbps
High Definition 1280x720, 24p 5-6 Mbps
Full High Definition 1920x1080, 24p 7-8 Mbps
posted by filmgeek at 11:47 AM on April 21, 2010
Internet/Standard Definition 640x480, 24 fps 1-2 Mbps
High Definition 1280x720, 24p 5-6 Mbps
Full High Definition 1920x1080, 24p 7-8 Mbps
posted by filmgeek at 11:47 AM on April 21, 2010
This thread is closed to new comments.
One thing to watch for is to make sure you are compressing the audio track too, for example to AAC. In the past I had accidentally compressed the video but left audio raw, and my video was bout 10x larger than it needed to be.
1gig for 70 minutes is some pretty serious compression, but like you said, it can be done. Sorry I can't offer a more exact answer.
posted by drjimmy11 at 5:44 PM on April 4, 2010