Глюк с перекодированием в h264

pride

Member
---------------------------------------------------------------
Сервер:
OS: CentOS Linux release 7.4.1708
Core: Linux 3.10.0-693.11.1.el7.x86_64
WCS : 5.1.3375
---------------------------------------------------------------
Трансляция:
OS: Win XP SP3 x86
Browser: Chrome 49.0.2123.112m
Codec: VP8
---------------------------------------------------------------

ip =0.0.0.0
ip_local =0.0.0.0
port_from =30000
port_to =31000
media_port_from =31001
media_port_to =32000
waiting_answer =60
user_agent =WCS5
balance_header =balance
cost_header =cost
video_enabled =true
domain =mdeia.online
outbound_proxy =
outbound_port =
log_level =5
enable_context_logs =false
rtp_activity_detecting =true,60
sip_msg_listener =com.flashphoner.sdk.sip.ChangeCallIdListener
call_record_listener =com.flashphoner.server.client.DefaultCallRecordListener
dtmf =rfc2833
auto_login_url =/usr/local/FlashphonerWebCallServer/conf/account.xml
get_callee_url =/usr/local/FlashphonerWebCallServer/conf/callee.xml
codecs =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
codecs_exclude_sip =mpeg4-generic,flv,mpv
codecs_exclude_streaming =flv,telephone-event
codecs_exclude_sip_rtmp =opus,g729,g722,mpeg4-generic,vp8,mpv
on_record_hook_script =on_record_hook.sh
rtmp_transponder_stream_name_prefix =
ws.port =8080
wss.port =8443
wss.keystore.password =password
wss.cert.password =password
rtmp.port =1935
rtmfp.port =1935
keep_alive.algorithm =HIGH_LEVEL
keep_alive.peer_interval =2000
keep_alive.server_interval =5000
keep_alive.probes =10
keep_alive.enabled=websocket,rtmfp
video_reliable =partial
audio_reliable =partial
audio_frames_per_packet =6
burst_avoidance_count =100
flush_audio_interval =80
flush_video_interval =0
hls_server_enabled =false
streaming_video_decoder_fast_start=false
webrtc_cc2_bitrate_overuse_event = false
resample_video = false
webrtc_cc_max_bitrate=3000000
webrtc_cc_min_bitrate=1000000
webrtc_cc2_cc=false
Здравствуйте! Заметили очень неприятный глюк с перекодированием.
Если трансляция идет с кодеком VP8, а просмотр h264, то со временем получаем такую картину:

Пробовали включать запись потока (средствами WCS), он пишется в кодеке VP8, в записи этой проблемы нет.
По этой причине предполагаем что дело в кодирование из VP8 в H264.
Подскажите как решить данную проблему?
 

Max

Administrator
Staff member
Воспроизводится ли проблема в стандартном примере Two Way Streaming?
https://demo.flashphoner.com/client...ming/two_way_streaming/two_way_streaming.html
Что если сделать две страницы two-way-streaming1.html и two-way-streaming2.html
Первая будет стримить VP8
Code:
session.createStream({name:'stream1',stripCodecs:"h264,H264"}).publish();
Вторая будет играть H.264
Code:
session.createStream({name:'stream1',stripCodecs:"vp8,VP8"}).play();
Если действительно идет перекодирование, его должно быть видно в мониторинге и статистике:
Мониторинг транскодеров
upload_2018-7-18_17-33-53.png

Мониторинг транскодеров http (поле native_resources)
upload_2018-7-18_17-36-32.png


Попытаемся воспроизвести проблему у себя. По результатам отпишем.
 

Max

Administrator
Staff member
Добрый день.
В наших тестах проблема не воспроизвелась.
Тестировали сборку 5.1.3375
  • Windows 10;
  • Chrome Версия 67.0.3396.99 (Официальная сборка), (64 бит), аппаратное ускорение включено;
  • Поток публиковался с VP8 в Two-Way Streaming, проигрывался с H264 в Two-Way Streaming на протяжении ~30 минут;
Во вложениях видно как именно был сконфигурирован тест для транскодинга из VP8 в H.264.
На последнем скриншоте видно статистику транскодинга.

Пришлите пожалуйста SSH доступ к вашему серверу и инструкцию по тестированию на базе нашего стандартного примера Two Way Streaming.
support@flashphoner.com
 

Attachments

Top