Отсутствие информации о видео при публикации

L

LmSys

New Member
Мне нужна информация о видео потоке при публицаии потока (валидация качества), но иногда выходит такая ситуация что при информировании о публикации отсутствуют данные о видео потоке. На какой ивент можно полагаться, если такой метод дает сбой.

Code: 
URL:http://someservice.com:2912/v1/flashphoner/StreamStatusEvent 
OBJECT: {  
  "nodeId" : "irO1BptHCon3uTTyNRDkqXBVuqvkktzU@5.5.5.6",  
  "appKey" : "someApp",  
  "sessionId" : "/5.5.5.5:64042/5.5.5.6:8443-59b0bb66-a893-4005-a326-65411db378ad",  
  "mediaSessionId" : "da446ec0-11db-11eb-858a-71fcd2e936c2",  
  "name" : "4268e7302097c0bb3cdd3ec37139be01",  
  "published" : true,  
  "hasVideo" : true,  
  "hasAudio" : true,  
  "status" : "PUBLISHING",  
  "sdp" : "v=0\r\no=- 8587999016537288712 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0 1\r\na=msid-semantic: WMS qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:hYnT\r\na=ice-pwd:eV1ESx/VibDfNDb2JxDKrnG8\r\na=ice-options:trickle\r\na=fingerprint:sha-256 92:46:66:97:9B:1E:1E:CE:36:C7:6C:2B:88:91:31:2D:9A:BF:BB:04:06:20:CA:95:7A:23:D0:43:92:F2:9E:19\r\na=setup:actpass\r\na=mid:0\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=sendonly\r\na=msid:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj 4add3776-d063-4b1c-ad73-80b9415df215\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=rtcp-fb:111 transport-cc\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:110 telephone-event/48000\r\na=rtpmap:112 telephone-event/32000\r\na=rtpmap:113 telephone-event/16000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:300010847 cname:NKxdNxrh6exs8hZH\r\na=ssrc:300010847 msid:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj 4add3776-d063-4b1c-ad73-80b9415df215\r\na=ssrc:300010847 mslabel:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj\r\na=ssrc:300010847 label:4add3776-d063-4b1c-ad73-80b9415df215\r\nm=video 9 UDP/TLS/RTP/SAVPF 97 99 101 102 121 127 120 125 107 108 109 124 119 123 118 114 115 116\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:hYnT\r\na=ice-pwd:eV1ESx/VibDfNDb2JxDKrnG8\r\na=ice-options:trickle\r\na=fingerprint:sha-256 92:46:66:97:9B:1E:1E:CE:36:C7:6C:2B:88:91:31:2D:9A:BF:BB:04:06:20:CA:95:7A:23:D0:43:92:F2:9E:19\r\na=setup:actpass\r\na=mid:1\r\na=extmap:14 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:13 urn:3gpp:video-orientation\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type\r\na=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing\r\na=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=sendonly\r\na=msid:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj 42140dbd-37c0-40e9-923f-c728ecb8a1e0\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:97 rtx/90000\r\na=fmtp:97 apt=96\r\na=rtpmap:99 rtx/90000\r\na=fmtp:99 apt=98\r\na=rtpmap:101 rtx/90000\r\na=fmtp:101 apt=100\r\na=rtpmap:102 H264/90000\r\na=rtcp-fb:102 goog-remb\r\na=rtcp-fb:102 transport-cc\r\na=rtcp-fb:102 ccm fir\r\na=rtcp-fb:102 nack\r\na=rtcp-fb:102 nack pli\r\na=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f\r\na=rtpmap:121 rtx/90000\r\na=fmtp:121 apt=102\r\na=rtpmap:127 H264/90000\r\na=rtcp-fb:127 goog-remb\r\na=rtcp-fb:127 transport-cc\r\na=rtcp-fb:127 ccm fir\r\na=rtcp-fb:127 nack\r\na=rtcp-fb:127 nack pli\r\na=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f\r\na=rtpmap:120 rtx/90000\r\na=fmtp:120 apt=127\r\na=rtpmap:125 H264/90000\r\na=rtcp-fb:125 goog-remb\r\na=rtcp-fb:125 transport-cc\r\na=rtcp-fb:125 ccm fir\r\na=rtcp-fb:125 nack\r\na=rtcp-fb:125 nack pli\r\na=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\na=rtpmap:107 rtx/90000\r\na=fmtp:107 apt=125\r\na=rtpmap:108 H264/90000\r\na=rtcp-fb:108 goog-remb\r\na=rtcp-fb:108 transport-cc\r\na=rtcp-fb:108 ccm fir\r\na=rtcp-fb:108 nack\r\na=rtcp-fb:108 nack pli\r\na=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f\r\na=rtpmap:109 rtx/90000\r\na=fmtp:109 apt=108\r\na=rtpmap:124 H264/90000\r\na=rtcp-fb:124 goog-remb\r\na=rtcp-fb:124 transport-cc\r\na=rtcp-fb:124 ccm fir\r\na=rtcp-fb:124 nack\r\na=rtcp-fb:124 nack pli\r\na=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f\r\na=rtpmap:119 rtx/90000\r\na=fmtp:119 apt=124\r\na=rtpmap:123 H264/90000\r\na=rtcp-fb:123 goog-remb\r\na=rtcp-fb:123 transport-cc\r\na=rtcp-fb:123 ccm fir\r\na=rtcp-fb:123 nack\r\na=rtcp-fb:123 nack pli\r\na=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f\r\na=rtpmap:118 rtx/90000\r\na=fmtp:118 apt=123\r\na=rtpmap:114 red/90000\r\na=rtpmap:115 rtx/90000\r\na=fmtp:115 apt=114\r\na=rtpmap:116 ulpfec/90000\r\na=ssrc-group:FID 1805593137 3657059575\r\na=ssrc:1805593137 cname:NKxdNxrh6exs8hZH\r\na=ssrc:1805593137 msid:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj 42140dbd-37c0-40e9-923f-c728ecb8a1e0\r\na=ssrc:1805593137 mslabel:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj\r\na=ssrc:1805593137 label:42140dbd-37c0-40e9-923f-c728ecb8a1e0\r\na=ssrc:3657059575 cname:NKxdNxrh6exs8hZH\r\na=ssrc:3657059575 msid:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj 42140dbd-37c0-40e9-923f-c728ecb8a1e0\r\na=ssrc:3657059575 mslabel:qbDqE9ta6t8Q8trFh0FCbpmRSEJzGwH1maFj\r\na=ssrc:3657059575 label:42140dbd-37c0-40e9-923f-c728ecb8a1e0\r\n",  
  "audioCodec" : "opus",  
  "videoCodec" : "H264",  
  "record" : false,  
  "width" : 0, 
  "height" : 0,  
  "bitrate" : 0,  
  "minBitrate" : 0,  
  "maxBitrate" : 0,  
  "quality" : 0,  
  "history" : false,  
  "gop" : 0,  
  "fps" : 0,  
  "audioBitrate" : 0,  
  "codecImpl" : "",  
  "transport" : "UDP",  
  "cvoExtension" : false,  
  "createDate" : 1603092153275,  
  "mediaProvider" : "WebRTC",    
  "origin" : "https://someorigin.com",  
  "constraints" : {    
    "audio" : {      
      "deviceId" : "default"    
    },    
    "video" : {      
      "deviceId" : "abeba38c43d7734de78eb56a935e41e3696fefee4f2d8f288999d8a1bdfe0d14"    
    }  
  } 
}
 
