[TOC]

# Testy PRET

Wszystkie materiały 1920x1080 @ 24fps

## Parametry

* `-bt` – CONVERT_BITRATE_TOLERANCE – tolerancja odchylenia od ustawionego bitrate
* `-b:v` – DEFAULT_BITRATE – bitrate video
* `-preset` – CONVERT_PRESET – preset, dotyczy głównie h264 i 265
* `-vcodec` – CONVERT_VCODEC – kodek video
* `-bufsize` – CONVERT_BUFSIZE – rozmiar bufora do estymacji bitrate
* `?cbr` – CONVERT_CONSTANT_BITRATE – minrate = maxrate = bitrate w ffmpeg

## Pliki

- mcslogo
- hyundai
- s20
- s10
- woda
- tapeta

### Pobieranie z KONW

http://31.186.83.4:8096/media/`nazwa ustawień konw`_`nazwa pliku`.ts

http://31.186.83.4:8096/media/K_hevc_1_woda.ts

## Protokoły

### UDP

Dwie pierwsze tury testów były przeprowadzone na protokole `udp`.

FFMPEG nadaje `-f mpegts udp://239.255.12.42:5001`,
ffplay odbiera `udp://239.255.12.42:5001`.

### SAP (RTP)

Począwszy of trzciej tury testów protokołem jest `sap` (strumieniowanie `rtp`).

Do `RTP` potrzeba dodatkowego portokołu `RTCP`, który standardowo jest na porcie
o jeden wyższym. Nie udało się zmusić ffmpega do pracy na jednym porcie, czyli
w trybie `rtcp-mux`. Dodatkowo `RTP` trzeba rozgłosić zapomocą `SDP`, np. w postaci
pliku (nieakceptowalne) albo protokołem `SAP` (użyte).

Reasumując w tej chwili aż trzy porty dotyczą jednego strumienia (dla przykładu kanał 1):
- 239.255.12.42:5010 (RTC)
- 239.255.12.42:5011 (RTPC)
- 224.2.127.254:5001 (SAP), *adres domyślny*

**TODO:** napisać więcej o RTP.

FFMPEG nadaje `-f sap 'sap://239.255.12.42:5010?announce_port=5001'`,
ffplay odbiera `sap://:5001`.

# Pierwsza tura testów

## KONW (konfiguracje konwertera)

| Nazwa | -bt | -b:v | -preset | -vcodec | -bufsize | ?cbr |
| -------- | ----- | ----- | --------- | ------- | -------- | ---- |
| K_h264_1 | 500k | 4M | veryslow | h264 | 500k | 1 |
| K_h264_2 | 500k | 1M | slow | h264 | 500k | 0 |
| K_h264_3 | 500k | 2M | slow | h264 | 500k | 0 |
| K_hevc_1 | 500k | 4M | veryslow | hevc | 500k | 0 |
| K_hevc_2 | 500k | 1M | veryslow | hevc | 500k | 0 |

## PRET – Streamer (ffmpeg)

| Nazwa | net | -pkt_size | -formatprobesize | -probesize | codec |
| -------- | ----- | ----- | ----- | ----- | ----- |
| S_1 | multicast | 1316 | 3k | 5k | copy |
| S_2 | multicast | 1888 | 3k | 5k | copy |
| S_3 | multicast | 1316 | 3k | 5k | hevc, h264 |

Od trzeciego testu wysyłane dwa kanały (czyli 2x większy ruch sieciowy).

**UWAGA** Każdy `ffplay` zajmuje ~190% procesora (w tym podgląd)!

### S_1

`ffmpeg -hide_banner -re -f mpegts -threads 1 -formatprobesize 3k -probesize 5k -i pipe:0 -c copy -fflags +igndts+genpts -f mpegts -tune zerolatency -pkt_size 1316 -f mpegts udp://239.255.12.42:5001 -progress unix:///tmp/tmpvyl8_tso/progress.sock`

### S_2

Zmniana `pkt_size` nie wniosła żadnej zmainy w żadnym teście.

`ffmpeg -hide_banner -re -f mpegts -threads 1 -formatprobesize 3k -probesize 5k -nostats -i pipe:0 -c copy -fflags +igndts+genpts -f mpegts -tune zerolatency -pkt_size 1880 -f mpegts udp://239.255.12.42:5001 -progress unix:///tmp/tmpn7ay180o/progress.sock`

### S_3

Rekodowanie w locie (ultrafast).

Dla h265 (hevc):
`ffmpeg -hide_banner -re -f mpegts -threads 1 -formatprobesize 3k -probesize 5k -nostats -i pipe:0 -vcodec hevc -preset ultrafast -an -fflags +igndts+genpts -f mpegts -tune zerolatency -pkt_size 1316 -f mpegts udp://239.255.12.42:5001 -progress unix:///tmp/tmp2qfis2e6/progress.sock`

