Transkodowanie MPEG2 do MPEG4 H.264 AVC w czasie rzeczywistym

Michał Baszyński napisał(a):

Już się w to nie bawię. Od kiedy wszyscy kupują na eBay, jest straszny tłok i ceny bardzo poszybowały. Ale widziałem ze 2 razy. Oczywiście w USA, bo w EU to co najwyżej głowice od szczoteczki do zębów... :)

Michał Baszyński napisał(a): [ciap]

właśnie że jest. Choć w sumie jest i nie jest. Jako element handlowy to nie ma od dawna ale jako część serwisowa jest. Wtedy obejmuje to tylko sam moduł (bez programu który da się sciągnąć z www, bez instrukci i bez przewodu RSowego). Jak potrzebujesz to się odezwij na mail.

Andrzej Kamieniecki

A. Grodecki pisze:

Przetwarzanie w czasie rzeczywistym nie oznacza w tym przypadku braku opóźnienia tylko zdolność do przetwarzania tych 25 czy 30 ramek na sekundę. Jeśli koder czy transkoder nie wyrobi się w tym czasie to będzie ciągle zwiększał opóźnienie i sekwencja będzie się rozwlekać w czasie

PAndy pisze:

Nieprawda. H.264 może korzystać z referencji do przyszłych ramek (ramki typu B). Oczywiście wiąże się to z pewną latencją, ale jeśli koder korzysta powiedzmy z 15 ramek referencyjnych to potrzebuje mieć w buforze te 15 ramek do przodu zanim coś "wypluje".

Tutaj pełna zgoda. Jeśli to dodać do powyższego mamy 1-2 sekundy opóźnienia (czy też trochę więcej dla sekwencji tv 25 fps) przy kodowaniu/transkodowaniu.

"Phoenix" <p_h_o_e_n_i_x_8_2@tenbit_pl._bez_podkreslnikow> wrote in message news:fijhhj$ls8$ snipped-for-privacy@atlantis.news.tpi.pl...

gdzie nieprawda? korzystanie z ramek B jest optional a nie mandatory - nie mamy obowiazku korzystac z ramek B, nie mamy obowiazku korzystac nawet z ramek P, wszystkie ramki moga byc I

powtarzam to co wczesniej napisalem - rezygnacja z ramek B daje nam mozliwosc kodowania z latency mniejszym niz 1 obraz i to oddala zarzut o tym ze h.262 czy h.264 nie sa dostosowane do kompresji w czasie rzeczywistym (czyli w zalozeniu ze czas rzeczywisty pojmujemy jako latency mniejsze niz 1 obraz)