橫向先+6黑邊的一個做法，不知是否可行?

[adonisl]

諸位好，小弟剛接觸影像壓製不久，請大家指點。
目前打算用MEGUI2028 壓製一個16:9的DVD，並在電腦上撥放。
希望做到底下幾點:
1.畫面不變形
2.絕對不縮小，保持高度480。
3.盡量能不裁邊，裁得愈少愈好。
3.整體影像能接近16:9

網路上看到的作法:
A. 720x480 -> resize -> 872x480，872不等於872.727，畫面會有些許變形，不考慮。
B. 720x480 -> crop16 ->704x480，裁掉16
b1. 704x480 resize 704x396，縮小不考慮。
b2. 704x480 resize 853x480，853不等於853.33，變形不考慮。
b3. 704x480 SAR 40:33，最上面四個前提，1、2、4都符合，裁邊方面-- resize前的畫面被裁掉16

為了想辦法減少16這個量，我想了一個做法，不知道怎麼樣?
C. 720x480 -> 畫面左右各加3黑邊 -> 726x480 -> resize -> 880x480 -> 左右各裁12 -> 856x480 結束

這樣的作法
1. 畫面沒變形(726 x 40/33 = 880)
2. 畫面高度保持480，不縮小
3. 原本704作法下，畫面被裁掉16；加黑邊變成726的作法下，畫面被裁掉: 24 x 33/40 - 6 = 13.8
4. "整體影像"比例是856/480=1.7833，尚可接受

主要是resize前，把720加黑邊變成726，這樣x40/33後可以成為整數880，之後880怎麼裁，就是比較自由的考量。切到854的話，真實的整體影像更接近1.778 (852/480=1.775)，但被裁比較多(26 x 33/40 - 6 =15.45 > 13.8)

如果跟作法B之b3 (CROP-704 ->SAR 40:33) 相比，兩者的畫面都沒有變形，一樣都是16:9，但畫面從被裁16減為13.8。"整體的真實影像"雖然不是剛剛好16:9，但在電腦上播放沒有差別，就算880之後不裁或只裁到黑邊為止，畫面也不會變形走樣，畢竟是在resize之後的步驟。

不知道這個作法是否有道理? 惠請各位前輩能不吝給予指點。感謝 m(_ _)m

[dgwxx]

有关crop和resize的文章，请发到理论讨论区。

1.不知楼主在考虑出这个方法后有没有实践检验。
在YV12色空间下是不能加奇数px的黑边的。且画面长和宽必须保持4的整数倍。加6px黑边后，画面是726，不是4的整数倍，会出现错误提示。
如果为了加黑边再转换一次颜色空间（YUY2之类的），那么颜色空间转换带来的损失和开销要比形变代价还高。综上，横向加6px黑边这个做法本身在YV12颜色空间下是否具有必要性，需要考虑。
2.其次，40：33是704*480用的SAR，楼主加黑边之后还用这个SAR来计算形变是否正确，需要考虑。

动画DVD的制作比较混乱，日本动画的后期摄影，大多是在纯16：9的环境下进行的。具体来说，就是864x486这个分辨率。由于DVD的纵向分辨率是480，按照正确做法，应该是左右切到853（后期环境的颜色空间不是YV12，是允许486这种分辨率和奇数切边的）、纵向切到480后resize到704x480，左右再共计加入16px黑边到720x480，再压缩、灌制DVD。
（还有一种可能的做法是，864x486不切边，直接resize到704x480，播放的时候左右切16后resize到853x480刚好也是原始比例的16:9。）
可是现在无论是制作方还是播放设备的制造商都没有遵守正确的做法。
SD制作的时候直接将864x480 resize到720x480，HD制作的片子直接将1280x720制作的动画resize到720x480灌制DVD等等，都是错误的做法。由于原始的画面不再是853x480->704x480加黑边到720x480，所以这种因为我们没办法判断每张DVD原始的画面是怎么做出来的，所以在错误的情况下，SAR究竟是多少，掩藏在了制作过程这一不被公开的暗箱操作之中。后期过程本身是否存在变形，最终的SAR是多少，终究变成了虚无缥缈的不可知论。
播放过程也不一定总是正确的。据某位液内人士透露，某几个国际知名品牌的电视采用的方案是上下左右各切2%之后强行resize至全屏播放。

所以，为了数字上的好看去转换颜色空间再加黑边，我认为是不太划算的事情。看了上面的动画制作过程（正确版）之后，楼主的“切边越少越好论”自然也就不总是正确了，有时候该切的还是要切掉的。

[adonisl]

