TV Samsung serii C - drżenie obrazu na MUX3

informacje techniczne związane z wdrażaniem trzeciego multipleksu DVB-T
lustracja
Posty: 810
Rejestracja: 11 grudnia 2013, o 08:09

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: lustracja »

jaką wojenkę kol :lol:
nadwrażliwy jesteś do bulu.
podsumowałem twoje podsumowanie.

akurat mam takie same zdanie w sprawie zgłaszania tego do instytucji jak kol adac.
adac pisze:A oni spokojnie to oleją i odeślą do producenta albo sąsiada który doradził taki zakup.ps. @pawell nie traktuj tego jako prowokację, ja tylko napisałem to prosto.
to jest problem producenta i pisanie do urzędów tym się skończy chyba że chcesz te urzędy zaczepić.

Awatar użytkownika
Puma
Posty: 2994
Rejestracja: 13 kwietnia 2009, o 08:48
Miejscowość: Chojnice
Odbiornik: LG 32LM6370 WebOS 4.5, HbbTV 2.0.1
Instalacja antenowa: Dipol 44/21-69 Tri Digital (bez wzmacniacza), ~7m.n.p.t.
Nadajnik - obiekt nadawczy: Trzeciewiec (63km)

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: Puma »

Sens jest pisać wyłącznie do TVP lub Samsunga, TVP bo pakuje ile się tylko da do MUX 3 a Samsung za felerną partie TV serii C.

pawelll
Posty: 732
Rejestracja: 18 lipca 2011, o 23:04

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: pawelll »

Koledzy ja mimo wszystko wierzę w moc sprawczą "papierów" i nękania urzędów. Jeśli robi się to w sposób systematyczny i zorganizowany to ma szansę przynieść efekt. Nawet jeśli tym efektem będzie to, że ktoś (TVP, producenci) potwierdzą oficjalnie, że problem jest ale, że nie da się go rozwiązać i pozostaje wymiana odbiorników to i tak będzie to jakaś informacja. Kluczowe dla zagadnienia jest też oszacowanie skali problemu. Próbowałem to zrobić używając dostępnych danych i metod szacowania (co nie wszystkim się spodobało). Jeżeli skala problemu jest duża to po odpowiedniej akcji informacyjnej nie powinno być problemem spowodowanie wysłania dużej ilości zgłoszeń. No chyba, że większość machnęła na to ręką i tyle. Może zwyciężyło dość powszechne przeświadczenia, że "i tak się nie uda". Zresztą popatrzcie na ten wątek. Odzywają się 2-3 osoby które mają ten problem, reszta dyskutantów robi to "pro publico bono". Więc może to wszystko bez sensu? Może przestańmy dyskutować i oceniać jakiekolwiek działania TVP czy innych nadawców. Skoro i tak nie mamy na nic wpływu. To może jeszcze dalej pójdziemy, niech Emitel zamknie to forum bo skoro i tak nic nie jesteśmy w stanie zmenić...

Przepraszam za lekki sarkazm ale wydawało mi się, że forum służy właśnie temu, żeby próbować wypracować jakąś opinię w konkretnym temacie i podjąć działania aby to przeforsować. Jeśli tak nie jest, to de facto pozwalamy na sprowadzenie siebie (przez Emitela, TVP, innych nadawców) do roli "testowaczy" mniej lub bardziej przemyślanych nowych rozwiązań i technologii.

Oczywiście nie podważam roli "edukacyjnej" forum, można wykorzystywać takie sytuacje, żeby czegoś pożytecznego się nauczyć ale moim zdaniem to za mało. Jeśli jest zgłoszony problem to trzeba dążyć do jego rozwiązania.

Bartt

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: Bartt »

sirdaniel pisze:.. Oprócz tego ktoś pytał jak sprawdzić zaawansowane dane strumienia. Można po konwersji z ts do mkv, wrzucić plik do programu Avinaptic i zrobić analizę DRF.
Parametry na które zwracać uwagę to:
z mediainfo
GOP (np M=4 N=40) jak wielka jest zamknięta grupa obrazów
Poziom h264 @4.0/4.1 - 4.1 może powodować problem w niekompatybilnych dekoderach, ale wątpię czy i tak 4.0 jest przekraczany, ale może chodzi tu o max bitrate bufora VBV
MBAFF/Interlaced - przeplot
z avinaptic
Weighted prediction - polepsza kompresję i może powodować problemy ze starymi dekoderami
8x8dct - zwiększa kompresję i może powodować problemy ze starymi dekoderami
average/max drf - czyli stopień kompresji
Pozostałe właściwości się nie zmieniają.
Poniżej analiza 2 strumieni (TVP Rozrywka - działa źle, TVN - działa dobrze).
Co ciekawe, w plikach mkv zrobionych z kanałów z mux-3, dźwięk jest rozjechany z obrazem.
Name 20140223_1155 TVP Rozrywka.mkv
Date Sun, 23 Feb 2014 11:57:56 +0100
Size 8,800,223 bytes (8.392547 MiB)