Dla h264:
`ffmpeg -hide_banner -re -f mpegts -threads 1 -formatprobesize 3k -probesize 5k -nostats -i pipe:0 -vcodec libx264 -preset ultrafast -an -fflags +igndts+gepnts -f mpegts -tune zerolatency -pkt_size 1316 -f mpegts udp://239.255.12.42:5001 -progress unix:///tmp/tmp2qfis2e6/progress.sock`

Efekt poniżej krytyki.

## PRET – Player (ffplay)

Odtwarzacz jest wołany (kanał pierwszy, drugi analogicznie):
`/usr/bin/ffplay -window_title 'Channel 1' -fflags nobuffer -noinfbuf -fs udp://@239.255.12.42:5001`

### Monitory

1. `Intel(R) Celeron(R) CPU J1900 @ 1.99GHz`
2. `AMD E-350D APU with Radeon(tm) HD Graphics`

Monitor 2 na początku zawierał odtwarzacz opartą o VLC (przez pierwsze dwa testy) `multimedia-display_1.0.1_i386.deb`.

## Obserwacje

Przyjmujemy skalę 10 punktową (1 - nagorzej, 10 - idealnie)

### K_h264_1 + S_1

* Dla reklam dynamicznych sypiące się piksele. ocena - 5 pkt. (jako baza to kolejnych testów)
* reklama statyczna wygląda prawidłowo.
* monitor 2 - VLC, nie brany pod uwagę do wyników

### K_hevc_1 + S_1

* znaczne pogorszenie jakości materiałów wideo, duża ilość artefaktów ocena - 2 pkt.
* monitor 2 - VLC, nie brany pod uwagę do wyników

### K_hevc_2 + S_1

* bardzo dobra jakość materiału, brak błedów w odtwarzaniu na monitorze 1, ocena - 10 pkt.
* monitor 2, nie dawał sobie rady i materiał się zacinał. ocena - 2 pkt.

### K_h264_2 + S_1 (aktualnie ustawione w KONW)

* pogorszenie jakości odtwarzanych materiałów (widoczne piksele) materiał odtwarza się płynnie na obu monitorach ocena - 6 pkt.

### K_h264_3 + S_1

* poprawa jakości w stosunku do poprzedniego testu (mniej pikseli), jednak pojawiły się artefakty ocena - 3 pkt.

# Druga tura testów

Testy zostały przprowadzone dla różnych nastaw, przy czym, nie wszystkie kombinacje zostały sprawdzone. FPS 24.

1. Przepływności:
- 300k (*testowane w drugiej części*)
- 400k (*testowane w drugiej części*)
- 500k
- 600k (*testowane w drugiej części*)
- 700k (*testowane w drugiej części*)
- 800k
- 1M
- 2M
- 4M

2. Rozmiarów:
- 1920x1080 (Full HD)
- 1280x720 (HD Ready)
- 854x480 (WVGA)

3. Kodeków:
- H.264
- HEVC (H.265)

W repozytorium PRET-a jest skrypt `./scripts/pret-testing.sh` ułatwiający poniższe testy (pobiera pliki, zmienia ustawienia, pozwala restartować PRET-a i ffplay).

## Obserwacje

1. (hevc,1280x720,1M)

- bardzo dobra jakość obrazu, obraz odtwarzany płynnie, bez zacięć, podczas jednego z przebiegów playlisty przez krótką chwilę dla pliku woda widoczne artefakty – kanał 1, kanał 2 (sytuacja powtarza się bardzo nieregularnie)
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 534536 94280 904520 0 0 0 0 864 1363 19 2 79 0 0 (20%)
• 3 0 0 925736 72904 586056 0 0 0 0 1346 1715 55 2 43 0 0 (57%)

2. (hevc,1280x720,2M)

- jakość obrazu bardzo dobra, obraz odtwarzany płynnie, bez zacięć, często zdarzają się artefakty na obu monitorach.
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 534576 94280 904928 0 0 0 0 1010 1458 21 3 75 0 0 (25%)
• 1 0 0 923284 73136 587000 0 0 0 0 1673 1872 95 3 2 0 0 (98%)

3. (hevc,1280x720,4M)

- jakość obrazu bardzo dobra, kanał 1 obraz odtwarzany płynnie, na kanale 2 zacięcia odtwarzanego materiału (hyundai), bardzo częste artefakty na obu urządzeniach
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 530948 94300 905772 0 0 0 0 1444 1667 33 5 62 0 0 (38%)
• 4 0 0 905736 73552 588652 0 0 0 0 1867 2059 96 4 0 0 0 (100%)

4. (hevc,1280x720,800k)

- bardzo dobra jakość obrazu, obraz odtwarzany płynnie, bez zacięć, bez artefaktów
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 533104 94316 906348 0 0 0 0 882 1224 15 3 82 0 0 (18%)
• 0 0 0 918688 73680 589384 0 0 0 0 1228 1694 46 4 50 0 0 (50%)

