a-frames
Ik werk echt al jaren in deze sector, en ik heb werkelijk nog nooit van een A-frame gehoord. Ik ben echt bijzonder benieuwd wat volgens jou een A-frame is. FYI, B staat voor bidirectional (of bi-predicted), in tegenstelling tot P (predicted) of I (independent of intra-coded). Zie bv.
wikipedia.
flink gesjoemeld
De vergelijkingen tussen vp9 en h264 zijn gedaan via de bijzonder standaard settings (voor x264): --tune psnr (als psnr als metric wordt gebruikt) --profile high --pass 1/2 --preset veryslow, dat zijn de aanbevolen settings en de x264 developers zijn het daarmee eens (zie #x264-devel logs voor discussies tussen vp9 en x264 devs daarover). Het feit dat vp9 (via standaard best quality 2-pass settings, zie WebM wiki) 50% kleinere bestanden voor dezelfde kwaliteit (of enorm veel hogere kwaliteit voor dezelfde bitrate) genereert, is volledig verwacht en is niet verrassend, niet voor de x264 developers en niet voor de vp9 developers. Op bepaald materiaal (bv. parkjoy) doet x264 het bijna net zo goed als vp9 en hevc, en dat is wederom niet bepaald verrassend (als je wilt, kan ik ook uitleggen waarom).
door de video met h.264 een veel groter aantal A/B-frames te geven die relatief veel opslag vragen
Ik geloof dat je in de war bent met de VP8/H264 MTI (mandatory-to-implement) codec discussie in webRTC (real-time communication, i.e. videochat in de browser). Daar werden in de tests door het ene team
wel en door het andere team
niet B-frames voor H264 ingeschakeld. De reden dat het VP8 team ze
niet inschakelden is omdat B-frames delay betekenen (omdat je eerst een future P-frame moet encoden), wat dus latency (vertraging) betekent, wat over het algemeen als onacceptabel wordt beschouwd voor RTC doeleinden. Het gebruiken van B-frames in een RTC codec test was daarom ook nogal vreemd. Er waren nog wel meer vreemde dingen aan de gang in die codec-vergelijking.
Maar al dat heeft niks met VP9 te maken.
(kent geen b-frames)
VP9 kent geen B-frames, maar kent wel degelijk bi-directional prediction of non-linear (alt-ref) frame encoding (in vp9 kan een alt-ref patroon ook recursive zijn), wat samen voor vergelijkbare doeleinden kan worden gebruikt als B-frames (maar ook voor volledig andere dingen).
Zeker is dat VP9 nog aanzienlijk achterligt bij h.265.
Dit vind ik een grappige opmerking, wat er bestaan nog geen commerciele (of free software) hevc encoders waarvan de licentie je toestaat ze in vergelijkende tests te gebruiken. De enige encoder die momenteel op die manier ""bruikbaar"" is (expres tussen aanhalingstekens), is de reference model ("HM"), welke in de richting van de 10 frames (1080p) per uur kan encoden (zie bv. rant hierover dan een van de x264 developers), m.a.w. enorm praktisch bruikbare software voor HD video encoding. Vergeleken met
die reference model implementatie (zie dat als een exhaustive search implementatie van de hevc specificatie), staat libvpx (een
echte encoder die al in
Youtube is geintegreerd) vrijwel gelijk. ik ben - net als vele anderen - benieuwd naar echte vergelijkingen tussen vp9 en non-exhaustive implementaties van hevc (die dus sneller zullen zijn, maar niet noodzakelijkerwijs even goede resultaten zullen geven), maar om nu al te claimen dat vp9 ver achterligt t.o.v. h265 is ... bijzonder twijfelachtig. Niet in de laatste plaats omdat encoders voor beide formaten de komende jaren nog enorm onder ontwikkeling zullen zijn (inclusief kwaliteits-verbeteringen), iets wat voor H264 al jaren niet meer het geval is (voorbeeld: x264 --profile high --preset veryslow --pass 1/2 --tune psnr (met psnr als kwaliteits-metric) van januari 2013 is sneller dan van januari 2012, maar kwaliteit is hetzelfde).