Magic

File type data

Generic infos

Duration 00:00:30 (30.24 s)
Container matroska
Production date Sun, 23 Feb 2014 11:57:56 +0100
Total tracks 2
Track nr. 1 video (V_MPEG4/ISO/AVC) {und}
Track nr. 2 audio (A_MPEG/L2) {und}
Muxing library libebml v1.3.0 + libmatroska v1.4.1
Writing application mkvmerge v6.7.0 ('Back to the Ground') 32bit built on Jan 8 2014
15:03:17

Relevant data

Resolution 720 x 576
Width multiple of 16
Height multiple of 32
Average DRF 28
Standard deviation 0
Std. dev. weighted mean 0

Video track

Codec ID V_MPEG4/ISO/AVC
Resolution 720 x 576
Display resolution 1047 x 576 (pixels)
Frame aspect ratio 5:4 = 1.25
Pixel aspect ratio 349:240 = 1.454167
Display aspect ratio 349:192 = 1.817708
Framerate 50 fps
Stream size 8,176,918 bytes (7.798117 MiB)
Duration (bs) 00:00:30 (30.24 s)
Bitrate (bs) 2163.20582 kbps
Qf 0.104321

Audio track

Codec ID A_MPEG/L2
Sampling frequency 48000 Hz
Channels 2
Stream size 604,800 bytes
Bitstream type (bs) MPEG-1 Layer II
Frames (bs) 1,260
Duration (bs) 00:00:30 (30.24 s)
Chunk-aligned (bs) Yes
Bitrate (bs) 160 kbps CBR
Sampling frequency (bs) 48000 Hz
Mode (bs) stereo
Padding (bs) No
Emphasis (bs) none

Video bitstream

Bitstream type MPEG-4 Part 10
SPS id 0
Profile Main@L3
Num ref frames 4
Aspect ratio 16:11 (16:9 PAL pixel shape)
Chroma format YUV 4:2:0
PPS id 0 (SPS: 0)
Entropy coding type CABAC
Weighted prediction No
Weighted bipred idc No
8x8dct No
Total frames 1,512
Drop/delay frames 0
Corrupt frames 0

P-slices 343 ( 22.685 %) #####
B-slices 1134 ( 75.000 %) ###############
I-slices 35 ( 2.315 %)
SP-slices 0 ( 0.000 %)
SI-slices 0 ( 0.000 %)

DRF analysis

average DRF 28
standard deviation 0
max DRF 28

DRF<28 0 ( 0.000 %)
DRF=28 1512 (100.000 %) ####################
DRF>28 0 ( 0.000 %)

P-slices average DRF 28
P-slices std. deviation 0
P-slices max DRF 28

B-slices average DRF 28
B-slices std. deviation 0
B-slices max DRF 28

I-slices average DRF 28
I-slices std. deviation 0
I-slices max DRF 28

Profile compliancy

Selected profile MTK PAL 6000
Resolution Ok
Framerate 50 <> 25
Min buffer fill 73%

This report was created by AVInaptic (16-12-2011) on 23-02-2014 11:59:43
Name 20140223_1139 TVN.mkv
Date Sun, 23 Feb 2014 11:48:03 +0100
Size 8,676,200 bytes (8.274269 MiB)

Magic

File type data

Generic infos

Duration 00:00:31 (31.48 s)
Container matroska
Production date Sun, 23 Feb 2014 11:48:02 +0100
Total tracks 2
Track nr. 1 video (V_MPEG4/ISO/AVC) {und}
Track nr. 2 audio (A_MPEG/L2) {und}
Muxing library libebml v1.3.0 + libmatroska v1.4.1
Writing application mkvmerge v6.7.0 ('Back to the Ground') 32bit built on Jan 8 2014
15:03:17

Relevant data

Resolution 720 x 576
Width multiple of 16
Height multiple of 32
Average DRF 26.6277
Standard deviation 2.754208
Std. dev. weighted mean 2.256989

Video track

Codec ID V_MPEG4/ISO/AVC
Resolution 720 x 576
Display resolution 1047 x 576 (pixels)
Frame aspect ratio 5:4 = 1.25
Pixel aspect ratio 349:240 = 1.454167
Display aspect ratio 349:192 = 1.817708
Framerate 50 fps
Stream size 7,936,160 bytes (7.568512 MiB)
Duration (bs) 00:00:31 (31.48 s)
Bitrate (bs) 2016.813215 kbps
Qf 0.097261

Audio track

Codec ID A_MPEG/L2
Sampling frequency 48000 Hz
Channels 2
Stream size 721,152 bytes
Bitstream type (bs) MPEG-1 Layer II
Frames (bs) 1,252
Duration (bs) 00:00:30 (30.048 s)
Chunk-aligned (bs) Yes
Bitrate (bs) 192 kbps CBR
Sampling frequency (bs) 48000 Hz
Mode (bs) stereo
Padding (bs) No
Emphasis (bs) none

