VideoHelp Forum
+ Reply to Thread
Results 1 to 18 of 18
Thread
  1. 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.
    Quote Quote  
  2. Add "Convert To YV12" filter on the filter box.
    Quote Quote  
  3. 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.
    Quote Quote  
  4. Originally Posted by codemaster View Post
    The solution I found is to use AutoGK to encode dv to xvid, and Handbrake to encode dv to h264.
    That's a waste of time and results in more quality loss. Use epsilonalpha's solution instead.
    Quote Quote  
  5. 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)
    Quote Quote  
  6. Oops, wrong thread.
    Quote Quote  
  7. ok, I returned to MeGUI and added

    ConvertToYV12(interlaced=true, matrix="PC.709")
    after AviSource("path_to_signpost_avi_file")

    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 ?
    Quote Quote  
  8. Generally: if your source is standard def use rec.601, if high def use rec.709.
    Quote Quote  
  9. @ 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 ?
    Quote Quote  
  10. Originally Posted by codemaster View Post
    @ 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.
    Quote Quote  
  11. Member
    Join Date
    Jul 2009
    Location
    Spain
    Search Comp PM
    Originally Posted by codemaster View Post
    ok, I returned to MeGUI and added
    ConvertToYV12(interlaced=true, matrix="PC.709")
    after AviSource("path_to_signpost_avi_file")
    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 ?
    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).

    Originally Posted by codemaster View Post
    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 ?
    "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.
    Quote Quote  
  12. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    Originally Posted by Gavino View Post
    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?
    Quote Quote  
  13. Originally Posted by davexnet View Post
    I used to think there was a contrast/brightness difference between rec601/rec709.
    No, the levels are the same. Ie, grayscale (luma) levels are treated identically.

    Originally Posted by davexnet View Post
    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?
    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.
    Quote Quote  
  14. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    Originally Posted by jagabo View Post
    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.
    Quote Quote  
  15. Originally Posted by davexnet View Post
    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:
    Click image for larger version

Name:	org.png
Views:	1333
Size:	1.9 KB
ID:	10357

    After Levels(0,1,255,0,235):
    Click image for larger version

Name:	levels.png
Views:	1327
Size:	1.8 KB
ID:	10358

    After ColorYUV(gain_y=-20):
    Click image for larger version

Name:	coloryuv.png
Views:	1406
Size:	1.9 KB
ID:	10359

    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 11:55.
    Quote Quote  
  16. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  
  17. Member
    Join Date
    Jul 2009
    Location
    Spain
    Search Comp PM
    Originally Posted by jagabo View Post
    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).
    ...
    Oh, I just checked, Levels() crushes before scaling. So that won't work. Use ColorYUV() instead.
    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].
    Quote Quote  
  18. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!