web-dl.1080p.h265.aac-myz 是什么格式

这几个标准需要分开解说：
1、WEB DL是指从在线视频抓取的流媒体，说明这个视频来源很可能是苹果商店，而不是蓝光光盘。相比蓝光光盘，WEB DL的优势是体积更小，但画面质量受影响较小。
2、1080P是指这个视频的分辨率，其分辨率为1920（横向）1080（纵向），当然，非16：9的标准制式，在分辨率上会有一定的差异，譬如说21:9的视频分辨率为2560（横向）1080（纵向）。
3、H265为近些年新兴的视频压缩编码技术。浅显来说，相比前一代H264，H265可以在拥有同样画质与音质的前提下，获得更小的体积；换句话说，在画质和音质相同的情况下，同样2G的体积，能容纳更长时间的媒体文件；甚至可以再发散一下，同样体积的H265与H264，前者可以拥有更高质量的画质和音质。所以，其诞生之初的主要应用场景是在线视频类的“流媒体”，可以让我们用更小的带宽、消耗更少的流量，却能欣赏到更高质量的媒体文件。
4、AAC是苹果推行的一种音频格式，可以在更小体积下获得更好的音质，重要的是相比MP3格式，AAC可以支持多声道，譬如51声道等。
5、myz不太熟悉，但根据通用规则和前面的“-”字符，应该是压缩组的名称或缩写，也就是说这个视频是myz这个小组负责朔取、压制并放出来的。

基本上不会，很多视频网站甚至不支持h265，上传后直接转码成渣画质的264，视频上百传后变模糊的根本原因是视频文件的码率和尺寸太大，网站的存储空间开销极高。

所以会对超出规格的视频进行压缩处理，而网站每天要同时对成千上万的视频进行压缩编码，而编码对CPU开销极大，所以通常网站会使用GPU编码，且降低质量减少性能开销，不然系统资源不够用。

举个例子，一部可在网上流媒体播放的15GB的通常需要几小时甚至一天的压制时间，期间CPU占用持续100%，为的就是牺牲压制时间换取低码率下的高画质，想让视频变清晰就要去研究一下抖音的二压规则，然后自己压制到合理的质量避免被二次压制。

扩展资料：

PR设置输出抖音高清视频格式步骤：

1、在PR软件中将视频项目剪辑好，然后执行导出为媒体。

2、d出导出设置对话设置窗口，首先来设置导出视频的格式，这里选H264，也就是常见的MP4格式视频。

3、然后来设置视频的基本设置，先来设置视频的大小，这个视频的大小一般根据视频是横屏还是竖排在剪辑之前就还要设置好，然后帧频率一般24到30之间即可。

4、找到比特率设置，选择比特率的编码选项为“VBR，1次”。

5、在来设置目标比特率的数值，这里设置为8即可，如果还有最大比特率设置的话，设置为10就够了。

参考资料来源：百度百科——H265

刚才楼上回答已经很好了，我还想做一点点补充。
1、蓝光1080P与H265没有可比性，就如同你说斧头为什么比大虾更鲜美一样。
2、蓝光1080P是指：分辨率为1920（横向）1080（纵向）的视频，其来源是蓝光光盘。也就是说，这个视频是由蓝光光盘压制的，其分辨率为19201080。
3、H265为近些年新兴的视频压缩编码技术。浅显来说，相比前一代H264，H265可以在拥有同样画质与音质的前提下，获得更小的体积；换句话说，在画质和音质相同的情况下，同样2G的体积，能容纳更长时间的媒体文件；甚至可以再发散一下，同样体积的H265与H264，前者可以拥有更高质量的画质和音质。所以，其诞生之初的主要应用场景是在线视频类的“流媒体”，可以让我们用更小的带宽、消耗更少的流量，却能欣赏到更高质量的媒体文件。
4、决定我们视觉上“清晰”概念的因素有很多，譬如常见的分辨率、帧率，甚至还有其它许多不常见的因素，所以“清晰”这个概念，不能用“蓝光”、“1080P”、“H265”这样简单的对比——况且它们也没有什么可比性。
5、这个回答仅仅是对楼上莫达津回答内容的补充，如果您觉得好，请优先选择楼上莫达津同学的回答。

