Η Google ανοίγει τον κώδικα του VP8 codec και ανακοινώνει το WebM Project

[parsifal]

κατα τα αλλα ειναι open source....NOT!

 

Δεν χρειάζεσαι απαραίτητα τις ευλογίες του OSI για να βάλεις στάμπα "open source" στο προϊόν σου, πού το είδες αυτό; Δε λέω, αν είχε άδεια χρήσης εγκεκριμένη από OSI (ή χρησιμοποιούσε απλά μία έτοιμη από τις καθιερωμένες άδειες) θα ήταν πλεονέκτημα, αλλά «έτερον εκάτερον». Μην προσπαθούμε απεγνωσμένα να πιαστούμε από οπουδήποτε για να 'χαμε να λέγαμε...

[digekas]

Αυτό που λέει ο DiBona είναι ότι η άδεια του vp8 θέλει κάποιο ψάξιμο γιατί μπορεί να έρθει σε ρήξη με άλλες άδειες που ήδη χρησιμοποιούνται στην google και είναι απόλυτα λογικό, ίσως βέβαια να έπρεπε να είχαν ξεκαθαριστεί νωρίτερα τέτοια θέματα, παρά ταύτα όμως η πρόθεση και η κίνηση είναι ξεκάθαρη και ο vp8 είναι open source και free με ή χωρίς άδεια από την OSI ή το FSF.

 

Βεβαίως και πρέπει να έχει η google την ευλογία τους και είμαι πεπεισμένος ότι θα την πάρει αφού τόσο η OSI όσο και το FSF επηρεάζουν την κοινότητα στην οποία στηρίζεται και η google για την ανάπτυξή της, απλά θέλει αρκετό ψάξιμο για να μην καταλήξουν πάλι σε Tivoisation καταστάσεις.

 

http://www.fsf.org/blogs/community/google-free-on2-vp8-for-youtube/

http://lwn.net/Articles/200422/

 

Αφού έχουμε την χαρά να είναι στην χώρα μας ο Stallman, ευκαιρία να του γίνει η ερώτηση στην Θεσσαλονίκη και να μας πει πως βλέπει σήμερα την κίνηση της google, να βγάλουν και είδηση λαβράκι οι bloggers.

[parsifal]

Στο επίσημο blog του WebM project, ένα ενδιαφέρον αρθράκι για το experimental branch του project.

 

Το ρεζουμέ: σε αυτό το branch δε θα υπάρχει ο περιορισμός του frozen bitstream, επομένως θα μπορούσε πιθανά να βελτιωθεί η ποιότητα με πολύ πιο γρήγορα βήματα απ' ο,τι στο stable branch.

[FarCry]

την αλλαξαν την αδεια για να επιλυσουν τα προβληματα

 

http://arstechnica.com/open-source/news/2010/06/google-resolves-webm-licensing-conflict-with-bsd-license.ars

Επεξ/σία 26 Ιουνίου 2010 από FarCry

[parsifal]

http://arstechnica.com/open-source/news/2010/06/google-resolves-webm-licensing-conflict-with-bsd-license.ars

 

Ιδιαίτερο ενδιαφέρον παρουσιάζουν τα comments...

[digekas]

Γενικά αυτού του είδους οι ρήτρες δεν εξασφαλίζουν τόσο τις εταιρίες ότι δεν θα γίνουν μηνύσεις μεταξύ τους όσο το ότι κλειδώνουν την αγορά και αφήνουν τρίτους που ενδεχομένως θα ενδιαφερθούν να μπουν στο παιχνίδι, έξω από αυτή.

 

Πολύ απλά και με δυο λόγια, τα κάνουν "πλακάκια" και λέει η μία στην άλλη, δεν θα έχεις αξιώσεις από εμένα αλλά και εγώ με την σειρά μου δεν θα έχω κάποια αξίωση από εσένα, αλλά αν εμφανιστεί τρίτος που θα πάει να μας φάει μέρος της πίτας θα του πάρουμε και τα "σώβρακα".

 