Video bitstream

Bitstream type MPEG-4 Part 10
SPS id 0
Profile Main@L3
Num ref frames 4
Aspect ratio 16:11 (16:9 PAL pixel shape)
Chroma format YUV 4:2:0
PPS id 0 (SPS: 0)
Entropy coding type CABAC
Weighted prediction No
Weighted bipred idc No
8x8dct No
Total frames 1,574
Drop/delay frames 0
Corrupt frames 0

P-slices 387 ( 24.587 %) #####
B-slices 1154 ( 73.316 %) ###############
I-slices 33 ( 2.097 %)
SP-slices 0 ( 0.000 %)
SI-slices 0 ( 0.000 %)

DRF analysis

average DRF 26.6277
standard deviation 2.754208
max DRF 35

DRF<17 0 ( 0.000 %)
DRF=17 7 ( 0.445 %)
DRF=18 6 ( 0.381 %)
DRF=19 12 ( 0.762 %)
DRF=20 20 ( 1.271 %)
DRF=21 23 ( 1.461 %)
DRF=22 37 ( 2.351 %)
DRF=23 82 ( 5.210 %) #
DRF=24 87 ( 5.527 %) #
DRF=25 217 ( 13.787 %) ###
DRF=26 231 ( 14.676 %) ###
DRF=27 217 ( 13.787 %) ###
DRF=28 292 ( 18.551 %) ####
DRF=29 165 ( 10.483 %) ##
DRF=30 88 ( 5.591 %) #
DRF=31 36 ( 2.287 %)
DRF=32 21 ( 1.334 %)
DRF=33 20 ( 1.271 %)
DRF=34 8 ( 0.508 %)
DRF=35 5 ( 0.318 %)
DRF>35 0 ( 0.000 %)

P-slices average DRF 24.824289
P-slices std. deviation 2.255084
P-slices max DRF 34

B-slices average DRF 27.448007
B-slices std. deviation 2.274754
B-slices max DRF 35

I-slices average DRF 19.090909
I-slices std. deviation 1.658105
I-slices max DRF 25

Profile compliancy

Selected profile MTK PAL 6000
Resolution Ok
Framerate 50 <> 25
Min buffer fill 69%

This report was created by AVInaptic (16-12-2011) on 23-02-2014 11:51:38

lustracja
Posty: 810
Rejestracja: 11 grudnia 2013, o 08:09

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: lustracja »

I wygląda, że w tym jest problem.
TVP daje stały parametr DRF=28 Standard deviation 0
A TVN czyli należy przyjąć że przed 15.02 tak było też w TVP DRF jest dynamiczny.
DRF analysis

average DRF 26.6277
standard deviation 2.754208
max DRF 35.


TVP ustawiło to dosyć wysoko jak rozumiem i na sztywno

----posty połączono

TVP DRF
DRF<28 0 ( 0.000 %)
DRF=28 1512 (100.000 %)
DRF>28 0 ( 0.000 %)

----posty połączono

TVN DRF
DRF<17 0 ( 0.000 %)
DRF=17 7 ( 0.445 %)
DRF=18 6 ( 0.381 %)
DRF=19 12 ( 0.762 %)
DRF=20 20 ( 1.271 %)
DRF=21 23 ( 1.461 %)
DRF=22 37 ( 2.351 %)
DRF=23 82 ( 5.210 %) #
DRF=24 87 ( 5.527 %) #
DRF=25 217 ( 13.787 %) ###
DRF=26 231 ( 14.676 %) ###
DRF=27 217 ( 13.787 %) ###
DRF=28 292 ( 18.551 %) ####
DRF=29 165 ( 10.483 %) ##
DRF=30 88 ( 5.591 %) #
DRF=31 36 ( 2.287 %)
DRF=32 21 ( 1.334 %)
DRF=33 20 ( 1.271 %)
DRF=34 8 ( 0.508 %)
DRF=35 5 ( 0.318 %)
DRF>35 0 ( 0.000 %)

P-slices average DRF 24.824289
P-slices std. deviation 2.255084
P-slices max DRF 34

B-slices average DRF 27.448007
B-slices std. deviation 2.274754
B-slices max DRF 35

I-slices average DRF 19.090909
I-slices std. deviation 1.658105
I-slices max DRF 25

pawelll
Posty: 732
Rejestracja: 18 lipca 2011, o 23:04

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: pawelll »

Tyle, że ta analiza potwierdza tylko "czarno na białym" to co było wiadomo (a może lepiej co wszyscy przypuszczali). TVP "podkręciła" kompresję wraz z innymi parametrami, w tym przypadku DRF (Detail Removing Factor). Nazwa mówi sama za siebie. To już zresztą opisywaliśmy dość chyba zgodnie stwierdzając, że obraz jest mniej wyrazisty (szczegółowy).