5. (hevc,1280x720,500k)

- dobra jakość obrazu, obraz odtwarzany płynnie, bez zacięć, bez artefaktów
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 2 0 0 532076 94364 907412 0 0 0 0 811 1245 15 3 82 0 0 (18%)
• 2 0 0 916292 74280 592328 0 0 0 0 1014 1614 44 3 53 0 0 (47%)

6. (hevc,1920x1080,500k)

- bardzo dobra jakość obrazu, obraz odtwarzany płynnie na kanale 1, kanał 2 zacina się, bez artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 3 0 0 488452 94376 909240 0 0 0 0 1068 1203 36 4 60 0 0 (40%)
• 3 0 0 882088 74728 594292 0 0 0 0 992 1405 98 2 0 0 0 (100%)

7. (hevc,1920x1080,800k)

- bardzo dobra jakość obrazu, obraz odtwarzany płynnie na kanale 1, kanał 2 zacina się notorycznie, sporadyczne artefakty kanał 1 (jednorazowy przypadek przy n przebiegu)
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 2 0 0 490992 94420 909532 0 0 0 0 858 1279 23 3 73 0 0 (27%)
• 3 0 0 868456 75292 596712 0 0 0 0 1092 1323 99 1 0 0 0 (100%)

8. (hevc,1920x1080,1M)

- bardzo dobra jakość obrazu, obraz odtwarzany płynnie na kanale 1, kanał 2 zacina się notorycznie, brak artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 493964 94460 909572 0 0 0 0 1013 1273 31 4 65 0 0 (35%)
• 2 0 0 866304 75456 597848 0 0 0 0 1181 1339 99 1 0 0 0 (100%)

