DVD to .mkv αλλά γρήγορα (gpu accelerated)

[digekas]

 

Όχι, ρώτησα το ίδιο ακριβώς πράγμα, με εντελώς διαφορετική διατύπωση!!!

 

 

Τέλος πάντων και πέρα από την πλάκα, μου κάνει εντύπωση που και στο tomshardware αναφέρουν στην ουσία ως πρόβλημα αυτό το multithreading που θα πρέπει να έχει ο codec και αναρωτιέμαι εγώ τώρα (με πάσα επιφύλαξη να έχει ξαναγίνει η ερώτηση... ) γιατί δεν το αφήνουν single-threaded να τρέχει στον κάθε ένα πυρήνα και να ξεκινάει κάθε thread από διαφορετικό keyframe (βέβαια θα απαιτείται και αντίστοιχα πολλαπλάσια μνήμη); (Το πιθανότερο είναι αυτό να έχει ήδη γίνει, αλλά μια και έχω χρόνια να ασχοληθώ με το encoding και μια και βρήκαμε και τον παπά, να θάψουμε καμπόσους... )

[parsifal]

... και να ξεκινάει κάθε thread από διαφορετικό keyframe

Σε ένα raw video stream που σου έρχεται στην είσοδο, δεν υπάρχει η έννοια των keyframes. Το αν ένα frame θα είναι keyframe ή όχι στο τελικό bitstream είναι αποτέλεσμα της εκτέλεσης του scene change detection αλγορίθμου.

 

Αν πάλι εννοείς να κόβεται arbitrarily το input video σε κομμάτια και κάθε thread να αναλαμβάνει κι από ένα, αυτό έχει γίνει ήδη από 3rd party projects. Google για "x264farm" και "ELDER". Αλλά εδώ υπάρχουν μερικά θεματάκια:

 

1. Είναι εφαρμόσιμο μόνο σε offline encoding, όπου έχεις το input video αποθηκευμένο από πριν σε κάποιο αποθηκευτικό μέσο και σου δίνεται η δυνατότητα για seek σε αυτό σε arbitrary offsets. Τί γίνεται όμως στην περίπτωση που θέλεις να χρησιμοποιήσεις τον encoder σε συνθήκες online/realtime encoding, π.χ. broadcasting ή teleconferencing; Hint: Πρόσφατα είχε γίνει συνειδητά δουλειά στο codebase του x264 ώστε να μειωθεί το latency του encoder, ακριβώς για να γίνει πιο κατάλληλος και για τέτοιου είδους εφαρμογές

2. Δεν υπάρχει κεντρικός έλεγχος του ratecontrol ==> απώλεια ποιότητας και προβλήματα undersized/oversized output

3. Η εισαγωγή arbitrary I-frames εκεί που κανονικά δε θα χρειάζονταν σημαίνει πως χρειάζεσαι μεγαλύτερο bitrate για την ίδια ποιότητα (βέβαια με κομμάτια ικανού μεγέθους η επίπτωση θα είναι μικρή, but still...)

 

 

