问一下如果原盘是30fps，BDRip是60fps有意义吗

就是vmoe制作的几个magical mirai2014有30fps AAC的和60fps FLAC的，AAC和FLAC的区别还是能听出来的，但是帧数有很大区别吗，尤其是在原盘30fps的情况下
体积大了不少，cpu和gpu使用率也高了不少，这样做有意义吗

意义是有的，但是不是人人都需要／认可。

这个问题其实等同于：svp 到底有没有意义？在片源基础上插入过渡帧会大幅提高画面的流畅度，但也有副作用，首先过渡帧算法不可能完美，动画类视频补出烂帧的几率不小，其次是可能破坏片子本身想要表达的效果（比如制作时刻意想营造的抖动感）。

这个和音频还不一样。如果你拿有损格式的音频转成无损格式，听感是不会有提高的。

至于视频帧率要多高才算够高，这是个复杂的问题。有兴趣的可以读读这个文章，讨论得很全面。
http://www.100fps.com/how_many_frames_can_humans_see.htm

单就我们看动画这一情境来说，60 fps 其实都还不够。

楼上答案虽然没有说错什么，但是有很强的误导性，因为：

SVP的60p是通过算法将24p/30p插值出来的60p，而30fps蓝光制作成60p 是因为蓝光中每秒就有60场原生的图片，这两个是完全不同的制作流程和原理

关于这点我曾经在https://share.dmhy.org/topics/vi ... 80p_HEVC_BDRip.html
里和某小白撕逼过，而且我有打算下一部vcb-s的科普贴讲述这点。

目前我的回答是：有，而且很有必要，因为这就是原盘中自带的时间高频信息。只不过：
1. 播放压力很大，特别是配合HEVC
2. 前提是，制作者真的正确判断了原盘类型。30fps的蓝光原盘可能应该做成24p/30p/60p，这是看源的类型而定的。如果应该做成24p/30p的做成了60p那就呵呵了
3. 在极低的码率下，60p会造成码率分配不合理，因为较多的码率会被投入空间编码复杂度。

而30fps蓝光制作成60p 是因为蓝光中每秒就有60场原生的图片，

原来是这样。那么我上面就不能说等同于 svp 了，完全是两回事。

这锅给我扣的。。。 声明一下，在正经bdrip中，Vmoe没有用，也绝对不会用svp进行处理。同时，分辨率，帧率，体积，字幕类型都是有过考虑的。去年magical mirai 2014是1080 30的avc高压处理，今年是1080 60的hevc处理，混合码率定位约7k。再怎么说不会乱来，svp这种东西我们不会用的。

Evalyn 发表于 2016-2-8 21:30
这锅给我扣的。。。 声明一下，在正经bdrip中，Vmoe没有用，也绝对不会用svp进行处理。同时，分辨率，帧率 ...

我并没有扣锅啊。。。我问的是一个比较具有普遍性的问题就是原盘30fps但是压制后是60fps的意义，贵组压制的演唱会是举得一个例子。。。望您不要介意。

LittlePox 发表于 2016-2-7 11:43
楼上答案虽然没有说错什么，但是有很强的误导性，因为：

SVP的60p是通过算法将24p/30p插值出来的60p，而30 ...

不知怎麼翻到這篇，來說說我的看法吧


事實上我覺得 dmhy 上那位仁兄講得並不算錯，當然 LittlePox 講的部分大部分都正確，但有些地方跟我的認知還是不太一樣


(以下所說的 30 跟 60 應該全都換成 29.97 跟 59.94 才正確，以 30 跟 60 稱呼只是為了打字方便而已)


30p 跟 60i 是兩種不同的東西，它們的差異主要是發生在拍攝的時候

