mpg from bmp stills preserving digital 1-255?

[shorton]

Hi guys:

I'm trying to make my own calibration disc. I need to create some mpeg2 streams for use in my authoring software. I would like to create these from bmp's I create. I need to include Below black/above white digital 1-15 236-255 data, but all of my tools clip to 16-235 and adjusts all colors to fit.

Can I use avisynth to produce such a clip without changing the colors? I am obviously no expert, and I found a few threads where Wilbert seemed to be dealing with this issue for unrealted reasons and solved it. But it was over my head.

Is it possible, and if it is, can someone help me through how to do it? I can create the bitmap in whatever mode is appropritate.

Thanks,
Scott

[Wilbert]

Just open the bmp in AviSynth and convert it to YUY2. Thus

ImageSource("file.bmp") # RGB
ConvertToYUY2() # RGB [0,255] -> YUY2 [16,235]


How did you create them without AviSynth?

[shorton]

Just open the bmp in AviSynth and convert it to YUY2. Thus

ImageSource("file.bmp") # RGB
ConvertToYUY2() # RGB [0,255] -> YUY2 [16,235]


How did you create them without AviSynth?Wow. Everywhere else I asked they said "you can't" do this at all. This is encouraging indeed. That seems much too easy :) Surely there's more to it, can you elaborate for this poor noob?

To answer your question and maybe shed some more light on my skill level, the way I tried it was:

First try was:
Using Adobe Premier Pro importing the stills, creating an AVI, and encoding it.
I have the Mainconcept encoder (integrated and standalone).
Failed, levels were changed.

Second try was:
1. Create the bmp in photoshop.
2. Import it as an asset into DVD Maestro (which will accept bmps). Tried as both a timed clip and a single image (VUOB?) forget the name of that option.
3. Complie the DVD and test against a reference commercial DVD.
Failed, levels were changed.

Third try:
1. clip out a piece of the commercial DVD using DVD Shirink
2. Demux it with rejig.exe
3. Import the resulting m2v as an asset and compile the DVD
That appears to have worked. But I can't go sharing this since it's got the commercial stuff in it. I'd like to freely share my calibration disc if I can get it right.

So, based on my attempts, I concluded that DVD Maestro was transcoding the stills, but not the m2v.

Leaving me to the problem of how to create a m2v out of my stills without affecting their RGB levels.

What I'm ultimately after first is to make an Avia-like brightness pattern, only with moving blacker than black bars. Avia does not have BTB, DVE does but DVE is not animated (no moving bars). I also need to make some animated color test bars.

This means I'll need to animate my stills, but I'll get over that hump later. Need to get a flat, static still into a m2v unchanged first.

Thanks very much for the time to help. My apologies for being technically behind on the subject; laymens treatment is especially appreciated.

Scott

[shorton]

Wilbert:

ConvertToYUY2() # RGB [0,255] -> YUY2 [16,235]

After looking harder at your suggestion, I'm not sure I communicated what I want properly. Logic loks like I'm doing the opposite of what I want. I want to go from 0,255 to 0,255. But I don't understand the function (yet) so just in case, let me elaborate on what I'm trying to do with an example:

Create a bmp with 4 blocks on a video black background (16/16/16)

BlockNo RGB value
1. 0/0/0
2. 16/16/16
3. 235/235/235
4. 255/255/255

Get that into a m2v file

Create a DVD, play it back, capture an image of the playback, measure the 4 blocks. Each should have it's original levels unchanged. Same as the original DVE disc does.

Does that help?

[Wilbert]

Does that help?
No. The problem is the following. You can create YUV [0,255]. Remember the color format of a m2v is always stored as YUV (not RGB), so there's always a conversion. But when you play it back it is clipped (= rounded) to YUV [16,235] before converting back to RGB [0,255]. (It always converts back to RGB during playback.) This implies you will loose luma.

If you do what i say it is scaled back to RGB [0,255] during playback. Just try it, it should work.

[shorton]

If you do what i say it is scaled back to RGB [0,255] during playback. Just try it, it should work.Thaks for the explanation, I believe I understand the reason now. I'll go figure out how to give it a try. May have to report back for help. I'll post my result either way. Thanks again.