謝謝您的回覆。似乎我還沒跟上您的水平，對於YV12色空間還不太了解。
這個方式我有壓製過，沒有出現錯誤提示，最後就這樣壓完了。

我壓製的是去年日本演唱會的NTSC DVD，觀察其原始解析度為720x480，可變形16:9，
我是於AviSynth cript creator 腳本這樣輸入:
#deinterlace
#crop
AddBorders(3,0,3,0)
#resize
LanczosResize(880,480) # Lanczos (Sharp)
#crop
crop(12,0,-12,0)
#denoise
Resize前在畫面左右各加入奇數3黑邊，而726也不是您提到的4的倍數，不過過程中沒有出現任何問題。Resize後為880x480，裁邊為856x480，potplayer開啟影片按Tab鍵，其Input和Output顯示YV12(12 bits)。會不會是您提到的是動畫，所以造成我們在奇數pix黑邊和高度486這兩點上有所差異。

另外，您提到40:33僅為704x480用的SAR，這點也不太了解，我以為不論畫面是否在resize前被切裁過，16:9可變形影像寬度從被DVD內所壓擠成的1.5比例中還原出去時，應都是 x 4/3 x 10/11，前者為壓擠的還原，後者為長方形pix所要做的修正。當這個被擠壓的影像被裁掉部分，其剩餘的影像還是保持著相同被擠壓的狀態(被擠壓成1.5)。是否我的想法有誤? 懇請D大予以指正與批評，我在網路上看到的計算都是如此，即使720被裁掉的不是16，剩餘的數也是遵照著-- crop後寬度 x 4/3 x 10/11 x resize所求高度/480 = resize後寬度 這個方式。

另外您提到的製作方和撥放器不遵照正確resize方式，我在網路上有看到相關的資料，例如之前版本的PowerDVD、WINDVD和您提到的電視強行resize全螢幕。甚或是學理上的探究衍伸出的79:72。
不過沒辦法掌握的東西也無從依循，在自己手上的這個環節只能基於前製和後製都會正確這個想法來進行了。

如果我這個做法行不通，應該會選擇crop(8,0,-8,0) --Sar 40:33 或是 crop(8,0,-8,0) resize(704,396)
不過這片NTSC DVD，幾乎沒有任何黑邊存在，而且舞台上兩方都有成員，一裁掉16，人就被切掉一半了，不得已只能採取減低高度為704*396這個方式了。不過我看現在很少人壓這個比例，很好奇大家都是怎麼做的，閉門造車後，才會想出720-726-880-856這個方式。
若我有不足的地方，懇請D大指點。謝謝!

[264768502]

LZ为啥不考虑720x480 sar 40:33呢? (假设sar40:33是正确的)
播放的时候的确是偏离了1.77 达到了1.81 LZ是因为无法接受这个非16:9的结果吗

另外还有一种可能,就是片源做错了,sar应该是32:27 那么这种情况可以说皆大欢喜了,能满足LZ所有的要求

[Holy]

測試了下，在 YV12 色空間時，AddBorders 單邊是可以為奇數的，只要 left+right 和 top+bottom 為偶數；而 Crop 才有各邊皆須為偶數的限制。

[-o-o-304-o-o-]

首先704x480没法R到853x480吧，除非在YUY2下做，但是这样的话x264又有麻烦了，且考虑到部分滤镜可能需要mod4（比如lsfmod），一般最多的选择就是856x480

同虾大和草大，建议您先找个标准圆或者标准的方块图标给2个SAR（40:33,32:27）分别看看谁是对的（DVD的话前段时间就遇到一个带边的SAR32:27的DVD，结果傻乎乎的按着SAR40:33的做结果出来看着人脸总觉得怪怪的。orz

小白的小小建议，直接C完边然后给个SAR不行么直接压不行么（720->856的话多多少少会增加那么一点码率开销吧（应该就是一点吧估计不纠结的话可以无视嗯。主要是偷懒不想算（死））），且R的话维持如果需要维持原来的DAR的话，32:27没边的话直接R到854,856或者直接挂SAR 32:27就行
感谢指正，此处修改（orz脑抽算错了
小白意见，仅供参考。从养鸡场爬回的小白膜拜LS一众菊苣，看到菊苣们真是太高兴了泪目（众：…………

[adonisl]

如果是40:33的话您加了6px的边，按照40:33这个SAR做完R后再C掉24px的边。您把前后结果都换算成SAR为1:1的情况，实际上您是加了7.272727……（当然实际操作上加只能加6或者8）然后再C掉24px，这么算的话您这么做的画面损失似乎比直接切16px还要大（24-7.2727……>16），感觉这样似乎没啥必要吧