Max

Max

Administrator
Staff member
Используя событие StreamStatusEvent вы можете получить значение mediaSessionId.
Затем, используя значение mediaSessionId, можно отправить REST запрос rest-api/stream/metrics к вашему WCS серверу и получить интересующие вас параметры потока.
Пример REST запроса:
Code: 
http://demo.flashphoner.com:8081/rest-api/stream/metrics 

{   
    "mediaSessionId" : "72b76eb8-3c01-47f3-b308-a0516d51249b"
}
Пример ответа:
Code: 
{
    "VIDEO_SYNC": 3811814378436,
    "VIDEO_K_FRAMES": 54,
    "AUDIO_SYNC": 3811814378492,
    "VIDEO_NACK": 0,
    "AUDIO_RATE": 30104,
    "AUDIO_LOST": 0,
    "VIDEO_LOST": 0,
    "VIDEO_CODEC": 119,
    "VIDEO_B_FRAMES": 0,
    "VIDEO_PLI": 0,
    "AUDIO_CODEC": 111,
    "VIDEO_RATE": 18384,
    "VIDEO_WIDTH": 320,
    "VIDEO_HEIGHT": 240,
    "VIDEO_FPS": 15,
    "VIDEO_P_FRAMES": 3933
}
Подробнее здесь: https://docs.flashphoner.com/pages/viewpage.action?pageId=14254140
 
L

LmSys

New Member
И еще одна похожая проблема в том что при этом ивенте может отсутствовать информация про кодек видео. Эту проблему также необходимо решать через stream/metrics?