Żeby nie było- nie mam nic przeciwko dalszym analizom, powyższe namacalne potwierdzenie wcześniejszych opinii warte jest pochwały.
Być może dobrze byłoby porównywać strumienie "stare" i "nowe" od tego samego nadawcy ze tego samego multiplexu. Jakby co to ja jakieś stare fragmenty z TVP1 i Kultury mam.

Oczywiście nie jest wykluczone, że problem drgań leży w tym, że odbiorniki nie są w stanie poprawnie dekodować tak "podkręconej" kompresji, w tym DRF.

Bartt

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: Bartt »

Być może przyczyną są agresywne ustawienia parametrów DRF. Choć z drugiej strony nie wiem jak to się ma do problemów z przeplotem :o .
Dla porównania analiza strumienia dla TVP Regionalnej, która to jako jedyna z mux-3 działa u mnie prawidłowo (widać parametry DRF podobne do TVN):
Name 20140223_1338 TVP Rzeszow.mkv
Date Sun, 23 Feb 2014 13:40:56 +0100
Size 7,810,410 bytes (7.448587 MiB)

Magic

File type data

Generic infos

Duration 00:00:31 (30.58 s)
Container matroska
Production date Sun, 23 Feb 2014 13:40:56 +0100
Total tracks 2
Track nr. 1 video (V_MPEG4/ISO/AVC) {und}
Track nr. 2 audio (A_MPEG/L2) {und}
Muxing library libebml v1.3.0 + libmatroska v1.4.1
Writing application mkvmerge v6.7.0 ('Back to the Ground') 32bit built on Jan 8 2014
15:03:17

Relevant data

Resolution 720 x 576
Width multiple of 16
Height multiple of 32
Average DRF 25.366252
Standard deviation 1.742948
Std. dev. weighted mean 0.918135

Video track

Codec ID V_MPEG4/ISO/AVC
Resolution 720 x 576
Display resolution 1047 x 576 (pixels)
Frame aspect ratio 5:4 = 1.25
Pixel aspect ratio 349:240 = 1.454167
Display aspect ratio 349:192 = 1.817708
Framerate 50 fps
Stream size 7,321,338 bytes (6.982172 MiB)
Duration (bs) 00:00:31 (30.58 s)
Bitrate (bs) 1915.327142 kbps
Qf 0.092367

Audio track

Codec ID A_MPEG/L2
Sampling frequency 48000 Hz
Channels 2
Stream size 470,784 bytes
Bitstream type (bs) MPEG-1 Layer II
Frames (bs) 1,226
Duration (bs) 00:00:29 (29.424 s)
Chunk-aligned (bs) Yes
Bitrate (bs) 128 kbps CBR
Sampling frequency (bs) 48000 Hz
Mode (bs) joint stereo
Padding (bs) No
Emphasis (bs) none

Video bitstream

Bitstream type MPEG-4 Part 10
SPS id 0
Profile Main@L3
Num ref frames 3
Aspect ratio 16:11 (16:9 PAL pixel shape)
Chroma format YUV 4:2:0
PPS id 0 (SPS: 0)
Entropy coding type CABAC
Weighted prediction No
Weighted bipred idc No
8x8dct No
Total frames 1,529
Drop/delay frames 0
Corrupt frames 0

P-slices 358 ( 23.414 %) #####
B-slices 1146 ( 74.951 %) ###############
I-slices 25 ( 1.635 %)
SP-slices 0 ( 0.000 %)
SI-slices 0 ( 0.000 %)

DRF analysis

average DRF 25.366252
standard deviation 1.742948
max DRF 32


DRF<16 0 ( 0.000 %)
DRF=16 3 ( 0.196 %)
DRF=17 4 ( 0.262 %)
DRF=18 14 ( 0.916 %)
DRF=19 6 ( 0.392 %)
DRF=20 0 ( 0.000 %)
DRF=21 1 ( 0.065 %)
DRF=22 40 ( 2.616 %) #
DRF=23 126 ( 8.241 %) ##
DRF=24 196 ( 12.819 %) ###
DRF=25 228 ( 14.912 %) ###
DRF=26 554 ( 36.233 %) #######
DRF=27 327 ( 21.387 %) ####
DRF=28 20 ( 1.308 %)
DRF=29 1 ( 0.065 %)
DRF=30 2 ( 0.131 %)
DRF=31 6 ( 0.392 %)
DRF=32 1 ( 0.065 %)
DRF>32 0 ( 0.000 %)

P-slices average DRF 23.455307
P-slices std. deviation 0.97566
P-slices max DRF 28

B-slices average DRF 26.125654
B-slices std. deviation 0.901766
B-slices max DRF 32

I-slices average DRF 17.92
I-slices std. deviation 0.844748
I-slices max DRF 19

Profile compliancy

Selected profile MTK PAL 6000
Resolution Ok
Framerate 50 <> 25
Min buffer fill 71%

