I've exported some footage from premiere to DV using "Microsoft DV AVI".
I've encoded this DV to XviD using StaxRip, but StaxRip cannot encode this dv to h264 with x264. It doesn't let me start the encoding process and says "unsupported colorspace" and "x264 requires yv12 colorspace".
I have no idea what to do. I don't understand why StaxRip has problems with this DV file.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 18 of 18
Thread
-
-
I solved the problem eventualy.
The solution I found is to use AutoGK to encode dv to xvid, and Handbrake to encode dv to h264.
Both AutoGK and Handbrake recognise the input dv immediately, it's format and it's fourcc, without telling me to install haali, ffdshow or other stuff that staxrip keep asking for after opening the dv file. -
-
If it's interlaced, make sure you use ConvertToYV12(interlaced=true)
FYI x264 doesn't require YV12 anymore - It can encode YUY2 (422) , YV24 (YUV 444), RGB, and you can build it with 8-bit or 10-bit support - but your destination might require YV12 (most devices will only support 4:2:0 variant of h.264) -
ok, I returned to MeGUI and added
ConvertToYV12(interlaced=true, matrix="PC.709")
because the source and project are interlaced, but I don't know what matrix to specify
if I don't specify any matrix, the default will be Rec.601
the options are Rec.601, PC.601, Rec709, PC.709 ; how do I determine wich matrix to use ?
-
Generally: if your source is standard def use rec.601, if high def use rec.709.
-
@ jagabo: thanks, but if I my source is SD, and I encoded with "PC.709" instead of "rec.601", is it recommended that I encode it again, this time with "rec.601" ? Or I will not notice the difference ?
-
The difference isn't huge but you may notice it -- mostly in bright reds and greens. Here's a post with some examples:
https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830
A lot of software doesn't pay attention to colorspace flags. So you sometimes have to handle the conversions yourself if you want perfect results. -
The matrix is only used if your input is RGB. Are you sure you need it?
If your input really is RGB, it must have been converted by your DV decoder, since your source is DV (hence YUV). If that's the case, you need to find out what matrix was used in this conversion (probably Rec.601).
"PC.709" differs in two ways from "Rec601".
The 709/601 difference is slight, as jagabo says affecting mostly bright reds and greens.
However the PC/Rec difference is more significant and affects contrast right across the board. -
I used to think there was a contrast/brightness difference between rec601/rec709.
In my case, I blame my old Panasonic TV for this misconception.
When 480p material is received over component, a "color matrix" setting becomes active.
Besides hue/color changes, there is a massive brightness change - the SD setting is much, much darker.
Perhaps just poor TV design? -
No, the levels are the same. Ie, grayscale (luma) levels are treated identically.
Yes, there's something odd with the TV. Maybe an auto contrast feature kicking in?
For the OP:
The Rec matrices adjust the contrast to compensate for the fact that YUV digital video normally has blacks at luma=16, whites at luma=235, but RGB computer monitors have blacks at RGB=0, whites at RGB=255. So when converting from YUV to RGB the contrast is stretched (Y=16-235 --> RGB=0-255) and when converting from RGB to YUV the contrast is squished (RGB=0-255 --> Y=16-235).
The PC matrices don't perform this contrast stretch/squish. -
This is interesting. A while back I had downloaded a music video from the internet, 720*400, XVID AVI.
I wrote a simple Avisynth script,
directshowsource
Histogram
and opened it in Virtualdub. You could see that there was nothing below 16, but there was quite a bit above 235.
I encoded it to mpeg-2 in HCenc to see what would happen, and those luma levels remained in the mpeg-2.
I had thought that HCenc would squish the range to make the highlights be 235 and below.
Using levels in the script like this,
Levels(0, 1, 255, 0, 255) which according to the wiki does this:
# does nothing on a [16,235] clip, but it clamps (or rounds) a [0,255] clip to [16,235]:
and it appeared to put the levels in the proper range.
Is it best to make sure DVD mpeg-2 has levels in the proper 16-235 range, or doesn't it really matter?
PS I didn't mean to hijack the thread, I thought this might be helpful. -
Exactly what happens with super brights (Y>235) depends on the player and the TV, and how the TV is adjusted. Some will crush the super brights (everything over 235 becomes 235 so very bright details are lost). Others will show the super brights as brighter than 235 so you can still see detail up there.
Rather than crushing the top end I would have reduced the contrast. For example, Levels(0,1,255,0,235) or ColorYUV(gain_y=-20) or thereabouts (with either you might have to bring the black level up a bit to make sure the blacks don't go below 16). That way you would assure that the bright areas don't get washed out on any system.
By the way, it's very common for DV camcorders to have excursions into the super brights.
Oh, I just checked, Levels() crushes before scaling. So that won't work. Use ColorYUV() instead.
Levels bars, Y ranges from 0 to 255:
After Levels(0,1,255,0,235):
After ColorYUV(gain_y=-20):
Notice how you still can't see any difference between the two brightest bars after levels(). But you can see a difference after ColorYUV().
I wasn't concerned here about what was happening at the low end. But you can see that ColorYUV(gain_y=-20) has caused the Y=16 bar to drop to Y=15, too dark. So you would need to bring it up a bit. Something like ColorYUV(off_y=1, gain_y=-20).Last edited by jagabo; 3rd Jan 2012 at 10:55.
-
I see what you're saying. By using Levels(0, 1, 255, 0, 255) (coring=true - the default)
Everything above 235 was suddenly made 235 - but your levels statement reshuffles everything and reduces the contrast.
This occurred to me at the time, but I didn't get the result I expected. I'll definitely revisit this
Good info - thanks. -
To do this with Levels(), you need to add 'coring=false'.
With coring=true (the default), input luma is first pre-scaled from [16, 235] to [0, 255], then the levels conversion is performed using the supplied parameters, and finally the output is scaled back from [0, 255] to [16, 235]. -
Jagabo, thanks for the images, I see exactly what you mean. I added your statement to my script and it works
fine with the music video mentioned above. Regarding Gavino's info, appreciate the clarification. I found in my
script that very line commented out where I had tried it, but some reason didn't use it. It also does the job.
This music video seems kind of washed out; I scanned through it in Virtualdub. The video is of a live concert,
so there is a lot of black around the stage, etc. Most of the time the "black" is at level 19 or 20, and only
drops to 16 in one or two frames, from what I can see. I would probably use something like
levels(3,1,255,0,235,coring=false) to give a bit more contrast.
Similar Threads
-
Confused over colorspace (YV12) and DV AVI
By sasuweh in forum Video ConversionReplies: 4Last Post: 30th Sep 2010, 05:34 -
Bitrate vs Size Calculator for x264 for ripping DVD to x264 + AC3
By Bonie81 in forum DVD RippingReplies: 7Last Post: 5th Jul 2010, 18:24 -
What is Native DV(PAL) colorspace? YV12 or YUY2
By Josip in forum Newbie / General discussionsReplies: 7Last Post: 13th Nov 2008, 23:25 -
DVD to DVD: YV12 to RGB to YV12, color problem ???
By cd090580 in forum RestorationReplies: 9Last Post: 24th Oct 2008, 10:16 -
Sony Vegas YV12 colorspace
By MagicSparky in forum EditingReplies: 4Last Post: 8th Mar 2008, 12:40