Code: 
{
    "nodeId": "irO1BptHCon3uTTyNRDkqXBVuqvkktzU@*****",
    "appKey": "some-app-key",
    "sessionId": "/*********:33896/5.5.5.5:8443-ec1dd1be-971d-4f81-842c-c8a505a03311",
    "mediaSessionId": "833ddb30-0d61-11eb-a389-c5d607c18e79",
    "name": "ca81bbaa7073a2bc32a2ae5f2c75d869",
    "published": true,
    "hasVideo": true,
    "hasAudio": true,
    "status": "PUBLISHING",
    "sdp": "***",
    "audioCodec": "opus",
    "record": false,
    "width": 0,
    "height": 0,
    "bitrate": 0,
    "minBitrate": 0,
    "maxBitrate": 0,
    "quality": 0,
    "history": false,
    "gop": 0,
    "fps": 0,
    "audioBitrate": 0,
    "codecImpl": "",
    "transport": "UDP",
    "cvoExtension": false,
    "createDate": 1602599806379,
    "mediaProvider": "WebRTC",
    "custom": {
        ***
    },
    "origin": "****",
    "constraints": {
        "audio": {"deviceId": "default"},
        "video": {"deviceId": "b02756018cf4c2ca3414dfc25af37462c42f7bd1da03cf1e3fe8662a5b0fc142"}
    }
}
 
Max

Max

Administrator
Staff member
LmSys said:
И еще одна похожая проблема в том что при этом ивенте может отсутствовать информация про кодек видео. Эту проблему также необходимо решать через stream/metrics?
Click to expand...
Да, в примере выше приведена информация о видеокодеке:
Code: 
{
    ...
    "VIDEO_CODEC": 119,
    ...
    "AUDIO_CODEC": 111,
    ...
}
Как правило, значение 119 соответствует кодеку H264
 
Olehus

Olehus

New Member
А почему может возникать такая ситуация, что в одних запросах со "status": "PUBLISHING" есть поле videoCodec, а в некоторых оно отсутствует?
 
Max

Max

Administrator
Staff member
Это связано с тем, что /StreamStatusEvent отсылается в самом начале публикации, когда медиаданных еще могло не быть. В общем случае при публикации сервер не знает, что за кодек ему придет, пока не разберет первый пакет с медиаданными.
Поэтому метрики надежнее, поскольку они собираются для каждого потока при анализе полученного пакета.
 
Olehus

Olehus

New Member
@Max

Еще один вопрос из той же темы.
Используем rest-api/stream/metrics для получения метрик при подключении стрима. Иногда у некоторых стримеров данные о ширине и высоте кадра отсутствую на протяжении 10 сек (дальше мы просто отключаем стрим от сервера). Пример:
[2021-07-07T10:36:01.201Z][DEBUG] '{"VIDEO_SYNC":1625654161622,"VIDEO_K_FRAMES":3,"AUDIO_SYNC":1625654161628,"VIDEO_NACK":0,"AUDIO_RATE":13776,"AUDIO_LOST":0,"VIDEO_LOST":0,"VIDEO_CODEC":119,"VIDEO_B_FRAMES":0,"VIDEO_PLI":0,"AUDIO_CODEC":111,"VIDEO_RATE":1921392,"VIDEO_WIDTH":0,"VIDEO_HEIGHT":0,"VIDEO_FPS":31,"VIDEO_P_FRAMES":238}'

[2021-07-07T10:36:00.199Z][DEBUG] '{"VIDEO_SYNC":1625654160589,"VIDEO_K_FRAMES":3,"AUDIO_SYNC":1625654160588,"VIDEO_NACK":0,"AUDIO_RATE":13088,"AUDIO_LOST":0,"VIDEO_LOST":0,"VIDEO_CODEC":119,"VIDEO_B_FRAMES":0,"VIDEO_PLI":0,"AUDIO_CODEC":111,"VIDEO_RATE":1742328,"VIDEO_WIDTH":0,"VIDEO_HEIGHT":0,"VIDEO_FPS":29,"VIDEO_P_FRAMES":207}'

[2021-07-07T10:35:59.197Z][DEBUG] '{"VIDEO_SYNC":1625654159621,"VIDEO_K_FRAMES":3,"AUDIO_SYNC":1625654159608,"VIDEO_NACK":0,"AUDIO_RATE":13424,"AUDIO_LOST":0,"VIDEO_LOST":0,"VIDEO_CODEC":119,"VIDEO_B_FRAMES":0,"VIDEO_PLI":0,"AUDIO_CODEC":111,"VIDEO_RATE":1907904,"VIDEO_WIDTH":0,"VIDEO_HEIGHT":0,"VIDEO_FPS":30,"VIDEO_P_FRAMES":178}'

[2021-07-07T10:35:58.194Z][DEBUG] '{"VIDEO_SYNC":1625654158622,"VIDEO_K_FRAMES":3,"AUDIO_SYNC":1625654158608,"VIDEO_NACK":0,"AUDIO_RATE":13320,"AUDIO_LOST":0,"VIDEO_LOST":0,"VIDEO_CODEC":119,"VIDEO_B_FRAMES":0,"VIDEO_PLI":0,"AUDIO_CODEC":111,"VIDEO_RATE":1959384,"VIDEO_WIDTH":0,"VIDEO_HEIGHT":0,"VIDEO_FPS":30,"VIDEO_P_FRAMES":148}'