This report was created by AVInaptic (16-12-2011) on 23-02-2014 13:42:42

Awatar użytkownika
Krosnoludek
Posty: 3508
Rejestracja: 19 grudnia 2010, o 15:33
Miejscowość: KROSNO
Odbiornik: Philips 65PUS8807
Philips 43PUS8506
Opticum AX Lion NS
Instalacja antenowa: Anteny VHF (6-12) i UHF (21-60) z symetryzatorem + zwr. antenowa AMS ZA-104MS
Nadajnik - obiekt nadawczy: RTCN Rzeszów (Krosno) /Sucha Góra

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: Krosnoludek »

Zadzwońcie sobie jutro do TVP-Technologie i dowiedzcie się czy coś robią, aby usunąć problem występujący na niektórych telewizorach
Paweł Kącki
Ośrodek – TVP Technologie
Tel. 22 5477589
Kom. 605 605 600
http://forum.emitel.pl/viewtopic.php?p=129408#p129408
http://pytanienasniadanie.tvp.pl/103893 ... cyfryzacji
Ostatnio zmieniony 23 lutego 2014, o 14:52 przez Krosnoludek, łącznie zmieniany 3 razy.

Awatar użytkownika
sirdaniel
Posty: 235
Rejestracja: 16 maja 2012, o 08:28
Instalacja antenowa: Siatka + symetryzator

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: sirdaniel »

Stały DRF czyli po prostu kwantyzator nie jest wg mnie przyczyną skakania obrazu. Na pewno wasza analiza pomoże sprawdzić która transmisja jest poddana większej kompresji lub mniejszej. Stały DRF na pewno nie pomaga zaoszczędzić bitów tylko je marnuje. Aczkolwiek, mam nagranie ze studia olimpijskiego z DRF stałym na 28 i naprawdę dobrze wygląda, ale to pewnie dlatego, że jest lekko nieostre (zastosowany filtr wysokich częstotliwości), to pomaga lepiej skompresować materiał. Tak jeszcze poza tym, 25-28 DRF nie jest ostatecznie zły na nasze warunki. Ja mam nagranie dzisiejszych zjazdów TVP2 SD z DRF średnio 39, to jest dopiero kaszana..
Ja jeszce badam drżenie obrazu w innych moich nagraniach, napiszę jak coś znajdę.

adac
Posty: 1866
Rejestracja: 19 czerwca 2011, o 08:22
Nadajnik - obiekt nadawczy: najbliższy maszt GSM

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: adac »

Ja tylko dodam to tematu pokaz slajdów zrobiony z filmu który dostarczył wcześniej @ Bartt, tutaj: http://www.forum.emitel.pl/viewtopic.ph ... start=3040. Przypomnę: to nagranie z ekranu Samsunga C550 zrobione kamerą 30fps. Tak się składa że na próbkach dobrze widać z czego bierze się problem.
Paczka #1 to zrzuty klatka po klatce obrazu z dekodera Samsunga, który zawiera usterki (drżenie), paczka #2 to obraz nagrany z tunera zewnętrznego po hdmi.
Klatki numerowane są po kolei, można użyć podglądu windows i przewijać szybciej albo wolniej, 1 sek filmu.

Linki: http://www67.zippyshare.com/v/37264795/file.html -przechwyt Samsung
http://www43.zippyshare.com/v/54924579/file.html - z dekodera STB.

Na klatkach przechwyconych z Samsunga widać wyraźne zniekształcenia i degenarację obrazu: pojawiają się podwójne sylwetki, zamazane kontury , litery napisu raz są czytelne raz nie. Całość powtarza się sekwencjami po 5-7 klatek o podobnych zniekształceniach i z takich łańcuchów składa się cały obraz. Postprocesoring usiłuje to jakoś wygładzić i poskładać ale efekt drżenia i zamazanego ruchu pozostaje.

Dla odmiany klatki z obrazu STB są czyste i czytelne, nie dopatrzyłem się na nich zniekształceń poza drobnym rozmyciem elementów w ruchu (ręce zawodniczek), całość odtwarza się płynnie.

Przyczyną jak dla mnie jest procesor Samsunga który nie daje rady przetworzyć w locie strumienia z kompresją, okresowo zatyka się ( co 5-7 klatek) i psuje obraz.
Za mała moc obliczeniowa dla takiej kompresji, zbyt wolny, albo jedno i drugie. Procesor tunera STB radzi sobie z tym na bieżąco.

Jeszcze jedno: przejrzałem spore fragmenty materiału (próbki są ok. 20 sek) i nie potwierdzam powtarzanej tu diagnozy, że przyczyną jest błędne składanie ramek, zamieniona kolejność, 3-cia przed drugą itp. Na dynamicznym obrazie (jazda zawodniczek) taki defekt byłby od razu widoczny, a ja oglądając po kolei, klatka po klatce, nic takiego nie zauważyłem.
Dotyczy to przede wszystkim Samsunga, ale pro forma obejrzałem też fragmenty z STB.