On a side note, I saw in a thread where you were measuring the colors on a picture. Any easy way to do that? Or a thread where someone already discussed how to do it? Looking for a better way to measure the levels of my result.

[shorton]

Wilbert, et.al:

OK. I muddled my way through creating the avi. I did it with:

ImageSource("test.bmp", end = 30, fps = 29.97) # RGB
ConvertToYUY2() # RGB [0,255] -> YUY2 [16,235]

Adjusting the ImageSource function to keep the length smaller

I installed Virtualdub and played the avs file with it. In VirtualDub I chose "save as avi" and generated an avi. So far so good. But...

How can I get it to m2v without hosing the colors? I have the Mainconcept standalone encoder, but I believe encoding with it changed the colors. I authored and played the resulting VOB, captured a bmp from that and the levels on black (16) went to 18. Is there a way to go straignt to mpeg?

Feel like I made some progress, but I'm still not able to get to the final DVD.

Thanks,
Scott

[Wilbert]

How can I get it to m2v without hosing the colors? I have the Mainconcept standalone encoder, but I believe encoding with it changed the colors. I authored and played the resulting VOB
You used MainConcept to encode to VOB? Shouldn't you get a mpeg file?

On a side note, I saw in a thread where you were measuring the colors on a picture. Any easy way to do that?
If you want to measure the colors of a mpeg file, you can open the mpeg file in DGIndex, and create an index (d2v) file. Open this index file in AviSynth:

Mpeg2Source("file.d2v")
ColorYUV(analyze=true)


This gives you the average luma and so on.

[SeeMoreDigital]

Is this 1024x576 PNG sample any use to you?

http://img370.imageshack.us/img370/3318/greyscaletest0166ph.th.png (http://img370.imageshack.us/my.php?image=greyscaletest0166ph.png)


Cheers

[shorton]

You used MainConcept to encode to VOB? Shouldn't you get a mpeg file?Yes, When I encode the avi built with built with Avisynth and VirtualDub, using Mainconcepts's encoder I choose elementary video and get a mpeg file (m2v IIRC). Then I use DVD Maestro to author and create the VOB. If I use a rip of the commercial test disc, and recreate the VOB using DVD Maestro, the result comes out correct, so i appears DVD Maestro is not doing any fiddling withthe colors when multiplexing to VOB.

I have the original "Digital Video Essentials" which has a pattern on it that includes below black (and above white) test bars. It is these bars I'm trying to replicate. Creating the bmp is elementary, getting the end result of a VOB that spits the same thing back out has me stumped.

I have noticed though that when I view the commercial Digital Video Essentials VOB using VirtualDubx, that both the BTB and WTW are clipped. A frame capture and measure confirms it. I've asked on the Virtualdub forum how to prevent virtualdub from clipping these values.

If you want to measure the colors of a mpeg file, you can open the mpeg file in DGIndex, and create an index (d2v) file. Open this index file in AviSynth:

Mpeg2Source("file.d2v")
ColorYUV(analyze=true)


Thanks, I will try that. That might be revealing when I check the commercial disc.

Is this 1024x576 PNG sample any use to you?No, I can make the png or bmp, I just can't get the end result to spit out the below black levels I put in the bmp to start with. But a pattern similar to your's is the jist of what I'm trying. You know the whole process on how to get it to mpeg/vob out of that pattern so the below black is passed?

[SeeMoreDigital]

Is this MPEG-2/VOB PAL 720x576 Grey Scale Test (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/PAL_720x576_Grey_Scale_Test.7z) sample any use to you?


Cheers

[shorton]

Is this (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/PAL_720x576_Grey_Scale_Test.7z) sample any use to you?Thanks for the clip, I'll take a look at it tonight. But my main need is to be able to generate the VOB myself using the patterns I create. Also, I'm in NTSC land which is the root of this levels problem I believe <smile>.

[Inc]

Its quite funny how SAPs in diff. internal Modes do behave. So thats also an issue. As may some models do treat Colorconversions internally different.

