Transkodowanie MPEG2 do MPEG4 H.264 na serwerze IBM xSeries x345 - czy to możliwe?

Mon Nov 26, 2007 11:22 am   

Witajcie.

Przegladam strony w Internecie w poszukiwaniu rozwiazania do transcodowania
w czasie rzeczywistym streamu MPEG2 z satelity do MPEG4 (H.264 AVC), aby
mozna to bylo puscic po xDSL do 1.5-2Mbps.

Rozwiazania komercyjne typu OptiBase czt Scopus czy Allegro, kosztuja
dziesiatki tysiecy dolarow, np. OptiBase MGW1100 to koszt 80.000$ za 8
programow w locie do H.264 AVC.

Czy ktos z Was probowal uzywac kart DVB na linuxie z MPEG4IP i serwerem
Darwin? Jak to chodzi? Ja bym chcial sprobowac to zrobic na serwerku rack
typu IBM eServer xSeries x345 z 2 x XEON 2.40Ghz i 4GB RAM. Czy serwer
ztranskoduje w czasie rzeczywistym MPEG2 =>> MPEG4 AVC? Czy to moze pojsc
czy nie warto probowac?

pozdrawiam
exiled

Mon Nov 26, 2007 11:30 am   

Chyba w czasie quasi-rzeczywistym. Bo MPEG2 a tym bardziej 4 to nie są
formaty czasu rzeczywistego...

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Mon Nov 26, 2007 11:51 am   

hmm z angielskiego to bedzie "on-the-fly" czyli transcoding w locie...


"Exiled" <exiled@onet.eu> wrote in message
news:fie6or$nb0$1@inews.gazeta.pl...

Mon Nov 26, 2007 12:05 pm   

"Exiled" <exiled@onet.eu> wrote in message
news:fie6or$nb0$1@inews.gazeta.pl...


wg tego co pisza chlopaki od cinelerry to 4xopteron daje rade z
1920x1080 w czasie rzeczywistym, IMHO powinno sie wyrobic bez klopotow,
oczywiscie mozesz miec problem z ksztaltowaniem bitrate - dobrze byloby
go ustabilizowac by byl jak nablizszy CBR (wychodzie ze najrozsadniej
byloby h.264 enkapsulowac w TS z dodanym stuffingiem).
wstpenie sprawdz sobie to np w VLC - posiada mozliwosc transkodowania
zwyego strumienia i moze byc serwerkiem, poza tym ffmpeg i mencoder
pozwolic powinny na proby z transkodowaniem w czasie rzeczywistym

Mon Nov 26, 2007 12:07 pm   

"A. Grodecki" <brak@adresu.com> wrote in message
news:fie76v$3o6$1@atlantis.news.tpi.pl...

jak najbardziej rzeczywistego - w niemal kazdym studio TV kompresja
odbywa sie w czasie rzeczywistym, co wiecej w polaczeniu z
multiplekserem statystycznym nastepuje dynamiczne sterowanie
przydzielonym pasmem do kazdego z enkoderow

Mon Nov 26, 2007 12:41 pm   

PAndy napisał(a):


Co nie oznacza czasu rzeczywistego. Przeciez formaty skompresowane
operują na grupach ramek. Tak więc o czasie rzeczywistym nie może byc
mowy z definicji.
Przesunięcie czasowe musi powstać, więc nie ma obróbki w czasie
rzeczywistym!

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Mon Nov 26, 2007 3:27 pm   

Mon Nov 26, 2007 3:39 pm   

Mon Nov 26, 2007 3:59 pm   

On Mon, 26 Nov 2007 12:41:37 +0100, A. Grodecki wrote:
[quote:16a1f5fae6]Co nie oznacza czasu rzeczywistego. Przeciez formaty skompresowane
operują na grupach ramek. Tak więc o czasie rzeczywistym nie może byc
mowy z definicji.
Przesunięcie czasowe musi powstać, więc nie ma obróbki w czasie
rzeczywistym!
[/quote:16a1f5fae6]
Skoro mu nie przeszkadza ani jedna kompresja ani druga,
to pewnie i opoznienie transkodowania nie przeszkodzi.

J.

Mon Nov 26, 2007 4:11 pm   

Mon Nov 26, 2007 6:50 pm   

Przemysław Szeremiota napisał(a):


Słusznie.
Choć przyznasz, że np korekcja kolorów w formacie analogowym lub choćby
DV, gdzie operujemy na jednej ramce, to inny wymiar pojęcia "czasu
rzeczywistego" niż wstępna akwizycja iluś tam obrazów w celu przetworzenia.
Różnica między transkoderami "w czasie rzeczywistym" a postprocessingiem
całego materiału na pececie 386 różni się tylko długością bufora...

A gdyby np nagrywać partiami po 5 minut i transkodować to też byłby
chyba "ścisły rygor czasowy"?