jajanusz

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: jajanusz »

sirdaniel pisze:Stały DRF czyli po prostu kwantyzator nie jest wg mnie przyczyną skakania obrazu.

Też mi się również wydaje, owo drżenie obrazu ma jedynie związek z przeplotem (interlacing) a nie podwyższoną kompresją, nie wydaje mi się również że to sprzęt nie wyrabia, (skoro inne modele sprzętu działają normalnie a są złożone z tych samych elementów a różnią się oprogramowaniem), bo efekt byłby taki że obraz by się raczej "zawieszał" tak jak przy odtwarzaniu filmów na bardzo starym komputerze. Zaś podwyższenie stopnia kompresji dało by także inne efekty na ekranie, np. niepoprawne dekodowanie, artefakty jak przy słabym sygnale z anteny lub brak obrazu, tak jak na mojej mancie kiedyś w ramach testów na MUX1, ja już wspominałem że problem może być w tym że niektóre odbiorniki mają "niedorobione" oprogramowanie i nie obsługują niektórych trybów (de)interlacing, już pisałem że na komputerze to testowałem, funkcja interlacing w kodeku ma kilka różnych pod funkcji, które można modyfikować, każdy dekoder czy TV ma różne oprogramowanie, czasem lepiej zbudowane czasem gorzej czyli prościej, na komputerze wyeliminować się to da przy pomocy jednego kliknięcia myszką, komputer to co innego, nawet sam kodek MPEG4 AVC można zmienić na inny, zaś dekodery STB czy telewizory mają oprogramowanie stałe, które czasem wymaga ulepszeń (aktualizacji), zwykłemu użytkownikowi nie daje się możliwości wejścia w zaawansowane opcje dekodera i przestawienie pod opcji deinterlacingu, więc nie pozostaje nic innego jak wydanie aktualizacji przez producentów aby dostosować odbiorniki do sygnału MUX3.

No chyba że im się to nie opłaca. :|


A teraz wypowiadam się do co jakości HD w NTC Po tych poniższych słowach pewnie mnie na forum zlinczują, ale trudno muszę to powiedzieć. :?

Tak czytając i czytając to forum co do jakości MUX3, musiałem sprawdzić na własnej skórze sam czy rzeczywiście jest na co narzekać, wpierw porównywałem sklepowy TV z sygnałem z satelity, TVP1 HD - obraz żyleta, bez zastrzeżeń, obecnie oglądam TVP1 HD w NTC na 32 calach i tyle co mogę powiedzieć to że naprawdę nie ma tragedii, około południa Soczi i bobsleje, spory ruch na ekranie i nie widzę tradycyjnej pikselizacji a właśnie przymglenia, które w sygnale z satelity nie występuje, jak dla mnie takie darmowe HD w pełni wystarcza przeciętnemu odbiorcy. ;)

Podejrzewam także że różne odbiorniki i telewizory różne mają oprogramowania MPEG4 i dlatego tu na forum się spieramy że ktoś widzi lepszy obraz a ktoś gorszy, ja na komputerze gdy wymieniam kodeki przy odbiorze DVB-T to niektóre kodeki dekodują lepiej ale pobierają więcej mocy zaś inne dają gorszy efekt obrazu ale pobierają mało mocy obliczeniowej tak więc uważam że jakość obrazu zależy od odbiornika. :)

adac
Posty: 1866
Rejestracja: 19 czerwca 2011, o 08:22
Nadajnik - obiekt nadawczy: najbliższy maszt GSM

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: adac »

@ jajanusz:
z jakich stałych elementów :?: Przecież już ustaliliśmy że usterka dotyczy części serii zrobionej na chipsecie Trident i kto wie na jakich pamięciach i pozostałych podzespołach. Przejrzyj poprzednie posty żeby nie pisać rzeczy już nieaktualnych.

A dekodowanie w TV z tego co wiem jest sprzętowe i nie załatwi tego żadna wymiana softu

lustracja
Posty: 810
Rejestracja: 11 grudnia 2013, o 08:09

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: lustracja »

adac pisze: Przyczyną jak dla mnie jest procesor Samsunga który nie daje rady przetworzyć w locie strumienia z kompresją, okresowo zatyka się ( co 5-7 klatek) i psuje obraz.
Za mała moc obliczeniowa dla takiej kompresji, zbyt wolny, albo jedno i drugie. Procesor tunera STB radzi sobie z tym na bieżąco.
Zgadzam się z tym.
Jak dla mnie cały problem leży w kompresji. różnice w strumieniu dla mnie to potwierdzaj.
Chipset w tych Samsungach się nie wyrabia. Do wymiany.

Różne kombinacje procesorów i monitorów nie tłumaczą słabego wideo. Testowałem różne odbiorniki i różnych producentów.
Co do jakości Video to określenie tragedia jest słuszne. Przyjęcie optyki nadawców i Sugestia, że darmowe i dla przeciętnego odbiorcy wyjaśniają decyzję nadawcy ale dla odbiorcy to słabe pocieszenie. Dopiero nowe metody nadawania coś z tym zrobią.