If I do feed my SAP (Cyberhome 505) using for example the THX testing part of some Lucas DVDs the following results:

- Cyb.505 in internal "called" RGB output via Scart: The Total-Black Shadow behind the "THX" Logo is luma-cropped! but sharp picture.
To me imho that means: Cropping to 16-235, convert(expand) to rgb 0-255

- Cyb.505 in internal "called" Fbas output (yes only that and rgb/scart are available in the OSD ;) ) via Svideo: The Total Shadow behind the "THX" is noticable! but blurrier Picture.
T me that means: NO cropping is used.

IIRC the Data on the THX chart seemed to be YUV 0-255 coded but Im not really shure now.

[shorton]

>>IIRC the Data on the THX chart seemed to be YUV 0-255 coded but Im not really shure now.<<

Yep, that's the black shadow I'm trying to encode. If it's YUV 0-255 it woudl make sense to me, but damn if I can manage to make it. Haven't given up yet, but I'm learning WAY more than I want to trying to lick it :).

Cheers

[Wilbert]

ImageSource("file.bmp") # RGB
ConvertToYUY2(matrix="PC.601") # RGB [0,255] -> YUY2 [0,255]; for CCE
#ConvertToYV12(matrix="PC.601") # for QuEnc

encode with CCE or QuEnc. That should do it.

[SeeMoreDigital]

Thanks for the clip, I'll take a look at it tonight. But my main need is to be able to generate the VOB myself using the patterns I create. Also, I'm in NTSC land which is the root of this levels problem I believe <smile>.I've been meaning to generate an NTSC version... I'll work on it later and provide a sample!

I would be most grateful if you guys could try it in your NTSC players.


Cheers

[SeeMoreDigital]

Okay...

Here's my MPEG-2/VOB NTSC 720x480 Grey Scale Test (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/NTSC_720x480_Grey_Scale_Test.7z) sample...


Cheers

[mic]

FWIW & all...

In NTSC you won't be able to produce a TV signal that used both extremes, 0 & 255; if I'm not mistaken those voltages aren't available. There is a more definite loss in NA NTSC BB because it starts higher then other parts of the world. You can get above 235 & below 16 though. This should just mean some conversion will take place in sap, so test. Some sap offer expanded or relaxed (take your pick:)) specs sometimes called super black.

In my experience, be aware that setting your TV to display bb *might* throw off display of 16 - 235 material.

Many stand alone encoders will enforce standards complience, those intended for more pro use often don't. Some DVD authoring apps like DVDA will work well re: test patterns by importing bmp in png format (or ripped m2v) to menu background.

If posted samples don't work for you, use Wilbert's code. :)

[shorton]

FWIW & all...

In NTSC you won't be able to produce a TV signal that used both extremes, 0 & 255; if I'm not mistaken those voltages aren't available. There is a more definite loss in NA NTSC BB because it starts higher then other parts of the world. You can get above 235 & below 16 though. This should just mean some conversion will take place in sap, so test. Some sap offer expanded or relaxed (take your pick:)) specs sometimes called super black.

In my experience, be aware that setting your TV to display bb *might* throw off display of 16 - 235 material.

Many stand alone encoders will enforce standards complience, those intended for more pro use often don't. Some DVD authoring apps like DVDA will work well re: test patterns by importing bmp in png format (or ripped m2v) to menu background.

If posted samples don't work for you, use Wilbert's code. :)Mic, you have a point about the limits. What I really need to display is 5% over and under, not actually 0-255. So I need to display from 5 to 246. That's what' son the commercial disc. Calibrators don't usually set the displays to display the below black, but for devices that can display it, it gives a clear demarcation point of wher eteh floor *should* be. Takes out some of the guesswork. That's the reason it's there. For above white, calibrators defer to personal tastes, but on digital displays that show it, like my projector, most calibrate so the 5% above white is visible.

[shorton]

Okay...

Here's my MPEG-2/VOB NTSC 720x480 Grey Scale Test (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/NTSC_720x480_Grey_Scale_Test.7z) sample...