Nie upieram się przy "definicji" czasu rzeczywistego, o której
wspomniałem. Można przyjąć, że czas rzeczywisty to taki, gdzie
obserwator nie zauważa opóźnienia, albo jest ono nieuciążliwe. Niech
będzie. Ale to nie jest prawdziwy twardy real time, jaki zapewniają
układy analogowe i formaty analogowe. Ani nawet taki cyfrowy pseudo real
time, gdzie opóźnienie wynika jedynie z taktowania przetworników i
filtrów cyfrowych i jest poniżej poziomu jakiejkolwiek ludzkiej percepcji.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Mon Nov 26, 2007 7:04 pm   

W obu podanych przez Ciebie przykładach (z 386 i z nagrywaniem po 5
minut) system nie jest real-time! ... Zauważ, że dla obrazu 25fps masz
kolejna klatkę co 40ms... możesz mieć grupę 10 klatek co 400ms, może być
100 klatek co 4s - wychodzi na to samo, średnio masz klatkę co 40ms... .
386 czegoś takiego nie wydoli... nagrywając po 5 minut fakt, możemy coś
podobnego osiągnąć, ale jest różnica w opóźnieniu 5 minut i opóźnieniu
na poziomie ułamka sekund.. raczej nikt nie zauważy, że sąsiad z gola
zaczął się cieszyć 1 sekundę wcześniej i jedną sekundę wcześniej
wystrzelił mu korek od szampana ... . W przypadku 5 minut różnica
byłaby już znaczna... .

Mon Nov 26, 2007 7:27 pm   

Konop napisał(a):


Czyli sugerujesz, że różnica jest jednak nie jakościowa a ilościowa?
;)

386 czy 986 - to nie ma merytorycznego znaczenia.

Zauważ, że w np analogowej korekcji koloru opóźnienie jest tylko takie
jakie wnoszą filtry, czyli żadne.
W przypadku DV już jest to opóźnienie jednaj ramki. I już W CZASIE
RZECZYWISTYM nie da się porównać sygnału wchodzącego z wychodzącym, bo
są czasowo przesunięte o co najmniej długośc jednej pełnej ramki ale tak
naprawdę tylko konstruktor wie o ile.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Mon Nov 26, 2007 8:16 pm   

Użytkownik "A. Grodecki" <brak@adresu.com> napisał w wiadomości
news:fif110$fo$1@atlantis.news.tpi.pl...

No ale te transkodery nie rozciągają na wyjściu 5 sekund w 6 sekund,
prawda? A wyjście z postprocessingu na pececie klasy 386 rozciągnie (i
to ostro) -- nie dasz rady podać danych na wyjście odpowiednio szybko:
tu masz właśnie rygor, aby (przynajmniej średnio) przetwarzanie ramki
nie było dłuższe niż trwa jej wyświetlanie; wstępne opóźnienie akwizycji
jest do zaakceptowania. Gdyby ten 386 wyrobił się z samym
transkodowaniem tak, żeby nadążyć ciągle podawać materiał wyjściowy, też
stanowiłby transkoder real-time -- bo rozmiar bufora mógłby wtedy być
minimalny (taki, jaki potrzebny do skutecznego rozpoczęcia
przetwarzania).



O ile transkodowanie nie wydłuży tych pięciu minut do sześciu minut, to
będzie chyba jednak robione w real-time? Nie ma przecież koncepcyjnej
różnicy między przetwarzaniem porcji 5-minutowej a przetwarzaniem porcji
1/25-sekundowej. Byle nadążyć z wyjściem...

W takim przypadku jak podałeś, jeśli 386 (czy tam 986) nadąża z
generowaniem wyjścia, to masz system real-time: a buforowanie
pięciominutowej porcji czy nawet kilku godzin sygnału to wtedy już
jedynie Twoja decyzja: mógłbyś sobie to darować (skoro nadąża ),
widocznie chcesz mieć rezerwę.



Ja bym nie kładł nacisku na "zauważalność".


Masz rację, w przetwarzaniu cyfrowym real-time w sensie "brak
opóźnienia" z definicji nie istnieje.


Pozdrawiam,
Przemysław Szeremiota

Tue Nov 27, 2007 8:12 am   

A. Grodecki schrieb:

to, co ty wypisujesz to prawda trzeciego rodzaju, czyli gówno prawda.
Systemy real time, czyli czasu rzeczywistego muszą mieć deterministyczne
maksymalne opóźnienie, które musi być dodatkowo adekwatne do zadania.
Opóźnienie może wynosić ułamek femtosekundy, albo kilka lat. Warunkiem
koniecznym systemu czasu rzeczywistego jest to, że pasmo przetwarzania
jest niewęższe od pasma sygnału dochodzącego. Zauważ też, że wcale
opóźnienie nie musi być stałe. Zależy to od zadania.

Waldek