Γενικά το όλο θέμα έχει ένα ιδιαίτερο ενδιαφέρον όχι τόσο για το vp8 αυτό καθεαυτό αλλά για τις τάσεις της google να γίνει ο κύριος διανομέας τηλεοπτικού υλικού στο δίκτυο σε μία εποχή όπου οι κλασικοί διανομείς (κανάλια και στούντιο) βρίσκονται σε μία όχι και τόσο καλή οικονομική κατάσταση (συγκριτικά πάντα με τα προηγούμενα χρόνια).

 

Από αυτούς περιμένω να δω αντιδράσεις και που θα πατήσουν για να φρενάρουν την google πριν προλάβει να αποκτήσει την πρωτοκαθεδρία στην διανομή video μέσω δικτύου σε τηλεοράσεις που μέχρι σήμερα οι καταναλωτές είχαν κυρίως συνδεδεμένες με καλωδιακή, δορυφορικά συστήματα και blu-ray για να αξιοποιούν τις δυνατότητες των τηλεοράσεών τους.

[parsifal]

Post στο blog του Dark Shikari (ο ένας εκ των βασικών x264 developers, τον αναφέραμε μερικά posts πιο πάνω) όπου εξηγεί πώς ο ίδιος μαζί με άλλους 2 FFmpeg developers έφτιαξαν και ενσωμάτωσαν στο FFmpeg project έναν VP8 decoder αρκετά γρηγορότερο από (και bit-identical με) τον reference decoder της Google

[kurkosdr]

Post στο blog του Dark Shikari (ο ένας εκ των βασικών x264 developers, τον αναφέραμε μερικά posts πιο πάνω) όπου εξηγεί πώς ο ίδιος μαζί με άλλους 2 FFmpeg developers έφτιαξαν και ενσωμάτωσαν στο FFmpeg project έναν VP8 decoder αρκετά γρηγορότερο από (και bit-identical με) τον reference decoder της Google

 

Λογικο και αναμενομενο, αφου ακομα και ο αρχαιος theora σταδιακα ειδε γρηγοροτερους και καλυτερους decoders και encoders. Σε ολα τα φορμα (ακομα και στο mjpeg λεμε) υπαρχει περιθωριο εξελιξης.

Αλλα αυτο που πραγματικα εχει σημασια ειναι πως τα παει σε συγκριση με το σημειο αναφορας ονοματι mpeg 4 avc (και ειδικα την υλοποιηση απο το x264 group). Δεν εχουν τοση σημασια τα features του φορμα στα χαρτια, αλλα η συγκριση μεταξυ των δυο καλυτερων υλοποιησεων για το καθε φορμα.

 

Αμα ειναι περιπου ισο με το mpeg 4 avc, τοτε ας ξεφορτωθουμε τα mpeg 4 avc σε mkv container, τα mpeg 4 asp σε avi container και ολα τα υπολοιπα περιεγα φορμα που σκοπο εχουν να παρακαμψουν τις πατεντες του mp4 container, συν τα Quicktime, WMV που σκοπο εχουν να παρακαψουν τις πατεντες του mpeg 4 avc format, και ας παμε κατευθειαν στο WebM. Για ολες τις χρησεις. Αλλα κατι μου λεει οτι το VP8 δυσκολα θα πιασει το avc. Πολυ απλά, ο πηχης ειναι παρα πολυ ψηλα.

[digekas]

Αν έχει υποστήριξη σε hardware όπως και το h.264 πολύ σύντομα τα πράγματα θα αλλάξουν ανεξάρτητα του αν ο χώρος του θεάματος παραμείνει στο παλαιότερο και πιο διαδεδομένο προς το παρόν πρότυπο.

 

Πιο απλά, δεν έχει νόημα να έχεις ένα video που για την αναπαραγωγή του σε συσκευές πέρα από τον υπολογιστή να πρέπει να το ξανασυμπιέσεις.

 

Ξέρουμε πότε οι ATI/NVIDIA θα υποστηρίξουν την αποκωδικοποίηση του vp8 στην gpu;

[parsifal]

