『漫游』酷论坛>『影音数码技术学习交流』>[求助]关于1080P压480P的 ..
[求助]关于1080P压480P的分辨率设置
grasscup@2010-05-16 18:46
请问下怎么把1080P和1080I的视频压成480P？
直接resize到某个分辨率么？
我resize到720x480，再设sar40:33，但这样出来是873x480对吗？还是改设32:37？
我只知道DVD的sar设40:33就行，再大的就不知道了……
roozhou@2010-05-16 18:54
这个显然应该是32:27了，rip时resize不改变DAR
另外1080I的建议保留单场1920x540p后再resize成480p，这样免去反交错
grasscup@2010-05-16 19:16
谢谢roozhou解答。
“rip时resize不改变DAR”
就是说不管resize到什么分辨率，只要最后满足DAR不变就行了？
辉耀@2010-05-16 21:47
其实说来也简单了，BD的PAR=1:1，分辨率纵横比就是显示纵横比，只要resize、sar之后最终结果与原始相同就都是对的（一般就是16:9）
个人觉得……BDrip向下做到480P附近的话，分辨率其实可以灵活选择……像LZ所说做成类似DVDrip的720x480 32:27/704 480 40:33自然可以，此外切一下边做主流的864/848x480，不做AR且追求mod16做1024x576、768x432，甚至做个非主流的896x504（纵16mod横8mod纯16:9）也未尝不可……吧
话说，有个一直不太清楚的问题跟帖问下，856x480这种分辨率是怎么做出来的？不做任何crop直接resize？（也就是说接受那大概千分之三的AE？）
roozhou@2010-05-16 21:57
楼上为什么要凑mod16？连1080P本身都不是，你为什么要去凑呢？
辉耀@2010-05-16 22:23
唔……记得以前看帖就见到过roozhou大您表示mod16根本没有继续遵守的必要，也还记得diseac大曾表示过做480P完全可以做864x486（上下3px不切掉）；而实际上我个人也的确没遇到过因为分辨率不是mod16而出现所谓压缩瑕疵之类的问题，而1080也确实只是个mod8，DVDrip做704x396的也的确大有人在……
不过……毕竟绝大多数作品最终还是选择了遵守mod16……（虽然明白此类情况也有可能仅仅是出于某种习惯或者怕观众难以接受，就像RMVB用了这么多年一样……），自然而然就有些倾向于也这么做了……也许的确没必要……
而且……BDrip做成720x480 32:27我觉得比做768x432还要奇怪一点……吧……毕竟这样做如果观众一方若设置错误可能会出现错误的结果……（例如下面提起的EVR加边播放，vobsub设置错误导致字幕拉长等……）
对了提起这个我想问一下，似乎EVR模式下实现AR是加边而并不是直接resize，别扭不说看全屏每次都要过扫描……是我设置错误还是的确如此？（Win7 64 KMP EVR haali ffdshow，单一变量法后觉得问题似乎就是在EVR上）
52wy@2010-05-16 22:53
我用evr看sar的片子没发现加边啊。另外很多压到720x480只是为了兼容psp而已。
辉耀@2010-05-16 23:15
呃，也许真是我设置错误？但确实单一变量一个个修正试了一下，只要把渲染模式改成EVR增强就加边……
囧，突然发现本子上还真没有AR的片子……就随便抓了张图片裁成16:9，resize 720x480，--sar 32:27做了1s的视频测试的……
从我这看起来就是如下这样的……很别扭……
（Windows7 64bit/KMPlayer/EVR增强/ffdshow解码）
upyzl@2010-05-16 23:23
引用
最初由 辉耀 发布
呃，也许真是我设置错误？但确实单一变量一个个修正试了一下，只要把渲染模式改成EVR增强就加边……
囧，突然发现本子上还真没有AR的片子……就随便抓了张图片裁成16:9，resize 720x480，--sar 32:27做了1s的视频测试的……
从我这看起来就是如下这样的……很别扭……
（Windows7 64bit/KMPlayer/EVR增强/ffdshow解码）
可尝试下其他播放器
如MPC-HC
另外我不清楚x64 OS是否也会有影响
52wy@2010-05-17 00:36
的确跟播放器有关，我试了下kmp的确如此。mpc正常。
superkidx@2010-05-17 10:21
引用
最初由 roozhou 发布
另外1080I的建议保留单场1920x540p后再resize成480p，这样免去反交错
这个要这么做？
ssnake@2010-05-17 10:50
引用
最初由 superkidx 发布
这个要这么做？
SeparateFields().SelectEven().AssumeFrameBased()
然后再resize。
不过这样比做Deint再Resize效果会差一点——当然速度快非常多。
辉耀@2010-05-17 12:15
引用
最初由 ssnake 发布
SeparateFields().SelectEven().AssumeFrameBased()
然后再resize。
不过这样比做Deint再Resize效果会差一点——当然速度快非常多。
请问一下AssumeFrameBased()是什么……自己查了下没看懂……
AssumeFieldBased(clip clip)
AssumeFrameBased(clip clip)
AviSynth keeps track of whether a given clip is field-based or frame-based. If the clip is field-based it also keeps track of the parity of each field (that is, whether it's the top or the bottom field of a frame). If the clip is frame-based it keeps track of the dominant field in each frame (that is, which field in the frame comes first when they are separated).
However, this information isn't necessarily correct, because field information usually isn't stored in video files and AviSynth's source filters just guess at it. AssumeFrameBased and AssumeFieldBased let you tell AviSynth the correct type of a clip.
AssumeFrameBased throws away the existing information and assumes that the clip is frame-based, with the bottom (even) field dominant in each frame. (This happens to be what the source filters guess.) If you want the top field dominant, use ComplementParity afterwards.
AssumeFieldBased throws away the existing information and assumes that the clip is field-based, with the even-numbered fields being bottom fields and the odd-numbered fields being top fields. If you want it the other way around, use ComplementParity afterwards.
roozhou@2010-05-17 21:43
这个主要作用是让后面的resize当成progressive来处理。
如果是对交错的源做resize，实际上分成两场分别做resize然后再合成
比如1080i -> 480i，实际上就是分成两个1920x540 -> 720x240，再合成为一帧。我说的这种情况用这种方法resize就错了。
辉耀@2010-05-17 22:01
明白了……感谢您的指导~
«12»共2页
| TOP