kadiemus

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: kadiemus »

adac pisze:Jeszcze jedno: przejrzałem spore fragmenty materiału (próbki są ok. 20 sek) i nie potwierdzam powtarzanej tu diagnozy, że przyczyną jest błędne składanie ramek, zamieniona kolejność, 3-cia przed drugą itp.
Pozwolę się nie zgodzić, zamieszczałem kilka 2 lub 3 strony temu (kiepskie bo kiepskie) ale pokazujące istotę materiały, które dobitnie wskazują, że efekt powstaje poprzez złe składanie/kolejność klatek. Nagrane były prędkością 480 kl/s i 1000 kl/s, a więc są spowolnione ok 34 i ok 17 razy.

http://www34.zippyshare.com/v/25318207/file.html

http://www34.zippyshare.com/v/93585604/file.html

http://www34.zippyshare.com/v/88898597/file.html

http://www54.zippyshare.com/v/57246562/file.html
Ostatnio zmieniony 23 lutego 2014, o 16:56 przez kadiemus, łącznie zmieniany 1 raz.

lustracja
Posty: 810
Rejestracja: 11 grudnia 2013, o 08:09

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: lustracja »

Co do wideo.
Mówiąc wprost zamglenie i rozmazanie video to zamglenie i rozmazanie żaden inny dekoder już tego nie poprawi co wycięto. Plama to plama.
Niektórzy tylko lubią się godzić, żeby nie musieć oceniać.

adac
Posty: 1866
Rejestracja: 19 czerwca 2011, o 08:22
Nadajnik - obiekt nadawczy: najbliższy maszt GSM

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: adac »

@ kadiemus: Ok, nie będę upierał się w ciemno. Proszę żebyś obejrzał zrzuty klatka po klatce które podałem wyżej, żadna klatka nie jest pominięta. Można zrobić sobie mini film przewijając szybko i zobaczyć jak idzie obraz . Na prawie całym materiale (który obejrzałem) nie stwierdziłem że zawodniczki przeskakują do tyłu, ruch jest zawsze w tym samym kierunku.

kadiemus

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: kadiemus »

@adac spoko, wiadomo chodzi o to aby jak najlepiej zdiagnozować problem, ale spróbuj ściągnąć materiały, które podałem (linki) na swojego kompa i przejrzeć. Co o tym myślisz?

próbki nagrane były aparatem fot. fuji z TV Samsung LE40C550 soft T-TDT... czyli TRIDENT

adac
Posty: 1866
Rejestracja: 19 czerwca 2011, o 08:22
Nadajnik - obiekt nadawczy: najbliższy maszt GSM

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: adac »

" soft T-TDT... czyli TRIDENT "

/ edit:
rzeczywiście, postacie które robią pół kroku do przodu a potem do tyłu, bobsleje które poruszają się skokami po torze, to wygląda trochę dziwnie. Nie wiem skąd się to bierze, ale możliwe że obydwa efekty: ten wyżej i Twój występują niezależnie i jest to taki bonus występujący w tym modelu.

Przy okazji: czy robiłeś eksperyment z nagrywaniem w ten sam sposób obrazu z jakiegoś normalnego mux-a, najlepiej 2 ? Warto porównać jak to w tym przypadku wygląda.
Chętnie zobaczyłbym też podobny film jaki zrobiłeś z mux 3, ale metodą @ Bartt/a, czyli z normalną prędkością 30 fps i może trochę wyraźniejszy..

//edit: przypomniałem sobie posty w których zaleca się wyłączenie wszelkich polepszaczy obrazu, a jeżeli były wyłączone to pojedynczo włączać. Jeżeli w ustawieniach TV masz jakąś opcję związaną z deinterlacem to spróbuj zmienić. Odtwarzacze pc-towe mają coś takiego ale nie pamiętam żebym kiedykolwiek tego używał.
Można też: ustawić format obrazu na auto albo sztywne 16:9, zmienić kraj (nie chodzi o emigrację), itp.
Ostatnio zmieniony 23 lutego 2014, o 19:23 przez adac, łącznie zmieniany 1 raz.

xjustinx2

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: xjustinx2 »

Spróbujcie sprawdzić czy problem leży w wideo czy w kontenerze-obróbcie strumień w mkvmerge, odtwórzcie z pendrive i powiedzcie czy problem nadal występuje.

Bartt

Re: Kanały TVP w MUX3 - zagadnienia techniczne

Post autor: Bartt »

@xjustinx2
Zapakowanie w mkv nic nie daje - efekt jest ten sam.

A najśmieszniejsze w tym wszystkim jest to, że bardziej zaawansowany pod względem parametrów kodowania strumień wideo działa na tym tv bez problemu.
Jest to próbka materiału, do której ktoś z kolegów dał tu link na forum, w czasie testów w Warszawie (plik Test_TV2 HD20140117-18_56_10.zip).

