最后补充一个CPM cost per thousand impression(千人成本)，即广告主购买1000个广告收视次数的费用或者是广告被1000人次看到所需的费用。比如说一个广告 Banner 的单价是$1/CPM的话，意味着每一千个人次看到这个Banner的线 人次访问的主页就是$10。
为什么要补充一个这么专业的概念呢，因为CPM是广告行业入行面试/笔试必考题目，本人印象中唯一的门槛级专业词汇！！三次4A求职经历居然都被问到 T.T
具体每个公司的业务是选择 MTO、MTS，还是 ATO ，要看客户要求的订单交付期与供应链反应周期之间的关系。
MTS饭馆卖饺子，客户要求上菜时间是20分钟，如果煮饺子的时间是30分钟，那就必须提前煮些饺子出来。否则你就只能让客户等30分钟再把饺子端上去。这个就是 MTS 了。要储备库存以解决供给周期和需求时效的矛盾。当然也可以解决产能和需求波峰波谷之间的矛盾。比如大师傅11点半以前都坐着剔牙、看报。那是不是可以让他们之前煮点儿完了放冰箱冻起来人来了再热？当然这样做不太道德，但是我觉得饭馆肯定有这么干的。
ATO饺子有猪肉白菜的、有鸡蛋韭菜的，还有N多种其他的，如果提前把生饺子包好了，就会有一个你包了200个猪肉大葱100个鸡蛋韭菜，结果人家要买100个猪肉大葱200个鸡蛋韭菜的问题。如果客户要求上菜时间是20分钟，餐馆更新了煮饺子的设备，可以10分钟煮熟饺子（当然，这样是否好吃另说了），10分钟把事先准备好的馅儿包成饺子。这样，我们的问题可以解决。对于某些需求量小的饺子品种（比如冬瓜或者鲍鱼馅）可以现下单现包，对于大众饺子品种提前包出来没有问题。按订单把馅包在饺子里，这个就是 ATO 了。
MTO还是饺子，如果现在是某公司过春节大会餐，提前来找本餐馆预定。那就可以提前谈好了要什么馅儿的，猪肉大葱5000，韭菜2000，三鲜3000个。而且产品交付周期一般也会较长，人家公司行政的人怎么也得提前3~4天来找你谈的。所以，餐馆就完全可以利用这几天的时间现采购原材料（猪肉、羊肉、虾仁、鸡蛋），现准备馅儿，现包。因为时间充裕。按照订单先采购原材料、加工、组装成成品就是 MTO 了。
所以，具体用哪个模式是看每个环节加总组成的总供应周期和需求时效的差。看差值允许你做到哪一步。当然还要考虑储存周期、产能等一些其他的限制条件。
interlaced/progressive：隔行扫描、逐行扫描。属于电视广播的历史遗留问题，如今越来越少遇到。缩写为i或p，跟在视频清晰度后面。
2K, 4K、8K：横向为2048像素、4096像素、8192像素的视频。纵宽不固定，根据电影高宽比决定（1.85:1, 2.35:1之类）。
注意这个和消费电子所谓的4K (3840x2160，其实是UHD)的区别。另外，电影必然是逐行的，所以不分i或者p。
比如，1440x1080的逐行视频也是1080p，甚至极端的说，1x1080也是1080p（当然没人这么干）。
主要是因为纵向的线数越多，人眼察觉的细节越多。横向细节损失反而不容易看出来。
Aspect Ratio：高宽比。通常指的是画面的高宽比。比方说PAL DVD的分辨率是720x576像素，如果按数字来的线的，但只要高宽比设定成4：3或16：9，播放的时候就会自动拉伸到那个比例。
没错，这个时候画面的像素就不像电脑那样是正方形的了，而是先变成长方形再播放出来。
视频一般是分成「亮度」和「色度」两个信号处理，「亮度」可以产生黑白的画面，「色度」叠加在亮度上，让黑白画面变成彩色。但如果都原样保存的话，所占空间会巨大，所以产生了「色度抽样」，利用人眼对轮廓敏感，而对颜色不敏感的特性，减小「色度」信号的体积。
影视制作里一般常用的是4:2:2抽样，这个模式下纵向是可以保持和实际分辨率一样的清晰度。
比如说一个1920x1080的视频，亮度是1920x1080，但色度是960x540。在某些极端情况下会有肉眼可见的瑕疵，如图：
注意几个颜色接壤的地方，就是因为色度信号采样不够，覆盖到了不该覆盖的地方，使得颜色的界线显得非常模糊不自然。
从这个意义上讲，如果民用影视还沿用4;2:0采样的线K（UHD）电影的时候也是会享受到画质提升的（因为色度信号正好够1080p）。期待线K片源的普及。
M&E：Music & Effects，只有音乐音效但无人声的轨道，用来做官方配音。业内一般叫「国际声」。
嗯，暂时想不到什么了。制作时候的术语大多是汉语，而这部分英语可能不少字幕组的技术党们也都熟悉。就当抛砖引玉吧。
敏捷开发是现在比较流行的一套用于软件开发的过程控制论。它包括许多工具，如站会、看板、用户故事等。如果对这些术语不了解，则有可能造成团队成员间交流沟通的障碍，不利于团队协作。下面，我们就来看看敏捷开发中常见的术语。
敏捷方法是一种适应性强、覆盖开发周期的方法。这种方法是以迭代（iterations/sprints）来交付的软件产品。在敏捷开发中，时间是固定，范围是可以在用户需求的基础上，根据迭代情况改动的。敏捷方法适用于需求尚未全部确定的情况。
燃尽图是一个迭代中剩余工作时间与整个迭代时间对比产生的一个 图形化视图。项目待办/工时可在竖轴显示，时间以横轴显示。燃尽图常来判断一个项目或迭代中的工作什么时候可以完成。关于燃尽图的走势，可参见燃尽图类型解析。
迭代是一个重复开发的概念，就是在一个很短的时间范围内交付软件功能或用户故事。每个迭代都包括瀑布式的活动，比如分析，设计，开发，以及测试，但是迭代都要在一到四周内完成。在迭代最后，要和客户一起审核，并将其建议的变动加入下个迭代中。
估算扑克是Mountain Goat Software的Mike Cohn发明的一种估算游戏。估算扑克用于将单个用户故事作为团队活动进行估算。团队聚在一起，对用户故事一个个的回顾。团队每个人就用户故事进行讨论，并以自己手中的扑克牌对其工作量进行估算，直到团队对该用户故事的估算结果达成一致意见。禅道也推出了自己的估算扑克，欢迎大家选购！
发布时将迭代产生的软件交付给客户。在发布计划中，团队将回顾产品待办，将用户故事整理成特定的发布和迭代，将这个功能性的产品交付给顾客。
Scrum 是用于管理软件项目的重复式的开发方法。在基于Scrum的项目中，没有一个特定的项目经理来指挥团队的项目任务。团队进行自我管理，团队成员依靠文档进行互相交流，以交付项目。
Sprint是基于Scrum的敏捷方法论的概念，类似于iteration。Sprint是在一定时间内交付特定的用户故事以及产生有用的功能。在迭代计划中，客户或产品经理置顶用户故事的优先级，开发团队在给定迭代中完成在任务。迭代过程中，用户故事可以从迭代范围内去除，但是不可以加入新的用户故事。这样是为了让项目组将精力集中在完成此项迭代目标上，并可以迅速交付。
故事点是用于确定用户故事大小的一种比较估算方法，团队可以一次确定一次迭代中可以完成的工作量。故事点可以用简单的,T恤衫尺码，或者相对数标识。把用户故事和相关的故事点加起来，项目组可以估算未来迭代计划的速率。
用户故事是项目需求的敏捷版本的说法。用户故事包含几句话，描述给定需求由谁来做什么，以及为什么要这么做，这些可以用 索引卡或者便利贴记录下来。用户故事由顾客来写，说明想要的软件是什么样的。作为客户和开发组之间用于沟通工具，用户故事应该简明阐述用户故事，使软件开发出来。如 Mike Cohn所举例， 作为一名角色，我想要 达到的目的/做到的事。
迭代始于计划会议，由产品负责人讲解需求，开发团队估算工时。一个好的计划会议是迭代成功的基础。
每日站立会议，也叫作“每日Scrum”、“每日一小聚”、“早晨点名”，就是整个团队每天碰一次面，快速做个状态更新汇报。站着开会是为了让会议简短，每个人只需说明自己做了什么、准备做什么就可以了。工作中遇到的问题不会在站立会议上解决。
一般在迭代的最后一天进行，演示迭代成果。敏捷开发的会议一般都不会太长，否则就失去了“敏捷”的意义。
迭代结束后进行回顾会议，探讨持续改进的内容。确定问题优先级以及团队需要首要解决的问题，讨论解决问题的措施。