CheersSeemoredigital: Your sample appears to work. I'm having some troulbe measuring and a friend is checking on his HTPC, but I played yours with VirtualDubmpeg and captured a frame. Put that in photoshop and measured the RGB's (eydropper tool). Every one of them was right except, 4 measured 3 and 230 measured 229.

Now, can you tell me how I can do it with my pattern? PM me if you like, beeer and pizza fees etc. would be graciously offered :D

Thanks,
Scott

[shorton]

Okay...

Here's my MPEG-2/VOB NTSC 720x480 Grey Scale Test (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/NTSC_720x480_Grey_Scale_Test.7z) sample...


CheersSeeMore: I just found out something very interesting. Thanks to Wilbert I tried using DGIndex to check the levels on a VOB. I opened the VOB of the commercial calibration disc. Note that this pattern has 2 out of normal range bars, above white and below black (5 & 246). I set DGIndex to Video, YUV->RGB, TV Scale. Then I captured a bmp file and opened it in photoshop to measure RGB using the eydropper. The above/below bars measure correctly (5/246) and the video black and video white bars (16, 235) also measure correctly. This in itself is a big step forward for me. Finally a tool that I can apparantly use to measure and compare to the commercial disc.

OK, that behind me, I opened your pattern. Same settings, same measurements. Your's measures wrong when set to TV scale and captured (low). When I set to DGIndex to PC scale and capture, your bars measure correct as per your markings (except for 4 and 230 which are off by 1).

This seems to be progress anyway. You know how to make a pattern that behaves like the commercial disc?

I did not ignore Wilbert's instructions. I'm just having to figure out how to use the other encoders and avisynth at the same time. I used to the Mainconcept one...

There is progress! Thanks for hanging in here with me guys. Patience appreciated.

Thanks! Scott

[shorton]

OK guys, I'm so close I can taste it :D.

Here's what I did:

Follwoing Wilbert's code,
ImageSource("test.bmp", end = 30, fps = 29.97) # RGB
ConvertToYV12(matrix="PC.601") # for QuEnc

Discovered I could open the avs file directly in QEnc so I did. Generated the m2v file. Opened it in DGIndex, captured a bmp, measured it in Photoshop.

It looks like it was right!!. I'm beat, off to get some rest then followup tomorrow. Hoping I did'nt do something wrong and I only *think* it works...:D

Edit: Naaa couldn't go to bed this close :). Went on and authored a DVD using the m2v generated above. Then I opened it in DGindex, captured a bmp and measured it in Photoshop. It appears to have gone full circle (bmp->m2v->vob->bmp) and it is still in-tact, measuring properly! And BTW and WTW looked the way they are supposed to.

Now I have something to go to sleep on. <big smile>

[shorton]

Hi guys:

I thought I had this licked but I'm still getting some small errors on my resulting color output compared to the RGB I started with. A YUV guru looked at my output and saw I had some errors in the YUV values. He's given me a raw YUV file instead of my BMP to try.

We are trying to find where the errors are being introduced. He knows less about avisynth than I do and he wants me to feed a raw YUV file he's given me through QuEnc. He also gave me a .sif file to try.

Can someone tell me how I can process the YUV file throught QuEnc (or any other method). My objective is to go from YUV to DVD mpeg2 without changing the digital YUV values.

An example of what I'm trying to fix is this. Take a 75% green pattern bmp and convert the RGB to YCbCr:

Ey = 0.587 * 0.75
Y = (219 * 0.44025) + 16
Y = 112.41475
Y = 112

Ecr = -0.419 * 0.75
Cr = (224 * -0.31425) + 128
Cr = 57.608
Cr = 58

Ecb = -0.331 * 0.75
Cb = (224 * - 0.24825) + 128
Cb = 72.392
Cb = 72

So correct YCbCr should be 112, 72, 58

My file 75green.bmp is a green frame with green = RGB 16,180,16

But if I feed QuEnc my .avs script:

ImageSource("75green.bmp", end = 30, fps = 29.97) # RGB
ConvertToYV12(matrix="PC.601")