-o-o-304-o-o- 兄，您好，
您上面這段算錯了:
"24-7.2727" 並不能直接拿來跟16比，"24-7.2727"是resize"後"，16是resize"前"
720 - 16 = 704 ，這個16pix是resize前畫面被裁掉16pix
880 - 24 = 856 ，這個24pix是resize後畫面被裁掉24pix，

還原為"resize前"原始畫面被裁掉多少:
一個是 16，一個是 13.8 (24 x 33/40 - 6 = 13.8)
24是rezise後裁掉的畫面，要看這個量相當於resize前畫面被裁掉多少，要*33/40。
13.8 < 16

您是用"resize後"來做比較，"（24-7.2727……>16）" 前面是對的，後面是錯的，16須*40/33。
24-7.27 < 16*40/33
簡單來說: resize後裁掉16，跟resize前裁掉16是不一樣的。
其實您瞭解這個計算的，只是疏忽算錯了，且以為我算錯了，其實我的算法跟您提的道理一樣，反而您的算法就是您認為我算錯的那種。(好像繞口令)

[adonisl]

LZ为啥不考虑720x480 sar 40:33呢? (假设sar40:33是正确的)
播放的时候的确是偏离了1.77 达到了1.81 LZ是因为无法接受这个非16:9的结果吗
另外还有一种可能,就是片源做错了,sar应该是32:27 那么这种情况可以说皆大欢喜了,能满足LZ所有的要求

264768502兄，您好:
原本是有這個考量沒錯，不過現在應該也無所謂了，反正是在電腦上看。

這邊想跟大家討論兩個點，如果錯了，或資訊已過時，請不吝指點
1. 40:33這個東西。2. 不做resize，設定比例，播放時即時resize。

1.
個人認為在電腦螢幕上的話，32:27普遍來說應該是不太正確的，根據的是Silky和DOOM9上提到的相關學理。
應為 x 4 / 3 x 10 /11 (40:33) 或是 x 4 / 3 x 72 / 79
40:33不多講了，後面那個是把掃描線這個因素再多考慮進去，也就是Gordian Kont和NMM提供的"切邊與Resize計算器"的算法。

2.
壓製影片時不要Resize，直接壓縮，以設定比例值的方式，播放軟體再即時resize。
這點我聽過一個說法，codec, container 的 resize 演算法效果並沒有 Lanczos3 resize 好，
轉檔時用 Lanczos3 resize 的畫質會比即時 resize 來得好。

[264768502]

1.按标准来说 40:33没错 但你要知道并不是所有厂商都会按照标准来做的.胡乱编辑的事情我见到不是一次两次了

2.播放时resize可以根据你自己的需要,选择各种不同resize算法,和container无关,只和解码器和渲染器有关.如果不在解码时做resize的话就得依靠渲染器内置的resize算法.目前来说诸如ffdshow提供的resize还是madvr的resize都不会比lanczos3要差,vmr9和EVR得看设置和显卡,也未必会差

[-o-o-304-o-o-]

-o-o-304-o-o- 兄，您好，
您上面這段算錯了:
"24-7.2727" 並不能直接拿來跟16比，"24-7.2727"是resize"後"，16是resize"前"
720 - 16 = 704 ，這個16pix是resize前畫面被裁掉16pix
880 - 24 = 856 ，這個24pix是resize後畫面被裁掉24pix，

還原為"resize前"原始畫面被裁掉多少:
一個是 16，一個是 13.8 (24 x 33/40 - 6 = 13.8)
24是rezise後裁掉的畫面，要看這個量相當於resize前畫面被裁掉多少，要*33/40。
13.8 < 16

您是用"resize後"來做比較，"（24-7.2727……>16）" 前面是對的，後面是錯的，16須*40/33。
24-7.27 < 16*40/33
簡單來說: resize後裁掉16，跟resize前裁掉16是不一樣的。
其實您瞭解這個計算的，只是疏忽算錯了，且以為我算錯了，其實我的算法跟您提的道理一樣，反而您的算法就是您認為我算錯的那種。(好像繞口令)

刚刚爬出养鸡场头晕脑胀确实算错了，感谢指正

另外您别动辄“兄”啥的，太客气了这个咱看着有点无所适从了orz。。

720下c16换算成1:1 SAR的结果应该是19.393939……，确实这么算的话，切的话损失相对较直接c16更小些。还是感谢指正错误了，修改下原帖去

不过我说的其他部分的我认为应该是没啥问题吧。如果是追求有效画面的最大话的话完全可以不用管R完得DAR是不是16:9啊，只要和原始的DAR相同（前提是原始的DAR是没有问题的）的话应该就是没有问题的，多多少少还是有点不明白为啥要追求标准的16:9的DAR呢？