Πριν λίγες μέρες, η Google έβγαλε την έκδοση 0.9.5 του VP8 SDK, με κωδική ονομασία "Aylesbury". Σύμφωνα με τη σχετική ανακοίνωση στο επίσημο blog του WebM project, υπάρχουν βελτιώσεις στην ταχύτητα decoding και στην ποιότητα του αποτελέσματος (χρησιμοποιείται βέβαια το PSNR metric, το οποίο δεν είναι τόσο αντιπροσωπευτικό της ποιότητας που αντιλαμβάνονται εν τέλει ο ανθρώπινος εγκέφαλος, αλλά δεν υπάρχει και κάτι καλύτερο αυτήν τη στιγμή).

 

Για το επόμενο release που αναμένεται στο πρώτο τρίμηνο του 2011, υπόσχονται βελτιώσεις στην ταχύτητα του encoder.

[parsifal]

VP8 Codec SDK "Bali" Released

 

Στην έκδοση 0.9.6 του επίσημου VP8 implementation, όντως υπάρχει βελτίωση στην ταχύτητα του encoder όπως είχαν υποσχεθεί οι developers. Σε σχέση με την έκδοση 0.9.5 (Aylesbury) λοιπόν:

 

• 30-40% πιο γρήγορος σε x86
  
• 7% πιο γρήγορος σε μονοπύρηνο ARM Cortex
  
• 15% πιο γρήγορος σε 2πύρηνο ARM Cortex
  
• 26% πιο γρήγορος σε 4πύρηνο ARM Cortex
  
• 21-36% πιο γρήγορος σε NVIDIA Tegra2
  

 

Επίσης, βελτίωση 6% στη μέση ποιότητα του τελικού αποτελέσματος, όπως αυτή προκύπτει με PSNR και SSIM metrics.

[digekas]

Το vp8 hardware encoding σε Tegra2, (ποιοτικά πάντα συγκρινόμενο), σε τι επίπεδο βρίσκεται; Συμβάλει κάπως στην κωδικοποίηση ή έχει να κάνει με την σχεδίαση του soc αυτή η διαφορά του έως και 100% σε σχέση με τον 2πύρηνο cortex;

[parsifal]

Δε νομίζω πως έχει ενσωματωθεί VP8 encoding σε hardware στο Tegra 2 ή σε άλλο SOC που κυκλοφορεί αυτήν τη στιγμή. Τα σχετικά IP designs για hardware implementation έχει μόλις λίγο καιρό που εκδόθηκαν από την ομάδα του WebM project. Εξάλλου, πώς θα είχες βελτίωση επιδόσεων σε κάτι που υλοποιείται ως fixed transistors/ASIC, με νέα έκδοση ενός software encoder; Άτοπο!

 

Με τη διαφορά του 100% δεν καταλαβαίνω σε τί αναφέρεσαι. Η νέα έκδοση του libvpx είναι 15% πιο γρήγορη στο encoding σε 2πύρηνο ARM Cortex, δηλαδή αν με την 0.9.5 είχες X fps, τώρα έχεις (1,15 * Χ) fps. Σε Tegra 2, αν με την 0.9.5 είχες Y fps, τώρα έχεις (1,21-1,36 * Υ) fps. Με Χ διάφορο του Υ, όχι ίσα!

[digekas]

http://www.nvidia.com/object/tegra-2.html

 

Έχω την εντύπωση ότι αναφέρεται το vp8 στο encoding capability section χωρίς όμως να αναφέρονται τα υπόλοιπα codecs τα οποία υπάρχουν στο αντίστοιχο τμήμα που αφορά το decoding.

 

To πως θα πως θα μπορούσε να συνδυαστεί ένας hardware με ένα software encoder, τι να σου πω, βασικά εγώ ρώτησα πρώτος () αλλά nvidia είναι αυτή, δεν μπορώ να ξέρω σε τι βαθμό ο hardware encoder μπορεί να παραμετροποιηθεί, δλδ κατά πόσο τρέχει σαν κώδικας (πχ σαν cuda).

 

Το μέγεθός του από την άλλη, δεν ξέρω, σε σχέση με τον decoder μου φαίνεται αρκετά μικρό.

 

 