Poniżej podaję analizę tego pliku ts który przerobiłem na mkv. Jak widać są tam włączone dodatkowe parametry (obecnie nie stosowane), takie jak "Weighted prediction", oraz wyższy jest profil wideo - High@L4. Zmienny jest też parametr DRF.
Name Test_TV2 HD20140117-18_56_10.mkv
Date Sun, 23 Feb 2014 19:54:43 +0100
Size 3,759,901 bytes (3.585721 MiB)

Magic

File type data

Generic infos

Duration 00:00:08 (8.085 s)
Container matroska
Production date Sun, 23 Feb 2014 19:54:43 +0100
Total tracks 2
Track nr. 1 video (V_MPEG4/ISO/AVC) {und}
Track nr. 2 audio (A_MPEG/L2) {pol}
Muxing library libebml v1.3.0 + libmatroska v1.4.1
Writing application mkvmerge v6.7.0 ('Back to the Ground') 32bit built on Jan 8 2014
15:03:17

Relevant data

Resolution 1920 x 1080
Width multiple of 32
Height multiple of 8
Average DRF 37.28655
Standard deviation 2.350761
Std. dev. weighted mean 1.33618

Video track

Codec ID V_MPEG4/ISO/AVC
Resolution 1920 x 1080
Frame aspect ratio 16:9 = 1.777778
Pixel aspect ratio 1:1 = 1
Display aspect ratio 16:9 = 1.777778
Framerate 25 fps
Stream size 3,615,899 bytes (3.44839 MiB)
Duration (bs) 00:00:07 (6.84 s)
Bitrate (bs) 4229.121637 kbps
Qf 0.08158
Resolution (bs) 1920 x 1084

Audio track

Codec ID A_MPEG/L2
Sampling frequency 48000 Hz
Channels 2
Stream size 136,800 bytes
Bitstream type (bs) MPEG-1 Layer II
Frames (bs) 285
Duration (bs) 00:00:07 (6.84 s)
Chunk-aligned (bs) Yes
Bitrate (bs) 160 kbps CBR
Sampling frequency (bs) 48000 Hz
Mode (bs) stereo
Padding (bs) No
Emphasis (bs) none

Video bitstream

Bitstream type MPEG-4 Part 10
SPS id 0
Profile High@L4
Num ref frames 4
Aspect ratio Square pixels
Chroma format YUV 4:2:0
PPS id 0 (SPS: 0)
Entropy coding type CABAC
Weighted prediction P slices - explicit weighted prediction
Weighted bipred idc No
8x8dct Yes
PPS id 1 (SPS: 0)
Entropy coding type CABAC
Weighted prediction P slices - explicit weighted prediction
Weighted bipred idc No
8x8dct Yes
PPS id 2 (SPS: 0)
Entropy coding type CABAC
Weighted prediction P slices - explicit weighted prediction
Weighted bipred idc No
8x8dct Yes
Total frames 171
Drop/delay frames 0
Corrupt frames 0

P-slices 25 ( 14.620 %) ###
B-slices 140 ( 81.871 %) ################
I-slices 6 ( 3.509 %) #
SP-slices 0 ( 0.000 %)
SI-slices 0 ( 0.000 %)

DRF analysis

average DRF 37.28655
standard deviation 2.350761
max DRF 41

DRF<28 0 ( 0.000 %)
DRF=28 1 ( 0.585 %)
DRF=29 2 ( 1.170 %)
DRF=30 2 ( 1.170 %)
DRF=31 1 ( 0.585 %)
DRF=32 0 ( 0.000 %)
DRF=33 5 ( 2.924 %) #
DRF=34 8 ( 4.678 %) #
DRF=35 10 ( 5.848 %) #
DRF=36 18 ( 10.526 %) ##
DRF=37 30 ( 17.544 %) ####
DRF=38 41 ( 23.977 %) #####
DRF=39 28 ( 16.374 %) ###
DRF>39 25 ( 14.620 %) ###


P-slices average DRF 34.6
P-slices std. deviation 1.095445
P-slices max DRF 36

B-slices average DRF 38.1
B-slices std. deviation 1.395401
B-slices max DRF 41

I-slices average DRF 29.5
I-slices std. deviation 0.957427
I-slices max DRF 31

Profile compliancy

Selected profile MTK PAL 6000
Resolution 1920 x 1080 > 720 x 576
Framerate Ok
Min buffer fill 69%

This report was created by AVInaptic (16-12-2011) on 23-02-2014 19:55:41
Tak więc argument o przeciążeniu procka nie ma sensu, bo jak widać powyżej, bardziej skomplikowany pod względem kodowania materiał wideo działa bez problemu.
Ostatnio zmieniony 23 lutego 2014, o 20:17 przez Bartt, łącznie zmieniany 2 razy.

Zablokowany