Then look at the YUV values using mpeg2decode, we get 112, 74, 60 which is wrong, and should be 112, 72, 58.

So I want to skip the RGB to YUV conversion and feed YUV directly. Can someone help me do that? It looked like the rawsource filter might do it but it was over my head. For starters I need NTSC output.

Here is a link to a sample YUV file he's like me to try:
http://tn1.companypostoffice.com/scott/ycsd.yuv

Thanks very much for the help.
Scott

[Wilbert]

Quick response. I will look at your yuv file tomorrow.

ImageSource("75green.bmp", end = 30, fps = 29.97) # RGB
ConvertToYV12(matrix="PC.601")

Then look at the YUV values using mpeg2decode, we get 112, 74, 60 which is wrong, and should be 112, 72, 58.
No, you should get 112.3, 73.7 and 59.3.

Let's look at your formulas. You will get the factors 219 and 224 if you are converting to CCIR. But you aren't, so i don't know what they are doing there. The correct formulas are:

Y = 0.299 * R + 0.587 * G + 0.114 * B = 112.3
U = 0.5*(B - Y)/(1-0.114) + 128 = 73.7
V = 0.5*(R - Y)/(1-0.299) + 128 = 59.3

see also http://www.avisynth.org/ColorConversions

I'm not sure why you get V=60 in your measurement. Perhaps AviSynth is making an rounding error somewhere.

[shorton]

Quick response. I will look at your yuv file tomorrow.


No, you should get 112.3, 73.7 and 59.3.

Let's look at your formulas. You will get the factors 219 and 224 if you are converting to CCIR. But you aren't, so i don't know what they are doing there. The correct formulas are:

Y = 0.299 * R + 0.587 * G + 0.114 * B = 112.3
U = 0.5*(B - Y)/(1-0.114) + 128 = 73.7
V = 0.5*(R - Y)/(1-0.299) + 128 = 59.3

see also http://www.avisynth.org/ColorConversions

I'm not sure why you get V=60 in your measurement. Perhaps AviSynth is making an rounding error somewhere.Thanks Wilbert for having a look at it. Much appreciated. I have some programming ablilites, but not in C. I tried to take a look at the source code to trace the calc and see if I could find where a rounding error might occur but the code was too far out of my skill level to see it.

Also, I tried to relate the Poynton information linked in the reference section of "colorconversions" (part 29) to derive the equations above but didn't see it. I'll study some more...

Thanks again, Scott

[SeeMoreDigital]

Hi Scott,

Just to let you know.... I created my MPEG-2 samples using a payware application called JPGAvi (http://www.ndrw.co.uk/) inconjunction with FFdshow's MPEG-2 in AVI codec.


Cheers

[drmpeg]

The correct formula for video level RBG to YCbCr conversion (from page 18 of Keith
Jack's Video Demystified) is:

Y = 0.299R + 0.587G + 0.114B
Cb = -0.172R - 0.339G + 0.511B + 128
Cr = 0.511R - 0.428G - 0.083B + 128

You have to scale the coefficients for Cb and Cr because the range of Cb and Cr is
16 to 240, not 16 to 235. If you rewrite the previously posted formula:

Y = 0.299 * R + 0.587 * G + 0.114 * B
U = 0.5*(B - Y)/(1-0.114) + 128
V = 0.5*(R - Y)/(1-0.299) + 128

You get:

Y = 0.299R + 0.587G + 0.114B
Cb = -0.169R - 0.331G + 0.500B + 128
Cr = 0.500R - 0.419G - 0.081B + 128

But the coefficients for Cb and Cr must be scaled by 240/235, bringing the formula to:

Y = 0.299R + 0.587G + 0.114B
Cb = -0.172R - 0.339G + 0.511B + 128
Cr = 0.511R - 0.428G - 0.083B + 128

The avisynth color conversion for video RGB is using the unscaled version of the formula, which is a bug (presumably for REC 709 also).

Ron

[Wilbert]

The avisynth color conversion for video RGB is using the unscaled version of the formula, which is a bug (presumably for REC 709 also).

edit for the second time: Ok, i understand your point. First, i assume you know that there are two conversion in AviSynth:
RGB [0,255] <-> YCbCr [16,235] and RGB [0,255] <-> YCbCr [0,255]
and we are talking about the second conversion.

Hold on, i will get back to this later today ... :)

[shorton]

Thanks Willard.

Ideally if I an send a raw YCbCr file via avisynth to CCE that would be great. I tried sending the bmp's directly to CCE and had some sucess. It is using the formula I prefer, or close to it, but it's truncating decimals instead of rounding.

Thanks again for the help,
Scott

[Wilbert]

shorton, i like to know the frame size (352x288 ?) and the colorformat of your yuv file.

[shorton]

shorton, i like to know the frame size (352x288 ?) and the colorformat of your yuv file.The other guy gave it to me to try, I don't know, I've emailed him to ask. I'll reply the instant I know. Or he may reply himself here.

On a different but related topic, is there anyone here that would be interested (able) to run that rounding error discussed above to ground and repair it? I looked at the source, but it was too much C for me, I didn't see it.

Thanks! Scott

[drmpeg]

shorton, i like to know the frame size (352x288 ?) and the colorformat of your yuv file.
It's a 720x480 4:2:2 YCbCr file in headerless planar format (720*480 bytes of
Y, followed by 360*480 bytes of Cb and then 360*480 bytes of Cr). It looks
like the file on Scott's website has been corrupted by CR/LF characters, so
I've posted the correct version on my website:

http://www.w6rz.net/ycsd.yuv

To be honest, it was a complete shot in the dark. I also sent Scott a 4:2:0
file in the same headerless planer format (except 360*240 bytes of Cb and
Cr), and that didn't work either. I'm guessing QuEnc requires a file with a
FourCC header or something like that.

Wilbert, could you provide a test YCbCr file that works with QuEnc? Also,
Scott is now using CCE, so a YCbCr file for CCE (if it's different than QuEnc)
would also be very much appreciated.

Ron

[SeeMoreDigital]

I managed to open the YCSD.YUV image using XnView... and it reports it as being 720x576 pixels: -

http://img301.imageshack.us/img301/5595/imagesample5at.png


Cheers

[Wilbert]

It's a 720x480 4:2:2 YCbCr file in headerless planar format (720*480 bytes of Y, followed by 360*480 bytes of Cb and then 360*480 bytes of Cr).
Ah, thanks. I always use the plugin RawSource (http://www.avisynth.org/warpenterprises/#rawsource) to open my uncompressed clips. But 4:2:2 planar is one of the few formats which is not supported :) I will add that format to RawSource. In the mean time:
I also sent Scott a 4:2:0 file in the same headerless planer format (except 360*240 bytes of Cb and Cr), and that didn't work either.
is supported and can be opened as follows:

RawSource("c:\clip.yuv", 720, 480, "YV12")

Then you need to convert it to YUY2 before encoding with CCE (luma will be left untouched in that case):

RawSource("c:\clip.yuv", 720, 480, "YV12")
ConvertToYUY2()


I'm guessing QuEnc requires a file with a
FourCC header or something like that.
I thought QuEnc can only open AviSynth scripts?

[shorton]

Wilbert: Thanks for considering adding the new format to Rawsource.

Ron: I'm standing by. I presume by using Rawsource we can skip the Avisynth Convert() BMP to YUV conversions that don't agree perfectly with the BT601 formulas you recommend. I have the current version of Rawsource (20051007) and if Willard has time to add support for the other format I'll grab that one right away.

As I understand it (correct me if I'm wrong), with rawsource we should be able to import the YUV files you created directly. Or at least we are on our way to identifying a format that won't need conversion. With rawsource I should be able to feed YV12 to QuEnc, or YUY2 to CCE. And in either case, no RGB->YUV conversion will take place so we can eliminate that issue.

I tried the files you originally sent mentioned above (both attached). We know the latter won't open with Rawsource (yet), so I tried the first one you sent. If I change the framsize to 360, 240 in Rawsource (guessing), it will encode but it is not right. It's wavy lines (garbage). So just for grins I tried 720, 480 and that crashes both QuEnc or CCE. Getting closer :)

Thanks guys,
Scott

[shorton]

Wilbert:

It just dawned on me that I'm not opening clips with multiple frames, I'm opening single frame images and building video clips with them. So far I've used

ImageSource("somefile.bmp", end = 59, fps = 29.97)

to get just the right number of frames depending on my need (I need either 2 frames or 60). And this works exactly as I need it to since I'm chaining several images together for some animated clips.

Can you tell me how I would use Rawsource and other filters if necessary to accomplish the same thing?

Update for Archive: Wilbert showed me how to do this particular thing here:
http://forum.doom9.org/showpost.php?p=722657&postcount=4

[drmpeg]

Scott,

Can't see your attachment. The correct file I sent you to try is wbars.yuv

http://www.w6rz.net/wbars.yuv

It is in the 4:2:0 planar format that RawSource("c:\wbars.yuv", 720, 480, "YV12") supports.

However, this is not really the format that we ultimately want to use since we're doing
4:2:2 to 4:2:0 conversion several times. Ideally, we should be able to send CCE a raw 4:2:2 file and let CCE do the 4:2:2 to 4:2:0 conversion once.

The file ycsd.SIF

http://www.w6rz.net/ycsd.SIF

is in Cb Y Cr Y format which should also be supported by RawSource("c:\ycsd.SIF", 720, 480, "UYVY").

Ron

[shorton]

http://www.w6rz.net/wbars.yuvIt is in the 4:2:0 planar format that RawSource("c:\wbars.yuv", 720, 480, "YV12") supports.I tried that one. To be thorough, I D/L'd it again and gave it another try. Trying to serve that file crashes either encoder.

However, this is not really the format that we ultimately want to use since we're doing
4:2:2 to 4:2:0 conversion several times. Ideally, we should be able to send CCE a raw 4:2:2 file and let CCE do the 4:2:2 to 4:2:0 conversion once.

The file ycsd.SIF
http://www.w6rz.net/ycsd.SIF
is in Cb Y Cr Y format which should also be supported by RawSource("c:\ycsd.SIF", 720, 480, "UYVY").

OK, hopefully Wilbert can get it to read that format.

Best, Scott

[Wilbert]

@shorton,
Originally Posted by drmpeg
http://www.w6rz.net/wbars.yuvIt is in the 4:2:0 planar format that RawSource("c:\wbars.yuv", 720, 480, "YV12") supports.
That one works, although it should be "I420" I think..

The file ycsd.SIF
http://www.w6rz.net/ycsd.SIF
is in Cb Y Cr Y format which should also be supported by RawSource("c:\ycsd.SIF", 720, 480, "UYVY").
That one also works.

1) warning: VDub and VDubMod returns an error message when i close them after loading a script with latest RawSource. Does that also happen for you?

2) To check whether a script is good, the easiest is to open it in VDub or VDubMod.

[shorton]

Wilbert:

To answer your question, I have not tried opening the scripts in VDub, but I will in a few hours when I get back to my editing workstation.

I did however try to open the wbars.yuv as shown in your response. It promptly crashed both encoders. If you can open them, I should be able to I'll try again. I did not have the
AssumeFPS(29.97)
in my scripts though, maybe that was the problem. I'll add that and see if I can open them. I'll report back in a little while...

Thanks, Scott

[shorton]

For the archive if someone is following along, branched this discussion to:

http://forum.doom9.org/showthread.php?p=722827#post722827

Where Wilbert is already on it :D

[SeeMoreDigital]

.....Where Wilard is already on it :DWho's "Wilard"?.... Or do you mean "Wilbert"?

[shorton]

Who's "Wilard"?.... Or do you mean "Wilbert"?DOH!!! I have a friend named Willard and I'm guess my feeble old brain is so busy getting a handle on Y's, U's, And V's intelaved with 4:2:2's, etc. I unconsciously type Willard. I've done it a few times now :eek:. Very sorry about that Wilbert. I *know* who's helping me, and I appreciate it vey much. Post corrected.