Transkodowanie MPEG2 do MPEG4 H.264 AVC w czasie rzeczywistym

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

Reply to
Exiled
Loading thread data ...

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

Reply to
A. Grodecki

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

Reply to
Exiled

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
Reply to
PAndy

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

Reply to
PAndy

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!

Reply to
A. Grodecki

po pierwsze kazdy z tych formatow moze operowac wylacznie na ramkach w histori (I i P), po drugie i tak proces kompresji wprowadza latency wiec problem ten jest mniej istotny niz mogloby sie to wydawac na pierwszy rzut oka - przejscie przez transkoder to zawsze ok 500 - 1500ms minimum.

Reply to
PAndy

A. Grodecki snipped-for-privacy@adresu.com napisał w news:fieblq$ppk$ snipped-for-privacy@nemesis.news.tpi.pl...

Coś chyba ci się pomyliło...

I co z tego? Dowolny sygnał też operuje na grupach... sinusoid i nie można go odebrać BEZ opóźnienia, a zdaje się, że taką to malignę (tzn. "bez opóźnienia") "czasu rzeczywistego" sobie uroiłeś i do niej się odnosisz...

Definicji urojeń?

No właśnie (odwołujesz się do bredni) !!!

Czasami warto pomyśleć, a nie klepać farmazony wzorem piesków niejakiego Paw- łowa.

Nie ma "obróbki" czegokolwiek zachodzącej "bez czasu/poza czasem" (z definicji). Wobec tego twoja definicja "obróbki w czasie rzeczywistym" jest imaginacyją cokol- wiek nie z tej ziemi.

JeT.

Reply to
Jerzy Turynski

Skoro mu nie przeszkadza ani jedna kompresja ani druga, to pewnie i opoznienie transkodowania nie przeszkodzi.

J.

Reply to
J.F.

Użytkownik "A. Grodecki" snipped-for-privacy@adresu.com napisał w wiadomości news:fieblq$ppk$ snipped-for-privacy@nemesis.news.tpi.pl...

A jaka to definicja?

Co ma przesunięcie czasowe do mieszczenia się w limitach czasowych? Czas rzeczywisty w przetwarzaniu to nie "brak opóźnienia", tylko "ścisły rygor czasowy" -- tylko tyle i aż tyle.

Pozdrawiam, Przemysław Szeremiota

Reply to
Przemysław Szeremiota

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.

Reply to
A. Grodecki

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... .
Reply to
Konop

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.

Reply to
A. Grodecki

Użytkownik "A. Grodecki" snipped-for-privacy@adresu.com napisał w wiadomości news:fif110$fo$ snipped-for-privacy@atlantis.news.tpi.pl...

postprocessingiem

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

Reply to
Przemysław Szeremiota

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

Reply to
Waldemar

to nie tak, opoznienie rowne/ponizej jednej ramki jest takie samo jak opoznienie 120ns - nie ma to zadnej roznicy - 1/fps to najmniejszy rozroznialny przedzial czasu. Teraz mylnie zakladasz ze enkoder potrzebuje wiecej niz jedna ramke na proces enkodowania - sa dostepne enkodery ktore moga nie wprowadzac zadnego opoznienia (czas przetwarzania1/fps) tylko ze z punktu widzenia studia cyfrowego to i tak nie ma sensu bo w studio stosuje sie dosc intensywnie bufory, korektory podstawy czasu itd. Wynika stad ze jesli chcesz porownac to co widzi kamera i to co zaobserwujesz ty to czasy opoznienia moga byc nawet kilkusekundowe. Co wazniejsze w przecietnym studio TV stosujacym nadajacycm transmisje w formacie cyfrowym enkodery sterowane sa informacja zwrotna z multipleksera - sa kanly dla kotrych wazna jest jakosc i moga te kanaly wplywac na stopien kompresji pozostalych kanalow - multiplekser musi wyprodukowac strumien bitowy ktory nie przekroczy w zadnym wypadku poejmnosci informacyjnej modulatora cyfrowego. Stad niektore multipleksery nie tylko wysylaja informacje zwrotna do enkoderow ale same potrafia operowac na np skladni MPEG'a, moga dokonac rekwantyzacji sygnalu w locie (w tym procesie operuje sie bezposrednio na danych i nie ma potrzeby dekodowania/enkodowania sygnalu wizyjnego), moga usunac kolejne klatki ustwiajac flage powtarzania ostatniej ramki (to brutalna metoda stosowana w krytycznych sytuacjach). Ogolnie wszystkie enkodery hardware sa enkderami czasu rzeczywistego, tylko od ustawien operatora zalezy latency takiego enkodera, w praktyce DVB zaklada ze klatka I nie jest rzadziej niz co 500ms (dla MPEG-2) czyli dlugosc GOP wynosi 12 obrazow.

Reply to
PAndy

"Przemysław Szeremiota" snipped-for-privacy@TOTEZicpnet.pl wrote in message news:fif636$2krm$ snipped-for-privacy@opal.icpnet.pl...

i nie inaczej jest w przetwarzaniu analogowym - kawalek drutu wprowadzi opoznienie a tym bardziej pozostale elementy - predkosc swiatla jest skonczona

Reply to
PAndy

PAndy napisał(a):

Dochodzimy do tego, że czas jest względny :) Czyli nie tędy droga. Definicja, że system czasu rzeczywistego to taki, który przetwarza dane na bieżąco podoba mi się. Ale już uzupełnienie, że "jest w stanie" przetwarzać na bieżąco, czyli niekoniecznie przetwarza, już raczej nie ma nic wspólnego z systemem czasu rzeczywistego. Podobnie stwierdzenie, że opóźnienie między wejściowym i wyjściowym sygnałem może być dowolne. Myślę, że czas przetwarzania w systemie czasu rzeczywistego musi być powiązany z prędkością procesu lub przynajmniej percepcji obiektu, inaczej pojęcie traci sens. Kilkugodzinne opóźnienie w transkodowaniu sygnału video nijak się ma do systemu czau rzeczywistego, nawet jeśli jest robione na bieżąco(?!)

Myślę też, że pojęcia s.c.r. nie ma co mieszać z fizycznymi ograniczeniami czasu propagacji sygnału elektrycznego w materiałach. Oscyloskop cyfrowy Tektronixa, który gubi ważny sygnał, bo procesor nie wyrabia się z ciągłą akwizycją próbek nie jest urządzeniem czasu rzeczywistego z powodu opóźnień w wejściowym układzie próbkującym.

Reply to
A. Grodecki

Waldemar napisał(a):

Dziękuję za podsumowanie :)

Taką 'słuszną' definicję wyczytałeś. A co w przypadku, gdy pasmo jest niewęższe ale są przerwy w przetwarzaniu? W efekcie dane giną albo wydłuża się odstęp wejście-wyjście?

Zauważ też, że wcale

A może byc stale rosnące ale nie dłuższe niż 100 lat?

Reply to
A. Grodecki

wprowadza sie dlatego pojecie latency (polski termin zwloka ale nie jestem pewien) - nie ma kilkugodzinnego opoznienia - tym rozni sie wlasnie system online od offline ze tej zwloki nie ma

hm... karkolomne prownanie - oscyloskop vs enkoder h.264

Reply to
PAndy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.