9. (hevc,854x480,1M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, brak artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 545432 94468 906936 0 0 0 0 814 1315 13 2 85 0 0 (15%)
• 1 0 0 908012 75584 598408 0 0 0 0 1195 1563 43 3 54 0 0 (45%)

10. (hevc,854x480,2M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, brak artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 0 0 0 540464 94476 907004 0 0 0 404 946 1579 13 2 85 0 0 (15%)
• 0 0 0 922268 75844 599548 0 0 0 0 1579 1845 36 3 61 0 0 (39%)

11. (hevc,854x480,4M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, duża liczba artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 0 0 0 541532 94476 907060 0 0 0 0 589 1243 7 2 92 0 0 (8%)
• 1 0 0 919488 75900 599900 0 0 0 0 1181 1622 22 4 74 0 0 (26%)

12. (h264,854x480,4M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, duża liczba artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 0 0 0 544404 94476 907224 0 0 0 0 750 1364 6 2 92 0 0 (8%)
• 0 0 0 923476 75972 600404 0 0 0 36 1451 1955 18 3 80 0 0 (20%)

13. (h264,854x480,2M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, brak artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 549288 94500 907544 0 0 0 0 547 1260 4 1 95 0 0 (5%)
• 1 0 0 921928 76080 600952 0 0 0 0 1878 2150 21 4 76 0 0 (24%)

14. (h264,854x480,1M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, brak artefaktów

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 548684 94512 907620 0 0 0 80 751 1376 6 2 92 0 0 (8%)
• 0 0 0 921124 76272 601868 0 0 0 0 1231 1823 14 5 82 0 0 (18%)

15. (h264,854x480,800k)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, brak artefaktów
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 0 0 0 546612 94532 907708 0 0 0 0 582 1309 4 1 95 0 0 (5%)
• 1 0 0 919204 76620 603484 0 0 0 0 1161 1658 13 3 84 0 0 (16%)

16. (h264,1280x720,800k)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, brak artefaktów, w nielicznych, dynamicznych scenach widoczne piksele

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 0 0 0 536160 94536 908724 0 0 0 0 798 1353 10 2 87 0 0 (13%)
• 2 0 0 905428 76684 603812 0 0 0 0 1211 1775 24 4 73 0 0 (27%)

17. (h264,1280x720,1M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, brak artefaktów, w nielicznych, dynamicznych scenach widoczne piksele

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 539880 94540 908792 0 0 0 0 803 1298 10 2 88 0 0 (12%)
• 2 0 0 904208 76812 604384 0 0 0 0 1286 1795 27 3 70 0 0 (30%)

18. (h264,1280x720,2M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, na obu monitorach zdarzają się artefakty, w nielicznych, dynamicznych scenach widoczne piksele
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 527132 94540 908780 0 0 0 0 922 1462 10 2 87 0 0 (13%)
• 0 0 0 899580 76900 604828 0 0 0 0 1655 1913 29 3 69 0 0 (31%)

19. (h264,1920x1080,2M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, po kilku przebiegach na obu monitorach zdarzają się artefakty,
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 2 0 0 501272 94544 902388 0 0 0 52 1009 1412 16 3 81 0 0 (19%)
• 0 0 0 871964 76988 605480 0 0 0 56 1401 1636 51 2 47 0 0 (53%)

20. (h264,1920x1080,1M)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, na obu monitorach zdarzają się artefakty, w dynamicznych scenach widoczne piksele

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 502744 94552 910732 0 0 0 76 948 1361 16 4 80 0 0 (20%)
• 1 0 0 874604 77220 606544 0 0 0 0 1266 1613 47 2 51 0 0 (49%)

21. (h264,1920x1080,800k)

- dobra jakość obrazu, obraz odtwarzany płynnie, brak zacięć, na obu monitorach zdarzają się artefakty, w dynamicznych scenach widoczne piksele

Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 1 0 0 500032 94552 910888 0 0 0 44 945 1453 17 3 80 0 0 (20%)
• 2 0 0 865300 77296 607016 0 0 0 0 1198 1730 40 2 59 0 0 (60%)

22. (h264,1920x1080,500k)

- słaba jakość obrazu, wszechobecna pikseloza
Obciążenie monitorów:

r b swpd free buff cache si so bi bo in cs us sy id wa st
• 0 0 0 507488 94552 911000 0 0 0 0 847 1333 15 3 82 0 0 (18%)
• 0 0 0 879936 77376 607240 0 0 0 0 1214 1744 38 3 59 0 0 (41%)

### Podsumowanie

Wychodzi z badań, że konwerter powinien być ustawiony na `hevc`, `1280x720`, 800k.
Po dodatkowych testach przeprływnaiość została obnizona do `600k`.
Na takie parametry został ustawieny konwerter.

Niemniej po kilku, kilkunastu godzinach zaczęły pojawiać się artefakty,
szczególnie na statycznych planszach.

# Trzecia tura testów

W tym miejscu został zmieniony protoków z `udp` na `sap`, czyli `RTP` rozgłaszany przez `SAP`.

Testy polegały na podmianie statycznych obrazów bez restartu PRET-a.


Obraz z konwertera miał następujący układ ramek. Ramka `I` o wielkości 43790.

IBBBBpBBBBpBBBBpBBBpBBBBpBpppBBpppBBpBBBBppBBpBB
BBpBBBBpBBBBpBpBBBBppBBpppBBpppBBpBBBBpBpBBBBpBB
BBpBBBBppBBpBBBBpBpBBBBp

Wymuszenie wiezkszej liczby kluczowych ramek `I` (`-g 48`, czyli co 2 s)
spowododowało, że pierwsza 2s planszy było OK, ale potem były artefakty.
Ramki `I` o wielkościach 43865, 56552, 56485.

IBBBBpBBBBpBBBBpBBBpBBBBpBpppBBpppBBpBBBBppBBpBB
IBBBBpBBBBppBBpBBBBpBBBBpBpppBBpBBBBppBBpppBBpBB
IBBBBppBBpBBBBpBBBBpBBBp

Na koniec obraz został w ogóle pozbawiony ramek dwukierunkowych `B` (`-bf 0`).
Przez chwilę wydawało się, że jest lepiej, ale artefakty wróciły.
Ramka `I` o wielkości 43399.

Ippppppppppppppppppppppppppppppppppppppppppppppp
pppppppppppppppppppppppppppppppppppppppppppppppp
pppppppppppppppppppppppp

Układ ramek można uzyskać za pomocą:

ffprobe -hide_banner -show_frames FILE.ts > /tmp/ffprobe.log 2>&1
echo $(sed -nE '/^pict_type/ {s/.*=//; p; }' /tmp/ffprobe.log) \
  | sed -e 's/ //g' -e 's/P/p/g'

# Czwarta tura testów

Na koniec zostały uruchomione różne testy nie wymagające zaangażowania.

### PRET ze statyczną planszą (2 kanały)

Dość szybko zaczęły się artefakty (po niecałych 10 min).

### FFMPEG ze statyczną planszą (2 kanały)

Jak wyżej, ale bez PRET-a. Polecenie uruchomione z ręki:

while :; do
  cat ../media/e03cf015\:wrzeisen-2020-tapeta-panorama-auto_0002255.ts
done | ffmpeg -hide_banner -re -f mpegts -threads 1 -formatprobesize 3k \
  -probesize 5k -nostats -i pipe:0 -c copy -fflags +genpts -tune zerolatency \
  -pkt_size 1316 -f sap 'sap://239.255.12.42:5010?announce_port=5001'

Analogicznie na drugim kanale.

Testy własnie trwają, od 7 godzin nie ma artefaktów.

...

# Różności

Narzędzie do tabeli w ViM: https://github.com/dhruvasagar/vim-table-mode