btw, το τρέχον threading model του x264 προβλέπει ένα μικρό ποσό frame-based παραλληλισμού αλλά όχι στο βαθμό και με τον τρόπο της λύσης που πρότεινες (νομίζω πως υπάρχει master thread που εκτός από συγχρονισμό κάνει και το απαραίτητο "bookkeeping", γι' αυτό και οι 3 παραπάνω επιπτώσεις που ανέφερα δεν ισχύουν εδώ).

[digekas]

Καταρχήν να πω ευχαριστώ για τις απαντήσεις.

 

Ναι λογικό είναι για να μπορείς να βρεις keyframes να πρέπει είτε να έχεις κάνει ένα pass το αρχικό video ή να υπάρχει κάποιο buffer αρκετά μεγάλο σε περίπτωση που τραβάς από κάμερα και δεν σε νοιάζει να γίνει realtime αναμετάδοση όπου εκεί όντως θα υπάρχει καθυστέρηση.

 

Πόσοι όμως στην πράξη χρησιμοποιούν encoders για να τραβάνε 720p και 1080p realtime;;; Τα προγράμματα στα οποία αναφερόμαστε υπάρχει εξαρχής το video και είτε γίνεται reencoding σε άλλα bitrate ή άλλες αναλύσεις. Δηλαδή τουλάχιστον όπως εγώ το βλέπω το πράγμα, αυτό που θέλει ο χρήστης είναι να μπορεί να αξιοποιηθεί στο έπακρο το hardware που έχει και να γλιτώσει πολλές ώρες αναμονής χωρίς όμως να θυσιάσει την ποιότητα. Όπως γινόταν και παλαιότερα στις h.263 multipass συμπιέσεις, όπου στην αρχή σάρωνε το video και έκανε κάποιες εκτιμήσεις σχετικά με το ποιες σκηνές χρειάζονταν μεγαλύτερα bitrates.

 

Βέβαια με την ψηφιακή τηλεόραση να έχει μπει στην ζωή μας, αν και ακόμα είμαστε σε sd σήμα, το realtime h.264 encoding αποκτά ιδιαίτερο ενδιαφέρον, χώρια που πλέον ένα σωρό gadgetάκια φέρουν κάμερες αρκετών megapixel αλλά και αρκετή επεξεργαστική ισχύ οπότε και εκεί οι υλοποιήσεις θα είναι αυτές που θα προσδίδουν αξία σε αυτές τις συσκευές, αν και για video conferencing ακόμα και σε υψηλές αναλύσεις οι συμμετέχοντες δεν κινούνται και ιδιαίτερα οπότε και τα bitrates είναι χαμηλά ενώ από την άλλη σε τι οθόνη θα δει ο άλλος 720p ή 1080p και σε πόση απόσταση; (δλδ δεν φαίνονται οι λεπτομέρειες παρά μόνο αν συνδεθεί σε μεγάλη οθόνη που σπάνια πιστεύω θα συνδέει κάποιος ένα smartphone ή tablet στην τηλεόραση του για να μπορούν περισσότερα άτομα γύρω του να συμμετέχουν σε μία συζήτηση).

 

Πάντως μου έδωσες αρκετό υλικό για διάβασμα για το Σ/Κ και έχω μείνει αρκετά πίσω στο κομμάτι του encoding το οποίο με τον ένα ή άλλο τρόπο θα μας απασχολήσει αρκετά τους επόμενους μήνες.

 

Και πάλι ευχαριστώ, με φιλικούς χαιρετισμούς, Δημήτρης.

[parsifal]

Το θέμα είναι πως ο encoder είναι (και ίσως οφείλει να είναι; ) agnostic γύρω από την offline διαθεσιμότητα του video που θέλουμε να συμπιέσει. Αυτό που περιμένει να δει είναι raw (YUV για την ακρίβεια) frames στην είσοδό του, δε γνωρίζει αν αυτά του σερβίρονται από ένα αρχείο αποθηκευμένο τοπικά στο δίσκο ή over the network ή από κάποια συσκευή σύλληψης. Επιπλέον, το μέγεθος των χρησιμοποιούμενων buffers δε μπορεί να είναι οσοδήποτε μεγάλο μας βολεύει σε κάθε περίπτωση, υπάρχει και το ζήτημα του level conformance που το απαγορεύει.

 

 

Όπως γινόταν και παλαιότερα στις h.263 multipass συμπιέσεις, όπου στην αρχή σάρωνε το video και έκανε κάποιες εκτιμήσεις σχετικά με το ποιες σκηνές χρειάζονταν μεγαλύτερα bitrates.

Και τώρα γίνεται αυτό. Οι περισσότεροι H.264 encoders υποστηρίζουν 2-pass encoding, δεν καταργήθηκε. Απλά, με την αύξηση των διαθέσιμων χωρητικοτήτων στα «σκληρά» αποθηκευτικά μέσα και των ταχυτήτων στις δικτυακές επικοινωνίες, έχει μπει περισσότερο στο περιθώριο.

 

 

Πάντως μου έδωσες αρκετό υλικό για διάβασμα για το Σ/Κ και έχω μείνει αρκετά πίσω στο κομμάτι του encoding το οποίο με τον ένα ή άλλο τρόπο θα μας απασχολήσει αρκετά τους επόμενους μήνες.

Αν σε ενδιαφέρει να εμβαθύνεις, καλό reference ανάγνωσμα θεωρείται το "H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia".

[digekas]

To αν ο encoder γνωρίζει ή θα πρέπει να γνωρίζει εξαρτάται από την υλοποίηση, δλδ, αν το πρώτο πέρασμα (που γίνεται για την εύρεση αλλαγής σκηνών αλλά και για μία εκτίμηση του απαιτούμενου bitrate κάθε μίας) θα συμπεριληφθεί στον encoder πράγμα που ήδη γίνεται και στο single-pass όπου αναγνωρίζεται η αλλαγή σκηνής οπότε και έχουμε νέο keyframe. Ε, από την στιγμή που θα γίνει αυτό, multiple instances του x264 θα τρέχουν στους πυρήνες, απλά για να γίνει πιο κατανοητό σε όσους τύχει να διαβάσουν τα ποστ, αντί να ξεκινήσει να συμπιέζει από την αρχή το video και να φτάσει στο τέλος του ο encoder, θα πάρει ο πρώτος πυρήνας την πρώτη σκηνή, ο δεύτερος την δεύτερη και πάει λέγοντας οπότε φανταστείτε ολόκληρο το έργο να συμπιέζεται ταυτόχρονα από την αρχή μέχρι το τέλος και όχι σειριακά οπότε και το parallelization δεν θα έρθει από τον ίδιο τον encoder αλλά από το feed του.

 

Τουλάχιστον για το θέμα που συζητάμε εδώ, δλδ από dvd (και bluray) σε mkv.

 

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

 

Ε, αυτοί τώρα οι πολλοί λιγότερο ισχυροί υπολογιστές είναι οι πυρήνες στην gpu μας οι οποίοι θα μπορούν κάλλιστα να συνεργάζονται με τους πυρήνες της cpu.

[parsifal]

Ε, αυτοί τώρα οι πολλοί λιγότερο ισχυροί υπολογιστές είναι οι πυρήνες στην gpu μας οι οποίοι θα μπορούν κάλλιστα να συνεργάζονται με τους πυρήνες της cpu.

Όχι, δεν είναι τόσο απλό, για πολλούς λόγους, όπως:

 

1. Οι Stream Processors των GPU (όπως είναι τώρα σχεδιασμένοι και υλοποιημένοι από NVIDIA και ATI τουλάχιστον) δεν έχουν την απαιτούμενη πολυπλοκότητα για να τρέξουν ένα πλήρες πολυαλγοριθμικό πρόγραμμα που να κάνει δουλειά αντίστοιχη με αυτήν που κάνει ένα μοναδικό thread π.χ. του x264. Είναι πολύ απλές επεξεργαστικές μονάδες, σχεδιασμένες για να τρέχουν σύντομα και trivial κομμάτια κώδικα (hint: γιατί έτρεχαν τα σάλια μεταξύ άλλων και των x264 developers όταν διάβαζαν τα specs του άδοξα ακυρωθέντος Larrabee ). Η δύναμή τους είναι ο τεράστιος αριθμός τους και τίποτ' άλλο. Για να εκμεταλλευτείς αυτήν τη δύναμη (εδώ είναι και άλλη μία σημαντική δυσκολία στο GPGPU video encoding, πέραν του integer VS FP debate), πρέπει να προσαρμόσεις το συνολικό αλγόριθμό σου για να φέρεις την SIMD λογική στα όριά της, δηλαδή πολύ fine-grained parallelism και πολύ μεγάλο διαμερισμό των δεδομένων εισόδου. Κάτι που δεν είναι ούτε εύκολα εφικτό ούτε αποδοτικό στο inter-frame video encoding

2. Περιορισμένες ποσότητες μνήμης στην οποία μπορεί να έχει πρόσβαση ο κάθε SP

3. Η μετακίνηση δεδομένων μεταξύ RAM και VRAM κοστίζει πολλούς κύκλους

4. Δεν υπάρχει shared μνήμη μεταξύ CPU και GPU, γεγονός που δημιουργεί θέματα συγχρονισμού και δρομολόγησης των kernels που κάνεις dispatch για εκτέλεση στους SPs, όταν χρειάζεται να έχεις κάποιου είδους master thread που θα τρέχει στη CPU

 

 

Πέραν δηλαδή από τις συνήθεις δυσκολίες του παράλληλου προγραμματισμού με κυριότερη την απαίτηση για εφεύρεση συχνά νέων μη τετριμμένων αλγορίθμων, εδώ υπάρχουν και έξτρα προκλήσεις από το αρκετά περιοριστικό προγραμματιστικό μοντέλο που επιβάλλει η αρχιτεκτονική των GPU. Πολύ χαρακτηριστική είναι μία δήλωση ενός από τους developers του x264 (νομίζω ο Glasser, μπορεί να ήταν και ο Merrit), δε μπορώ τώρα να την βρω για να τη γράψω verbatim αλλά πήγαινε κάπως έτσι: «Ξέρεις πόσοι μας προσέγγισαν κατά καιρούς, δηλώνοντας την προθυμία τους να δουλέψουν για τη μεταφορά τμημάτων του κώδικα του x264 στη GPU; Αφού ξοδεύαμε αρκετή ώρα κάθε φορά για να τους κατατοπίσουμε σχετικά με τη λογική του x264 και μετά από μερικές επισκέψεις τους για ερωτήσεις στο #x264dev, σε λίγο καιρό τους χάναμε χωρίς ποτέ να δούμε κάποιον κώδικα από αυτούς».

[digekas]

Βασικά ένα από τα μεγαλύτερα προβλήματα είναι τα optimizations που έχουν γίνει στον x264 και που αναφέρουν και τα παιδιά https://sites.google.com/site/x264cuda/Home/x264-cuda.pdf?attredirects=0&d=1 οπότε αν κάποιος ξεκίναγε ένα τέτοιο project μάλλον από εκεί που σταμάτησαν θα συνέχιζε χωρίς βέβαια αυτό να σημαίνει ότι η μνήμη της κάρτας γραφικών θα επαρκούσε, όχι τουλάχιστον αν καταμεριζόταν στο σύνολο των πυρήνων αλλά αυτό δεν σημαίνει ότι ένα σύνολο πυρήνων δεν θα μπορούσαν να σχηματίσουν μία υπομονάδα επεξεργασίας και όσο αφορά το θέμα της ταχύτητας, έτσι και αλλιώς το αρχικό βίντεο βρίσκεται σε εξωτερική μονάδα, οπότε ακόμα και με την συμπίεση που έχει, μου δίνει την αίσθηση χωρίς να το έχω υπολογίσει ότι το bandwidth επαρκεί και αν υπάρξει bottleneck αυτό θα προέλθει από την εξωτερική πηγή.

 

Δεν λέω ότι είναι εύκολο να γίνει, αλλά έχοντας δει κώδικα FEA να τρέχει σε cuda και μάλιστα με πάρα πολύ μεγάλη ταχύτητα μεταφέροντας δε τεράστιους πίνακες θεωρώ ότι είναι ναι μεν δύσκολο να γίνει αλλά είναι εφικτό, αλλά όπως λες και εσύ θέλει πάρα πολύ δουλειά και πέρα από αυτή αρκετές γνώσεις στο αντικείμενο και δεν νομίζω να υπάρχει χειρότερο πράγμα από το να έχουν το φόρτο της εργασίας τους και από πάνω να απαντάνε σε ερωτήσεις, των οποίων τις απαντήσεις εύκολα μπορεί κάποιος να βρει χωρίς να τους απασχολήσει, για αυτό λέω ότι θα αφιερώσω 1-2 μέρες να δω πως λειτουργεί ο encoder και τι δυνατότητες υπάρχουν από πλευράς cuda και εφόσον δω ότι το πράγμα μπορεί να προχωρήσει θα ρωτήσω τα παιδιά στο κανάλι τους να δω πως και εκείνα θα δουν την όλη σκέψη.

[caution]

Όχι, δεν είναι τόσο απλό, για πολλούς λόγους, όπως:

 

1. Οι Stream Processors των GPU (όπως είναι τώρα σχεδιασμένοι και υλοποιημένοι από NVIDIA και ATI τουλάχιστον) δεν έχουν την απαιτούμενη πολυπλοκότητα για να τρέξουν ένα πλήρες πολυαλγοριθμικό πρόγραμμα που να κάνει δουλειά αντίστοιχη με αυτήν που κάνει ένα μοναδικό thread π.χ. του x264. Είναι πολύ απλές επεξεργαστικές μονάδες, σχεδιασμένες για να τρέχουν σύντομα και trivial κομμάτια κώδικα (hint: γιατί έτρεχαν τα σάλια μεταξύ άλλων και των x264 developers όταν διάβαζαν τα specs του άδοξα ακυρωθέντος Larrabee ). Η δύναμή τους είναι ο τεράστιος αριθμός τους και τίποτ' άλλο. Για να εκμεταλλευτείς αυτήν τη δύναμη (εδώ είναι και άλλη μία σημαντική δυσκολία στο GPGPU video encoding, πέραν του integer VS FP debate), πρέπει να προσαρμόσεις το συνολικό αλγόριθμό σου για να φέρεις την SIMD λογική στα όριά της, δηλαδή πολύ fine-grained parallelism και πολύ μεγάλο διαμερισμό των δεδομένων εισόδου. Κάτι που δεν είναι εύκολα εφικτό στο video encoding

2. Περιορισμένες ποσότητες μνήμης στην οποία μπορεί να έχει πρόσβαση ο κάθε SP

3. Η μετακίνηση δεδομένων μεταξύ RAM και VRAM κοστίζει πολλούς κύκλους

4. Δεν υπάρχει shared μνήμη μεταξύ CPU και GPU, γεγονός που δημιουργεί θέματα συγχρονισμού και δρομολόγησης των kernels που κάνεις dispatch για εκτέλεση στους SPs, όταν χρειάζεται να έχεις κάποιου είδους master thread που θα τρέχει στη CPU

 

 

Πέραν δηλαδή από τις συνήθεις δυσκολίες του παράλληλου προγραμματισμού με κυριότερη την απαίτηση για εφεύρεση συχνά νέων μη τετριμμένων αλγορίθμων, εδώ υπάρχουν και έξτρα προκλήσεις από το αρκετά περιοριστικό προγραμματιστικό μοντέλο που επιβάλλει η αρχιτεκτονική των GPU. Πολύ χαρακτηριστική είναι μία δήλωση ενός από τους developers του x264 (νομίζω ο Glasser, μπορεί να ήταν και ο Merrit), δε μπορώ τώρα να την βρω για να τη γράψω verbatim αλλά πήγαινε κάπως έτσι: «Ξέρεις πόσοι μας προσέγγισαν κατά καιρούς, δηλώνοντας την προθυμία τους να δουλέψουν για τη μεταφορά τμημάτων του κώδικα του x264 στη GPU; Αφού ξοδεύαμε αρκετή ώρα κάθε φορά για να τους κατατοπίσουμε σχετικά με τη λογική του x264 και μετά από μερικές επισκέψεις τους για ερωτήσεις στο #x264dev, σε λίγο καιρό τους χάναμε χωρίς ποτέ να δούμε κάποιον κώδικα από αυτούς».

 

 

...a.k.a. development_wise και με δεδομένη την αρχιτεκτονική των GPUs, παίζει να είναι πιο φθηνό να γραφτεί από την αρχή ένα αλγόριθμος συμπίεσης για gpgpu (με τις ιδιαιτερότητες των SP κατά νου) παρά να προσπαθούν να portάρουν κομμάτια του x264 σε cuda...

[parsifal]

digekas, δεν ξέρω καθόλου το είδος των αλγορίθμων που τρέχουν σε FEA, δυστυχώς δεν έχω μελετήσει καθόλου σχετικά με πεπερασμένα στοιχεία. Δεν αμφιβάλλω όμως ότι υπάρχουν tasks πολύ βολικά και επιλύσιμα με extreme SIMD programming. Π.χ. οι clients για το Folding@home επιτυγχάνουν τρομερές επιδόσεις σε κάρτες NVIDIA και ATI σε σχέση με την εκτέλεση στη CPU. Άρα, εκεί εκ του αποτελέσματος αποδεικνύεται ότι είναι πιο εύκολα τα πράγματα για το γράψιμο GPGPU κώδικα.

 

 

...a.k.a. development_wise και με δεδομένη την αρχιτεκτονική των GPUs, παίζει να είναι πιο φθηνό να γραφτεί από την αρχή ένα αλγόριθμος συμπίεσης για gpgpu (με τις ιδιαιτερότητες των SP κατά νου) παρά να προσπαθούν να portάρουν κομμάτια του x264 σε cuda...

Ναι, δεν αποκλείεται να είναι κι αυτός ένας παράγοντας που οι έως τώρα προσπάθειες για GPU-οποίηση του x264 απέβησαν άκαρπες. Και όχι απλά «πιο φθηνό», αλλά ίσως ο μόνος εφικτός τρόπος για να επιτευχθεί substantial/απτή επιτάχυνση.

[parsifal]

TMPGEnc δεν τον έχω τεστάρει για πολλά χρόνια, αλλά δεδομένου ότι πριν λίγο καιρό έκανε commercial licensing του x264 και πλέον χρησιμοποιεί αυτόν ως encoder, φαντάζομαι πως ποιότητα και ταχύτητα θα είναι πάνω κάτω η ίδια με τα vanilla x264 binaries (give or take sth λόγω προόδου στα νεότερα x264 revisions). CUDA χρησιμοποιεί για κάποια φίλτρα νομίζω. Εκεί θα έχει κάποιο speedup πιθανότατα, αλλά υπάρχουν GPGPU filters και για Avisynth (π.χ. fft3dGPU).

 

Btw, η Pegasys δίνει 14ήμερη trial.

 

Φαίνεται πως έπεσα έξω στο σημειωμένο με bold κομμάτι: TMPEnc VMW5 and x264: slow or not?