We are using PHDS streams with an OSMF based player.
all streams that are received via RTMP have no problem
with our player in regarding to showing the subtitles (closed captions)
yet when we get the stream via PHDS it seems that once in
a seek or two, the captions (subtitles) shift ahead for about 0.5-1 secs.
and as mentioned another seek can fix it or leave it out of sync.
our conclusion is that it has to do with the FMS serving the
stream which somehow deviates the current time of the stream.
ps: when getting the stream for the same video via RTMP
via the same player - the subtitles are OK, the problem is only PHDS
Can you tell me which FMS build you are using and what file you are using? Especially codec details and how closed captioning data is present in the file, is it present in the Video data or as a separate track in Data messages.
Does HDS unencrypted plays fine with closed captions?
I need this information to understand your workflow clearly which can help me to diagnose the problem better.
we are using fms build 4.5.2
the captions are loaded as an external file (srt) and digested via our player.
the player uses the currentTime property of the MediaPlayer (osmf) to put
the subtitles on spot and on time.
we tried both unencrypted HDS and PHDS, with same results,
which means a little loss of sync on and off, its not related to
any specific location in the movie, same location can work
well and then not.
rtmp is always in sync btw for the same videos.
video encoding details (media info) :
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 618 MiB
Duration : 2h 20mn
Overall bit rate : 614 Kbps
Writing application : Lavf53.32.100
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2h 20mn
Bit rate mode : Variable
Bit rate : 512 Kbps
Width : 512 pixels
Height : 288 pixels
Display aspect ratio : 16/9
Frame rate mode : Variable
Frame rate : 25.000 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.139
Stream size : 515 MiB (83%)
Writing library : x264 core 124 r2197 69a0443
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=2pass / mbtree=0 / bitrate=512 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 2h 20mn
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 96.7 MiB (16%)
let me know if anything else might help you
help me ...
This is expected.
In case of RTMP you are not observing this because RTMP seek is fast as the server sends some data immediately when we seek irrespective of the keyframe and the player starts playing it so it is in sync.
But in case of HDS we have fragments which are downloaded by the player and it has keyframes in it which can be positioned anywhere in the fragment. So, when you seek you get the current time but this might not be same with the time when the player actually starts playing the fragment as it looks for the keyframe. So, sometimes it can be the case that it got the keyframe immediately when it seeked but tsometimes not.
Europe, Middle East and Africa