Για το 100% που ανέφερα, η νέα έκδοση είναι 15% πιο γρήγορη σε διπύρηνο cortex και έως 36% πιο γρήγορη σε Tegra 2, οπότε στον Tegra 2 εμφανίζεται μία διαφορά (36-15)/15 *100 %, δλδ έως και 140% max (δλδ από 40~140% συγκριτικά με τον διπύρηνο cortex), τα μεγέθη βέβαια δεν είναι (άμεσα) συγκρίσιμα αφού πρώτο έχει το x86 που βρίσκεται σε τελείως άλλη κατηγορία ισχύος.

[parsifal]

http://www.nvidia.com/object/tegra-2.html

 

Έχω την εντύπωση ότι αναφέρεται το vp8 στο encoding capability section χωρίς όμως να αναφέρονται τα υπόλοιπα codecs τα οποία υπάρχουν στο αντίστοιχο τμήμα που αφορά το decoding.

Τον είχα δει τον πίνακα αυτόν. Δεν υπάρχει καμμία ένδειξη ότι για όλα τα διάφορα formats που αραδιάζουν εκεί υπάρχει hardware decoding ή encoding. Για H.264 video, σίγουρα υπάρχει dedicated bitstream decoder, ίσως και για MPEG-4 ASP, MPEG-2 και VC-1 (τα δύο τελευταία προβλέπονται στο Blu-ray standard). Για όλο το κατεβατό όμως, δεν παίζει, πίστεψέ με! Εννοούν τί δυνατότητα υπάρχει μέσω software.

 

 

To πως θα πως θα μπορούσε να συνδυαστεί ένας hardware με ένα software encoder, τι να σου πω, βασικά εγώ ρώτησα πρώτος () αλλά nvidia είναι αυτή, δεν μπορώ να ξέρω σε τι βαθμό ο hardware encoder μπορεί να παραμετροποιηθεί, δλδ κατά πόσο τρέχει σαν κώδικας (πχ σαν cuda).

Αν είναι πλήρης bitstream encoder fixed σε hardware, απλά δε γίνεται! Τουλάχιστον όχι χωρίς να «κοροϊδεύουμε αλλήλους» (όπως π.χ. αποπειράθηκε να κάνει η Intel με τον Sandy Bridge, προσεγγίζοντας τους developers του x264 και υποσχόμενη πρόσβαση στην Quick Sync engine, αλλά τελικά αποδείχθηκε ότι αυτή η πρόσβαση θα ήταν απλά μέσω του σχετικού SDK και χρησιμοποιώντας την Quick Sync εντελώς ως ένα "black box"! )

 

 

Το μέγεθός του από την άλλη, δεν ξέρω, σε σχέση με τον decoder μου φαίνεται αρκετά μικρό.

Σε τέτοια SOCs, ο hardware encoder αφορά συνήθως το video format που καταγράφουν οι συσκευές που τα ενσωματώνουν μέσω της καμερούλας τους. Για το συγκεκριμένο, υποπτεύομαι μόνο H.264 σε baseline ή και main profile σε κάποια βήματα αναλύσεων, και τίποτα πέραν αυτού.

 

 

Για το 100% που ανέφερα, η νέα έκδοση είναι 15% πιο γρήγορη σε διπύρηνο cortex και έως 36% πιο γρήγορη σε Tegra 2, οπότε στον Tegra 2 εμφανίζεται μία διαφορά (36-15)/15 *100 %, δλδ έως και 140% max (δλδ από 40~140% συγκριτικά με τον διπύρηνο cortex), τα μεγέθη βέβαια δεν είναι (άμεσα) συγκρίσιμα αφού πρώτο έχει το x86 που βρίσκεται σε τελείως άλλη κατηγορία ισχύος.

Αυτό που λες είναι ότι πέτυχαν διαφορετικό (μεγαλύτερο) speed-up του κώδικα στο Tegra 2 απ' ο,τι σε άλλους Cortex A9 (ο Tegra 2 είναι κι αυτός ένα implementation του Cortex A9 IP design). Διαφορετικά implementations --> Διαφορετικές αρχικές επιδόσεις και διαφορετική επίπτωση των ίδιων code optimizations. Που είναι το περίεργο;