30p = 每秒拍出 30 張 1920x1080 完整畫面 (稱為幀 = frame)，每一張畫面之間，相隔 1/30 秒
60i = 每秒 60 張 1920x540 半張畫面 (並不是上半+下半，而是隔行，前一張是單數行(1,3,5,....1079 行)的畫面，後一張是偶數行 (2,4,6,...1080行)的畫面

這看似半張的畫面，通常稱為場 ( = field, 單數行組成的畫面叫 top field / 偶數行叫 bottom field)，每個場的解析度為 1920 x 540
而場跟場之間，時間相隔 1/60 秒，比 30p 的幀跟幀間的時間差比，快了一倍


要「還原」成 60p 那是不可能的，因為原生畫面就已經丟失了一半的畫面　（這張丟了單數行，下張丟了偶數行，再下張又丟了單數行....）

要「運算」成 60p 當然是可能的，但那就跟補幀的做法類似，是用前後幀去運算不存在的畫面出來
補幀補的是整張 1920x1080 的假畫面，而 60i -> 60p 是補了一半 1920x540 的假畫面，差別只是這樣而已

還原成 30p，然後把那 1/60 時間差所造成的交錯部份消除掉，這才是播放 60i 原本被預期會採取的作法

所以一般 60i 是「還原成 30p」，再加上去交錯處理 (deinterlaced)，並不會被預期「還原成 60p」



60i 的畫面資訊量 = 每秒 60 * 1920 *540 * bit 數
30p 的畫面資訊量 = 每秒 30 * 1920 * 1080 * bit 數，這跟 60i 的資訊量是一樣的，只差在取樣時間不同，所以才會造成畫面交錯
60p 的畫面資訊量 = 每秒 60 * 1920 * 1080 * bit 數

60i 跟 60p 的畫面資訊量差了兩倍，當然不可能有所謂「60i 還原成 60p」這種事情，但把 60i 「運算成」60p 當然有可能

而這種 60p，每一張畫面都有運算的假資料在，而補幀是 2 真畫面 3 假畫面，或 1 真 1 假，真假畫面交錯


60i -> 60p 跟補幀這兩種作法，其實是殊途同歸的，都是想計算出不存在的畫面資訊，提升整體的觀賞體驗


以提升觀驗為前提，把 60i 的源運算成 60p，這當然沒什麼問題

但如果說 60i -> 60p 才正確，60i -> 30p 是錯誤，因為會丟掉一半的資訊，這種說法就有很大問題了....


因為事實上並不是 30p 會丟掉 60i 一半的資訊 (X)，反而是 60i -> 60p 製造了一倍的資訊出來吧 (O)

我觉得没有必要

tonyhsie 发表于 2020-5-11 08:00
不知怎麼翻到這篇，來說說我的看法吧

你这段推论中最大的问题是：

60i和30p虽然在“资讯量”上一样
但是这俩是完全不同的结构

60i是时间上不妥协，空间上打5折。
30p是时间上打5折，空间上不妥协。

“還原成 30p，然後把那 1/60 時間差所造成的交錯部份消除掉，這才是播放 60i 原本被預期會採取的作法”
这只是你一厢情愿的美好想法，实际播放中根本无法做到。因为空间上丢失的信息无法通过时间上的富余来弥补；空间上丢失的信息必须通过空间插值（1920x540 -> 1920 x 1080）来处理。

尽管看上去都是一样的数据量，60i和30p是没有办法直接互转的
尽管看上去都是一样的数据量，60i和30p是没有办法直接互转的
尽管看上去都是一样的数据量，60i和30p是没有办法直接互转的

重要的话说三遍。那么60i怎么转成30p呢？

1.  60i -砍掉一半-> 30i - 运算拉升 -> 30p (先在时间上打5折，再把空间上翻倍）
或者2.  60i -运算拉升-> 60p -砍掉一半-> 30p (先在空间上翻倍，再把时间上打5折)

既然空间上运算翻倍不可避免，那我们可以选择时间上不打折，即：
60i -运算拉升-> 60p

“還原成 30p，然後把那 1/60 時間差所造成的交錯部份消除掉，這才是播放 60i 原本被預期會採取的作法”
这只是你一厢情愿的美好想法，实际播放中根本无法做到。因为空间上丢失的信息无法通过时间上的富余来弥补；空间上丢失的信息必须通过空间插值（1920x540 -> 1920 x 1080）来处理。

我想你誤解了我的說法

「通过时间上的富余来弥补」<= 這並不是我原文的意思


一般對 60i 的處理，本來就是把兩張不同時間的 1920x540 fields 合併成單張 1920x1080 frame，再來做處理 (60 fields -> 30 frames)


這過程你稱之為「空间插值」，但我倒覺得是「合併 fields」

尽管看上去都是一样的数据量，60i和30p是没有办法直接互转的
尽管看上去都是一样的数据量，60i和30p是没有办法直接互转的
尽管看上去都是一样的数据量，60i和30p是没有办法直接互转的

這前面我也講得很清楚了，沒想到連這也必須還要澄清，有點遺憾

1.  60i -砍掉一半-> 30i - 运算拉升 -> 30p (先在时间上打5折，再把空间上翻倍）
或者2.  60i -运算拉升-> 60p -砍掉一半-> 30p (先在空间上翻倍，再把时间上打5折)

既然空间上运算翻倍不可避免，那我们可以选择时间上不打折，即：
60i -运算拉升-> 60p

1. 根本是完全錯誤的推論，事實上的確是有這種丟棄一半畫面，單純只把 1920x540 的 field resize 成 1920x1080 frame 的作法
但這並不是一般播放器 (不管硬體、軟體、或是 TV) 最普遍採用的作法；相反的，一般沒人會用，(除非有現實因素的考量)

你不能推論所有由 60i -> 30p 的成果影片/播放結果，全都是由來源的單一 field 來拼揍出成品的單一 frame，在過程中丟掉了一半的 field


2. 問題就在於「運算拉升」 這東西代表了什麼？如何從 1920x540 的單一 filed 無痛升級成 1920x1080 的單一 frame?


基本上 60i -> 30p 本來就是從前後兩個 1920x540 的 field 來拼揍出 一張 1920x1080 的 frame ，而單純拼揍不作任何處理

就會像這樣

field 1


field 2


單純合併 field 1 & 2，得到 frame 1


這時再作 deinterlace，就是一般 60i -> 30p 的作法


你所謂的「先拉升，再砍半」這種說法我還是第一次聽到

我不確定你這句話說的是什麼樣子的處理方式

如果你指的是「先把 1920x540 的單一 field 通通 resize 成 1920x1080 變成 frame，然後再捨棄其中一半的 frame，讓 fps 減半」的作法

那就完全是對現行 60i -> 30p 的一種誤解了


如果不是這樣，那也請你略述一下，何謂「先拉升，再砍半」？


在這之前，或許可以先參考 https://www.100fps.com/ 然後我們再繼續討論會比較快得到共識


題外話，我 2003 年開始作壓製，2006 年自己寫過 MPEG-1 decoder，實作過把 MPEG 檔案轉換成畫面影像的過程

在影像處理這個領域裡，應該還是有資格聊上幾句的


不敢說我的理解就一定完全正確無誤，或許一樣也有問題，大家切磋互補不足就是了