-
Videoon 4/24/2017
V14 crashes during mp4 -> mpeg2 encode
Thanks for the tip. Meanwhile I tried Vegas again, and this time it ran to 100% and completed OK. Maybe I have a hardware problem? Normally I use Handbrake for any transcoding, but I want to author a DVD with chapter points that start exactly on the specified frame, for which I need the MPEG2 encoder to generate an I-frame at each frame having a chapter marker. Can Handbrake do that? Maybe if I figure out "Import/Export chapter markers" ? Also, ideally Vegas would not crash :-).
-
Videoon 4/24/2017
multicam edit: change one camera's brightness after edit?
Sure enough that works; thanks!
-
Videoon 4/24/2017
multicam edit: remove filename from each take window?
Perfect, just what I was looking for; that fixed it. Thank you!
-
Videoon 4/23/2017
multicam edit: remove filename from each take window?
I don't know if this works, but if so here is a screenshot showing what I'm talking about. https://goo.gl/photos/cY6QWY3M4TkBit3Y7
-
Videoon 12/28/2010
OT: HDC-TM700 HD view finder
I have a FX1 and TM700 but probably won't have time to do a side-by-side in the foreseeable future.. if you do this, remember the TM700 in best quality mode records 1920x1080 at 60 progressive frames per second. The FX1 records HDV at 1440x1080 at 60 interlaced fields per second. So if you want to compare "graininess" you should really use the TM700 in interlaced mode, and then reduce the horizontal resolution to 1440 pixels across, for a more fair comparison.
-
Videoon 12/24/2010
OT: HDC-TM700 HD view finder
It does have great images. My only criticism is that indeed, in auto white balance mode the color can suddenly and drastically shift for no apparent reason.
-
Videoon 12/20/2010
SOT: Shooting the moon and a laser beam?
If there is any atmospheric haze, I think you'll see the outgoing beam (as long as it's visible, and not infrared!) Tiny droplets of water in the air act like retroreflectors, so the the beam will appear brighter the closer you can get to the source laser output. Assuming they are running a fast pulse train, a slow shutter speed should help, or stack together frames in post. You don't have a chance of catching the return beam with your camcorder. If memory serves, they get an average of *one photon* per laser pulse into a lunar retroreflector. And that is with a telescope several feet in diameter... I don't think your lens is that large. They shoot many pulses and average, in order to get a usable signal.
-
Videoon 12/13/2010
exporting chapters to DVDA for BluRay
Thank you for that link. Looks like the same or similar problem exists with Vegas 10, according to user alanfitch: http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=741313&Replies=1 I have to say I'm surprised by this. Chapter marks not available for AVC encoding, which is the only real choice for HD delivery of projects of any length, and it's still not fixed? Are people not using Vegas for making bluray discs?
-
Videoon 8/15/2010
New Full HD Cameras
it takes more CPU time to run the AVC (H.264) codec than MPEG, so editing and rendering will be more sluggish than HDV, on the same system. Overall image quality depends on the camera, but the XR550 and other cameras in that class are quite good.
-
Videoon 8/1/2010
How do we deliver 1920x1080 50p or 60p?
Short answer is for now, you don't, except as data files to play on a fast PC. I have the Panasonic TM700, one of very few consumer cameras available now to shoot 1920x1080 60p. As you have observed, 60p is not yet a widely distributable format. Any sufficiently fast PC can play it if you have the right software, such as the "HD Writer AE" that Panasonic provides, or the Mirillis Splash Lite player, http://mirillis.com/en/products/splash.html Some people report their Sony PS3 can play 60p smoothly, although maybe that is just the newer one. My older non-slimline 40 GB PS3 does not, the video has subtle hiccups which take away the point of using 60p. For now, I am downconverting to 60i for general use playback and distribution. In my experience, the data rate in the H.264 codec between 60i and 60p for "reasonable" image quality is nearly the same! That is because motion estimation at 60p is easy, and (at least with the TM700) there is in-camera noise reduction that takes away almost all random noise (in normal to high lighting). You can read more about the TM700 and about playing back and editing 1080p60 video here: http://www.avsforum.com/avs-vb/showthread.php?t=1248284
-
Videoon 7/30/2010
"error occurred reason could not be determined"
Ah-hah! That's good to know. I'm rendering it in smaller chunks now, which is working. Is there some document somewhere that lists all the currently-known issues with Vegas 9e? (I wasted a full day of trying to render the full thing, each time took about 5 hours to reach the failure point.)
-
Videoon 7/29/2010
"error occurred reason could not be determined"
Thanks for the response. All the drives currently on the system are NTFS. I was wondering about the 4GB limit too, but the output file size went significantly above that limit. It is about 4.60 GB when it quits. I recall a discussion about running out of RAM memory in some cases, but the process seems to hover around 750 MB in the Windows Task Manager, going up and down but never exceeding 800 MB, so that seems ok also. Has anyone seen this "reason could not be determined" type of error? Shouldn't the program at least be able to tell me what module was active at the time of the fault, whatever it was?
-
Videoon 7/28/2010
levels problem when frameserving RGB to MeGUI
Ah yes, thanks again. (Just need to remember to undo any other customizations on the first clip, before copying to all rest.) By the way, I tried making a 1920x1080p29.97 mp4 clip and it plays fine and looks great on my PC, but the PS3 just shows a black screen (although it does have the audio). Is 1080p30 not a format the PS3 can do?
-
Videoon 7/28/2010
levels problem when frameserving RGB to MeGUI
Thanks for the 29.97p and fast-start tips, quite helpful. I see that "disable resample" seems to be a clip property, instead of a global setting. Is there any easy way to disable resample on an entire project at once?
-
Videoon 7/28/2010
levels problem when frameserving RGB to MeGUI
Well, that is interesting. MainConcept AVC generates a .mp4 file that has ALMOST (but not quite!) the same levels as the original. However for some reason, it also decided to give me half the frame rate. My project is 29.97 fps interlaced, and encode format is 29.97 fps nterlaced, and what did I get? This: Video: 00:02:32.486, 14.985 fps interlaced, 1920x1080x12, AVC EDIT: and if I change the timeline to the native format (1080p 59.94 fps) and try to encode 29.97 interlaced, Vegas just crashes ("system low on memory", although it isn't). Has anyone sucessfully encoded TM700 footage (1080p60) to 1080i and lived to tell the tale? EDIT: got it working, by unchecking the box "allow source to set frame rate". Finally.
-
Videoon 7/28/2010
levels problem when frameserving RGB to MeGUI
EDIT: I tried reinstalling Vegas 9e and hey, now MainConcept AVC is there! Apparently something happened to it before; don't know what. By the way I see Vegas uses "QT7PLUG.DLL" to read files of type MP4. I wonder if Quicktime is doing its own unwanted levels shift on import- probably it is. File Properties/General: Plug-In Name: qt7plug.dll Folder: C:\Program Files\Sony\Vegas Pro 9.0\FileIO Plug-Ins\qt7plug
-
Videoon 7/28/2010
levels problem when frameserving RGB to MeGUI
Thanks for the reply; I've sent the email to Nick Hope. Yes, I can do pre-correction but that will give me some posterization, given that each step in the process is quantized to 8 bits. I was hoping there was some simple way to just do it right, and avoid needing to pre-correct. EDIT: I see that if I set Sony AVC/MP4 to MP4 output, it allows 20 Mbps. However when I actually try to render to it, I just get "Error opening codec". I am using Vegas 9e.
-
Videoon 7/28/2010
levels problem when frameserving RGB to MeGUI
ConvertToYV12() results in everything becoming slightly brighter (histogram moves up, as a block). It has the effect of lowering contrast, since there are no more true black areas.
-
Videoon 7/8/2010
trying to understand x.v.Color
In case of interest, I made a video consisting of one frame for each Y' value showing on an xy graph each (Cb, Cr) value. So this is each Y'=constant slice through the 3D Y'CbCr gamut volume. Of course this is in arbitrary "Panasonic TM700" units, not necessarily any well defined standard colorspace. But the input was defined, being all single-wavelength colors over the visible spectrum 400..700 nm. page: http://www.bealecorner.com/TM700/ video: http://www.bealecorner.com/TM700/TM700-YUV-hist1.mp4 You can see that the camera is recording Cb values right out to 255 for Y' in the range (36...80), and we get Cr = 255 at Y' = 77. Cr also reaches down to zero around Y' = (148..190). It would be interesting to compare this (with the same full-spectrum input) to other cameras- haven't had a chance yet.
-
Videoon 6/24/2010
Using Color Scopes Tutorial
thanks for the link, that's a useful reminder about what the scopes are telling us.
-
Videoon 6/23/2010
trying to understand x.v.Color
> You should try looking at the RGB values. I'll try that, but the camera doesn't generate RGB (except I guess via HDMI). I wanted to look at Y'CbCr because that is the actual camera output, what is stored in the .MTS or .m2ts file. The RGB values are generated from that, in my case by the software on my PC that is displaying the MTS file (presumably following REC.709). None of my software speaks the new xyYCC standard, so I presume it is going to clamp R,G,B values to zero and not display negative ones. Sony talks about how the x.v.Color standard can represent negative R,G,B although I suspect no existing camera actually does that.
-
Videoon 6/23/2010
trying to understand x.v.Color
Looking at http://www.bealecorner.com/TM700/TM700-CinemaColorOn.PNG it seems the full spectrum really is chopped into almost pure R,G,B in this camera (except at the brightest point of the R-G border, where things are really saturating). That agrees with other 3-CCD cameras I've looked at. I calibrated the YCbCr image based on the CFL emission lines and generated a plot of the Cb, Cr response vs. wavelength, for pure colors, as you see here: http://www.bealecorner.com/TM700/ The measured (min,max) range for this frame, chosen to be at an exposure giving me maximum saturation values, is Cb: (10,232) and Cr: (28,242) over the full visible spectrum. The normal limit in YUV video encoding is (16, 240), so we aren't exceeding the normal range by a whole lot. I rather suspect Panasonic simply removed the [16,240] chroma range clamp but left the sensor chip and analog electronics precisely the same as in the older, non-"x.v.Color" capable unit. Just a hunch.
-
Videoon 6/21/2010
trying to understand x.v.Color
Hey, thanks for checking out my experiment. Good idea about using a CD as a grating, but I have a "real" rectangular transmission grating and used it to make a grating spectroscope in a long cardboard box. On the slit I had a CFL lamp (for calibration via mercury emission lines) plus a nice bright 200W clear filament lamp as a continuous source. Both shining through some spun diffusion to help illuminate the grating more or less evenly. I added a Vegas screenshot, and the Y,Cb,Cr planes extracted direct from the .m2ts file here: http://www.bealecorner.com/TM700/index.html It looks like we are getting some decent excursions in the Cb, Cr planes. I have to do some more thinking about what that vector scope plot is saying, though. I guess when you feed pure (nearly) single wavelengths into the sensor, you get response from only one CCD at a time (this is a 3-CCD camera with dichroic beamsplitter). So that's why most of the vectorscope is mostly showing me just three directions, I guess those are the primaries of the sensor as seen in vectorscope space. It does seem to exceed 100% saturation especially in the green (lower-left).
-
Videoon 6/17/2010
x.v.Color and the future
Just tried an experiment last night, but with inconclusive results. I took some video clips of a vivid pink rose, and a very deep dusky red rose. Both perfectly "natural" by the way, but strong saturated colors that I do not see on the video screen. For example, looking at the viewscreen by itself the red rose seemed "red", but comparing it with the real thing, the screen looked like a dull muddy orange, so that color is outside the viewscreen gamut, anyway. I tried recording both roses with the x.v.Color mode on and off, on two different cameras (Sony and Panasonic). I played back the video using an Avisynth histogram filter that shows the YCbCr components to see if I was recording any of the nominally "illegal" color ranges in the Cb or Cr components- and I was not; the color histogram did not extend very far either way towards the boundaries. But I suppose it is possible that something in the software (DGAVCDecode or Avisynth) was rescaling the video ranges (?) By the way, if I want to construct a test video with specified values of Y, Cb, Cr for pixels, how could I do that? I can generate RGB and convert that into a YCC video, but I'm not sure how to work directly with YCC if I want to work with Cb, Cr values outside the usual 16-240 range, that might correspond to negative R, G or B components . Maybe I could use ffmpeg to synthesize a clip from raw Y, Cb, Cr bitmap files (?) Note to self, see also: http://en.wikipedia.org/wiki/YCbCr and http://en.wikipedia.org/wiki/XvYCC
john-beale
Offline, Last login 4/25/2017, Member since 4/18/2017