|
|
| Wilbert |
| Posted: Aug 28 2005, 12:53 PM |
 |
|
Advanced Member
Group: Members
Posts: 132
Member No.: 6270
Joined: 11-September 03
|
@Avery,
I've a question about your dv decoder and its sampling, in particular PAL DV YV12 -> YUY2. How is the sampling done?
I created a post about how i think upsampling (and subsampling) should be done. This is not the same as your decoder is doing:
http://forum.doom9.org/showthread.php?p=70...0231#post700231
As shown by an example in that thread (the results for the VDub decoder is exactly the same as Cedocida's decoder).
I'd like to know which one is correct  |
|
| phaeron |
| Posted: Aug 28 2005, 08:16 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
VirtualDub's rules for interpolating DV 4:2:0 to 4:2:2:
- Existing samples are passed through unmodified.
- Missing samples are interpolated linearly from the nearest two neighbors in the same field by averaging, rounding up.
- Required source samples that are beyond the image boundaries are replicated from their nearest valid sample in the same field.
Note that if VirtualDub did support 4:2:2 to DV 4:2:0 conversion, it would thus use a rule of (3*V1 + V3)/4 instead of (2*V1 + V3)/3, avoiding having to change the interpolation rule.
It's a bit strange that VirtualDub and Cedocida would produce exactly the same output. You're sure that VirtualDub's DV codec was active? (Check File > File Information.) Do you have a sample clip available for testing?
Also, I don't get the same "correct result" as you do when interpolating the source data. Here's what I get:
| CODE | U[1] = 16
...
U[28] = 16
U[29] = 20 (19.5)
U[30] = 23
U[31] = 23
U[32] = 30
U[33] = 28
U[34] = 33 (32.5)
U[35] = 33
U[36] = 35
U[37] = 35
U[38] = 37
U[39] = 37
U[40] = 39
|
U39 is present in both the source and output test data, but is different (37 vs. 38). That seems like an error...?
When I tested the MSDV codec, I found that it output PAL data as two bob-deinterlaced frames — seeking in Windows Media Player produced the first field, quickly followed by the second. That makes it hard to compare to other decoders.
|
|
| Wilbert |
| Posted: Aug 28 2005, 09:04 PM |
|
|
Advanced Member
Group: Members
Posts: 132
Member No.: 6270
Joined: 11-September 03
|
| QUOTE | | U39 is present in both the source and output test data, but is different (37 vs. 38). That seems like an error...? |
I guess i should have used a calculator Anyway, thanks for your explanation.
| QUOTE | | It's a bit strange that VirtualDub and Cedocida would produce exactly the same output. You're sure that VirtualDub's DV codec was active? (Check File > File Information.) |
Oops, you're right Is there a way to force the use of VDub's decoder without the need of deinstalling all dv codecs?
test file (yuy2):
http://www.geocities.com/wilbertdijkhof/DumpU.zip
| CODE |
# contents of dumpU.avi
Sample: line 0: U = 16
...
Sample: line 29: U = 16
Sample: line 30: U = 30
Sample: line 31: U = 31
Sample: line 32: U = 32
Sample: line 33: U = 33
Sample: line 34: U = 34
Sample: line 35: U = 35
Sample: line 36: U = 36
Sample: line 37: U = 37
Sample: line 38: U = 38
Sample: line 39: U = 39
Sample: line 40: U = 40
...
|
I used the following avs filter to create the test file (thanks to neuron2 ):
http://www.geocities.com/wilbertdijkhof/Sa...ple_Wilbert.zip
I encoded dumpU.avi to DV with Cedocida (DV sampling), and the resulting output is given in that doom9 thread.
| QUOTE | | When I tested the MSDV codec, I found that it output PAL data as two bob-deinterlaced frames — seeking in Windows Media Player produced the first field, quickly followed by the second. That makes it hard to compare to other decoders. |
I'm not sure what you mean here. Are you only talking about the chroma, or also about the luma? |
|
| phaeron |
| Posted: Aug 29 2005, 12:42 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | | Oops, you're right Is there a way to force the use of VDub's decoder without the need of deinstalling all dv codecs? |
No, not currently. The fastest way is to edit the Drivers32 key in the registry, renaming the entries for the existing DV codecs. You only need to restart VirtualDub after doing this.
| QUOTE | | QUOTE | | When I tested the MSDV codec, I found that it output PAL data as two bob-deinterlaced frames — seeking in Windows Media Player produced the first field, quickly followed by the second. That makes it hard to compare to other decoders. |
I'm not sure what you mean here. Are you only talking about the chroma, or also about the luma? |
Both — it looks like you get a field-based display.
|
|
| Wilbert |
| Posted: Aug 29 2005, 10:02 PM |
|
|
Advanced Member
Group: Members
Posts: 132
Member No.: 6270
Joined: 11-September 03
|
Ok, i tried it again. I opened the dv in VDub 1.6.10, under file info it says "Internal DV decoder". When i recompress it to huffyuv (yuy2) (this way the YV12->YUY2 conversion is done by VDub right?) and request the U samples from the huffyuv clip, i get the same values as the Cedocida's (and not the ones you posted).
|
|
| phaeron |
| Posted: Aug 30 2005, 04:22 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Here's what I'm seeing in the decoder:
| CODE | U3 16
U4 16
...
U27 16
U28 16
U31 30
U32 30
U35 34
U36 35
U39 38
U40 39
U43 42
U44 43
U47 46
U48 47
|
Interpolating this gives:
| CODE | U29 23
U30 23
U33 32
U34 33
U37 36
U38 37
U41 40
U42 41
U45 44
U46 45
|
...which I believe is what you got.
Given that the Cedocida decoder looks nothing like mine, but you're getting identical results out of both decoders, I'm inclined to think that your DV file doesn't contain the Cb values you think it does.
By the way, as for why the Panasonic DV results are whacked: it's because the colors you are encoding are waaaay out of the RGB gamut and are being clamped badly. The first pixel is Y=200, Cr=16, Cb=16, which converts to a green of 349/255.
|
|
| Wilbert |
| Posted: Aug 31 2005, 09:00 AM |
|
|
Advanced Member
Group: Members
Posts: 132
Member No.: 6270
Joined: 11-September 03
|
| QUOTE | | Given that the Cedocida decoder looks nothing like mine, but you're getting identical results out of both decoders, I'm inclined to think that your DV file doesn't contain the Cb values you think it does. |
Yes, this turned out to be right. I should have checked this before wasting your time with it. Sorry Anyway, it's good now.
| QUOTE | | By the way, as for why the Panasonic DV results are whacked: it's because the colors you are encoding are waaaay out of the RGB gamut and are being clamped badly. The first pixel is Y=200, Cr=16, Cb=16, which converts to a green of 349/255. |
That's what i suspected, but i didn't bother to recalculate it.
Y=200, U=V=16 => R=35, G=255, B=0 => Y=154, U=48, V=49. The correct value should be U=49. Seems close enough |
|