***

[2021-07-07T10:35:53.182Z][DEBUG] '{"VIDEO_SYNC":0,"VIDEO_K_FRAMES":0,"AUDIO_SYNC":0,"VIDEO_NACK":0,"AUDIO_RATE":0,"AUDIO_LOST":0,"VIDEO_LOST":0,"VIDEO_CODEC":0,"VIDEO_B_FRAMES":0,"VIDEO_PLI":0,"AUDIO_CODEC":0,"VIDEO_RATE":0,"VIDEO_WIDTH":0,"VIDEO_HEIGHT":0,"VIDEO_FPS":0,"VIDEO_P_FRAMES":0}'
Click to expand...
 
Max

Max

Administrator
Staff member
Olehus said:
Используем rest-api/stream/metrics для получения метрик при подключении стрима. Иногда у некоторых стримеров данные о ширине и высоте кадра отсутствую на протяжении 10 сек (дальше мы просто отключаем стрим от сервера). Пример:
Click to expand...
Если речь о WebRTC публикациях, то похоже, в последнем приведенном Вами примере клиент вообще не высылал видеотрафик:
Code: 
[2021-07-07T10:35:53.182Z][DEBUG] '{"VIDEO_SYNC":0,"VIDEO_K_FRAMES":0,"AUDIO_SYNC":0,"VIDEO_NACK":0,"AUDIO_RATE":0,"AUDIO_LOST":0,"VIDEO_LOST":0,"VIDEO_CODEC":0,"VIDEO_B_FRAMES":0,"VIDEO_PLI":0,"AUDIO_CODEC":0,"VIDEO_RATE":0,"VIDEO_WIDTH":0,"VIDEO_HEIGHT":0,"VIDEO_FPS":0,"VIDEO_P_FRAMES":0}'
и решение о переподключении такого клиента будет правильным
В остальных случаях речь идет о задержке в отправке ключевого фрейма со стороны клиента (информация о ширине и высоте картинки берется из таких фреймов). Такие задержки отмечаются, например, при публикации из MacOS Safari. Рекомендуем следующую настройку:
Code: 
periodic_fir_request=true
periodic_fir_request_interval=2000
В этом случае сервер будет запрашивать у браузера ключевой фрейм каждые две секунды, и проблема должна уйти.
 
Olehus

Olehus

New Member
Спасибо за совет.
Но вот по логам видно, что через 5 сек было получено уже целых 3 ключевых кадра
[2021-07-07T10:35:58.194Z][DEBUG] '{"VIDEO_SYNC":1625654158622,"VIDEO_K_FRAMES":3,"AUDIO_SYNC":1625654158608,"VIDEO_NACK":0,"AUDIO_RATE":13320,"AUDIO_LOST":0,"VIDEO_LOST":0,"VIDEO_CODEC":119,"VIDEO_B_FRAMES":0,"VIDEO_PLI":0,"AUDIO_CODEC":111,"VIDEO_RATE":1959384,"VIDEO_WIDTH":0,"VIDEO_HEIGHT":0,"VIDEO_FPS":30,"VIDEO_P_FRAMES":148}'
Click to expand...
Но даные о VIDEO_WIDTH и VIDEO_HEIGHT так и остались неопределены.
 
Max

Max

Administrator
Staff member
Olehus said:
Но даные о VIDEO_WIDTH и VIDEO_HEIGHT так и остались неопределены.
Click to expand...
Возможно, клиент эти данные не прислал.
Также метрики лучше проверять для publish сессий: сначала получить список mediaSessionId опубликованных потоков запросом
Code: 
POST /rest-api/stream/find HTTP/1.1
Host: localhost:8081
Content-Type: application/json
 
{
    "published":true
}
а затем для каждого потока получить метрики

POST /rest-api/stream/metrics HTTP/1.1
Host: localhost:8081
Content-Type: application/json

{
"mediaSessionId" : "72b76eb8-3c01-47f3-b308-a0516d51249b"
}

В последних сборках WCS можно получать метрики потока сразу запросом /stream/find
Code: 
POST /rest-api/stream/find HTTP/1.1
Host: localhost:8081
Content-Length: 57
Content-Type: application/json
 
{
    "published":true,
    "display":["metrics"]
}
В этом случае в ответе на запрос будут и метрики потока. Подробнее читайте здесь.
Если же у Вас такие метрики именно для publish сессий, соберите, пожалуйста, отчет, как описано здесь, обязательно включая клиентские дебаговые логи, и пришлите, используя эту форму. В комментариях укажите имена и/или mediaSessionId проблемных потоков.
 
You must log in or register to reply here.
Top