H264进行编码，iOS 11 之后，iPhone 7以上的设备可以支持新的编码器H265编码器，使得同等质量视频占用的存储空间更小。所以本例中可以使用两种方式实现视频数据的编码

系统已经提供VTIsHardwareDecodeSupported判断当前设备是否支持H265编码

1> g_isSupportRealTimeEncoder = (is64Bit == 8) true : false; 用来判断当前设备是32位还是64位

2> 创建H264/H265Session 区别仅仅为参数的不同，h264为kCMVideoCodecType_H264。 h265为kCMVideoCodecType_HEVC，在创建Session指定了回调函数后，当编码成功一帧就会调用相应的回调函数。

3> 通过 [self getSupportedPropertyFlags]; 获取当前编码器支持设置的属性，经过测试，H265不支持码率的限制。目前暂时得不到解决。等待苹果后续处理。

4> 之后设置编码器相关属性，下面会具体介绍，设置完成后则调用VTCompressionSessionPrepareToEncodeFrames准备编码。

上述方法主要设置启动编码器所需的各个参数

1> kVTCompressionPropertyKey_MaxFrameDelayCount : 压缩器被允许保持的最大帧数在输出一个压缩帧之前。例如如果最大帧延迟数是M,那么在编码帧N返回的调用之前，帧N-M必须被排出。

2> kVTCompressionPropertyKey_ExpectedFrameRate : 设置fps

3> kVTCompressionPropertyKey_AverageBitRate : 它不是强制的限制，bit rate可能会超出峰值

4> kVTCompressionPropertyKey_RealTime : 设置编码器是否实时编码，如果设置为False则不是实时编码，视频效果会更好一点。

5> kVTCompressionPropertyKey_AllowFrameReordering : 是否让帧进行重新排序。为了编码B帧，编码器必须对帧重新排序，这将意味着解码的顺序与显示的顺序不同。将其设置为false以防止帧重新排序。

6> kVTCompressionPropertyKey_ProfileLevel : 指定编码比特流的配置文件和级别

7> kVTCompressionPropertyKey_H264EntropyMode ：如果支持h264该属性设置编码器是否应该使用基于CAVLC 还是 CABAC

8> kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration : 两个I帧之间最大持续时间，该属性特别有用当frame rate是可变

以上方法在每采集到一帧视频数据后会调用一次，我们将拿到的每一帧数据进行编码。

1> 通过frameID的递增构造时间戳为了使编码后的每一帧数据连续

2> 设置最大码率的限制，注意：H265目前不支持设置码率的限制，等待官方后续通知。可以对H264进行码率限制

3> kVTCompressionPropertyKey_DataRateLimits : 将数据的bytes和duration封装到CFMutableArrayRef传给API进行调用

4> VTCompressionSessionEncodeFrame : 调用此方法成功后触发回调函数完成编码。

1> 首先在回调函数中截取到I帧，从I帧中提取到(h265中新增vps),sps,pps信息并写入文件
2> 遍历其他帧将头信息0000,0001写入每个头信息中，再将该数据写入文件即可

这里我们简单介绍一下H264,H265码流信息

注意在H265流数据中新增vps在最前。

流数据中，属性集合可能是这样的：

经过处理之后，在Format Description中则是:

根据上述得到CMVideoFormatDescriptionRef、CMBlockBufferRef和可选的时间信息，使用CMSampleBufferCreate接口得到CMSampleBuffer数据这个待解码的原始的数据。如下图所示的H264数据转换示意图。

群晖h265放不出来的原因：由格式不兼容或证书错误所导致。修正格式或者证书即可。群晖科技（Synology）创立于2000年，自始便专注于打造高效能、可靠、功能丰富且绿色环保的NAS服务器，是全球少数几家以单纯的提供网络存储解决方案获得世界认同的华人企业。

---