View Full Version : Splitting by size, revisited
July 20th, 2005, 11:16 AM
Would the following approach be more feasible: In the Save As box, an option to specify max filesize (say 4.5GB by default). When VideoReDo is in the process of outputting the file to disk, keep a running count of how many bytes have been written, and when the threshold has been reached (4.5GB in this example), finish off the current GOP and move on to the next filename, and so on.
I'm not familiar with the inner workings of the software, so what I'm suggesting, or even the theory behind it, may not even be feasible :-)
But.... let me know either way
July 20th, 2005, 09:13 PM
In the lower right corner, there is a little green button labeled "Switch"
When you press this, the display changes from timecode to MB. You can then make cuts and save files based upon size if you prefer.
July 20th, 2005, 10:29 PM
When VideoReDo is in the process of outputting the file to disk, keep a running count of how many bytes have been written, and when the threshold has been reached (4.5GB in this example), finish off the current GOP and move on to the next filename, and so on. Its feasible. There's been some call for auto size splitting in the past, but not much recently.
Would be interesting see if there's demand for it.
July 21st, 2005, 09:43 AM
Hadn't noticed that "Switch" feature before. Very cool.
Using the same technology behind the Switch feature, would it be possible to do an equivalent SeekToTimeMsec COM function but in megabytes?
If that's too complicated, the alternative could be a function that we called after SeekToTimeMsec that gave us the equivalent megabyte position.
iMsec = SeekToTimeMsec(10000)
iMByte = GetCursorMB()
Is any of this possible?
If so, I'll write up a VBS script to split a file into multiple parts (by a specified size in MB) and donate it to the project.
July 21st, 2005, 10:30 AM
Let me think about it for a bit. FYI, the output MB feature in the "Switch" display is only accurate to around to 10% since the VideoReDo mutiplex output can be quite different in size from the input file size. THings like padding, packet size, where frames start, multiple input streams, can all affect the output size calculation.
December 19th, 2005, 05:24 PM
Any thoughts yet Dan?
I'm interested in knowing if your software would be capable of, upon Saving a file, keep a running count of bytes written, then when a designated amount is reached (a user-specified value in the Save dialog, ex. 4.5GB), the current GOP would be closed and then it would start writing to a new file (sequentially named for example, perhaps a number appended to the filename).
The interface changes could be an extra textbox in the Save dialog to specify the threshold (the amount of MB at which it attempts to close the current GOP and move on to the next filename).
As for COM, you could add a function to set the threshold such as objVideoRedo.SetFileSizeThresholdMB(4500), and when you call FileSaveAsEx, it would automatically take into account this number. If it's not set, or set to 0, it would ignore the threshold and write normally.
I don't expect a byte-accurate result (considering that there's a GOP to be closed, and maybe some audio packets scattered a bit further?), but I'm curious to know if this approach could be MB-accurate (or even 10MB, that's still OK in my opinion)
December 19th, 2005, 11:11 PM
i'm curious: why would you want to do an automatic split by size where you can't control where the cut point is? could be in the middle of an important scene, so from my point of view it's not needed at all.
in VRD you can easily see the size of your cuts if you do them manually. this way you can make the cut where you need it to be, not where an algorithm tells you it should be.
December 20th, 2005, 08:02 AM
A slightly off-topic response to this also would be don't pick anything above 4GB. You can't write anything larger to rewritable media as a data file (at least all of my utilities told me it was impossible after I saved some HD programs to single files)
December 20th, 2005, 09:28 PM
Harry, of course from your viewpoint it's not needed. That's because you're not me, and you're not using VideoReDo the same way I am =) If VideoReDo was custom-tailored to a single person's own viewpoint, we wouldn't have a very comprehensive piece of software, would we now?
Zaphod, you could potentially split your video into 1GB chunks (similarly to the way DVD authoring does it). You could then burn your 1GB chunks onto a DVD-R disc. Of course, to split a video into 1GB chunks would be a bit of a pain without the feature I'm after ;-)
The reason I'm looking for this feature is to cut a large (> 4.5GB) MPEG2 file in order to span it across multiple DVD discs.
And no, Harry, in my specific case, it doesn't matter if it cuts in the middle of an "important scene".
I'd like to hear from Dan on this, if possible! Where are ya Dan?!? =)
December 20th, 2005, 10:07 PM
if it isn't imporant whether it cuts in an important scene or not, i'm interested in what's your use case with such a feature. if it's simply backup, you can as well use a packing program like winrar to split your files. with a packer you can join them seamlessly together if you want to have them back on your hard disk.
besides there are several problems with the feature like eg the dvd iso format allows file sizes of maximum 2gb. so you would have to save it in udf which not every player is capable of.
if you really do need it, you can as well use freeware tools. in my early days of dvd cutting/authoring i remember there were several tools which can achieve what you want. i think one of them was vobsplit.
December 21st, 2005, 07:01 AM
HJSplit also does a nice job.
December 21st, 2005, 08:57 AM
I have used HJsplit and can recommend it also--has a very nice featureset, and is free.
December 21st, 2005, 11:26 AM
Harry, looking into VOBsplit, looks pretty promising.
December 21st, 2005, 11:48 AM
For anyone who ends up at this thread looking for what I was looking for, you might want to try http://www.geocities.com/anasto.geo/vobspl11.zip. It's VOBsplitter for DOS, but at least this way you can do some automation via a batch file. Note that you'll also be limited to 8.3 filenaming.
April 30th, 2006, 03:46 PM
First of all, VRD is an awesome product. Thanks a lot for creating such a versatile tool.
Its feasible. There's been some call for auto size splitting in the past, but not much recently.
Would be interesting see if there's demand for it.
Well, here's another request for autosize splitting. At this moment I join and split TS files with HDTVtoMPEG2. However, remuxing with VRD is often necessary to solve problems in the stream. It would be great if remuxing, editing and easy splitting would be possible in one pass. That would save a lot of time.
So I hope an autosize split feature will find it's way into VRD.
April 30th, 2006, 10:18 PM
HJSplit has an annoying bug in that it uses one directory only for in/out only. Has a 4gig file limitation in the Pro version, tghis version is meant to allow for different in/out folders. But is no use with 4gig file in/out limits. Yes it is a good cutter/joiner tool, which has been un-needed for a very long time. Since vrd is able to do it better, and smarter.
April 30th, 2006, 10:20 PM
Bearing in mind i need to manually choose where the cut will take place. I'm not into vrd automation, of cutting any frame scenes at all.
How could vrd know where is the correct place, i would like a cut to be !!
May 5th, 2006, 10:25 PM
I also have a need for an automated way to split video files, particularly from the command line. Here's why. I don't live where my recording PC is. That PC records ATSC and satellite receiver captures using BeyondTV. I then process them through VRD, either QSF or commercial cutting. The file then gets fed to Dr. Divx, and finally gets transferred over the internet to my location. If I have to wait for the "whole" video to complete at each step, that takes much longer than feeding pieces at a time through the process. The "pieces" need to be legitimate MPEGs, not just split files.
May 7th, 2006, 12:08 PM
If all you want to do is auto split from the command line, that's pretty easy to do with our com interface. Do you have any programming knowledge?
May 7th, 2006, 04:20 PM
Just enough to be dangerous and only if you count BASIC, FORTRAN, PASCAL and ASSEMBLER 25 years ago in college! I've been playing around with DOS scripts for automation, but that's about the extent of it currently. I wish I knew VB.
May 7th, 2006, 05:30 PM
Just enough to be dangerous and only if you count BASIC, FORTRAN, PASCAL and ASSEMBLER 25 years ago in college! I've been playing around with DOS scripts for automation, but that's about the extent of it currently. I wish I knew VB.That qualifies you to be dangerous!
There are two things to look at.
1) VRD can be automated via the COM interface. Here are the specifics on the COM interface: http://www.videoredo.com/COM%20Interface.htm
2) Take a look at the vp.vbs script in your videoredo installation folder. This is the cscript that videoredo runs from batch. You'll see that it uses the COM interface.
How exactly do you want to split the output? I'm sure we can offer some pointers.
May 7th, 2006, 11:37 PM
if you have constant bitrate i think the autosize splitting should be fairly easy.
if you have my vrd tools + source which i posted some time ago, you could easily get the file size, call a slightly modified method for automatic chapter creation, then split file by chapters.
variable bitrate would need some heuristics though ... unless: vrd does show the position (in mb), maybe it's possible that Dan implements a getter for that position value? you could approach a certain position, check the mb and if it fits, add a chapter, head on to the next position, after all is done split by chapters.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.