You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've downloaded ExoPlayer-with-RTMP-and-FLV-seek demo and trying to play a RTMP stream, which VLC is able to play. However, all I see in the log is the following:
ExoPlayerImpl: Init 1.5.7
EventLogger: start [0]
EventLogger: state [0.00, false, P]
EventLogger: state [0.19, true, P]
I do see that the packets are being read by RtmpDataSource. I am also able to play HLS streams with the demo app. On the server side, I do see that the client is able to connect to the nginx server. Can you suggest debug steps?
I dug a little deeper into exoplayer flv extractor and see that payload data is being parsed and written to the chunkextractorwrapper video track. Does this mean that exoplayer is not able to then render the video frames?
Another update, it does look like the frames are not drawn onto the surface. When I play HLS, I see surface drawing notifications. With RTMP, I also see that the surface is being set. However, frames are not being rendered to it. I know this isn't the repo for the RTMP work you guys so generously provided. Yet, that repo doesn't have Issues section so I cannot post to it.
I've got additional info. It seems that tracks for video, audio, and meta never become prepared. Their sources are never prepared. From looking at code, once a track's source is set, it is not able to get the format set. The format, at least for video track, is supposed to come from consuming tag data. However, I seem to only get AVC_PACKET_TYPE_SEQUENCE_HEADER only once in the very beginning and never again (I don't know if the server never emits the sequence header or packets with them are ignored by the client).
Also, will the rtmp client handle the case where my RTMP stream does not have autio and text tracks? Currently, I think the playback never starts is because all three (video, audio, and text) tracks are not prepared. However, assuming that is handled, will it work with only one track prepared?
@mekya Let me know if I can provide any more info to debug this issue.
The text was updated successfully, but these errors were encountered:
I've downloaded ExoPlayer-with-RTMP-and-FLV-seek demo and trying to play a RTMP stream, which VLC is able to play. However, all I see in the log is the following:
I do see that the packets are being read by
RtmpDataSource
. I am also able to play HLS streams with the demo app. On the server side, I do see that the client is able to connect to the nginx server. Can you suggest debug steps?I dug a little deeper into exoplayer flv extractor and see that payload data is being parsed and written to the chunkextractorwrapper video track. Does this mean that exoplayer is not able to then render the video frames?
Another update, it does look like the frames are not drawn onto the surface. When I play HLS, I see surface drawing notifications. With RTMP, I also see that the surface is being set. However, frames are not being rendered to it. I know this isn't the repo for the RTMP work you guys so generously provided. Yet, that repo doesn't have Issues section so I cannot post to it.
I've got additional info. It seems that tracks for video, audio, and meta never become prepared. Their sources are never prepared. From looking at code, once a track's source is set, it is not able to get the format set. The format, at least for video track, is supposed to come from consuming tag data. However, I seem to only get
AVC_PACKET_TYPE_SEQUENCE_HEADER
only once in the very beginning and never again (I don't know if the server never emits the sequence header or packets with them are ignored by the client).Also, will the rtmp client handle the case where my RTMP stream does not have autio and text tracks? Currently, I think the playback never starts is because all three (video, audio, and text) tracks are not prepared. However, assuming that is handled, will it work with only one track prepared?
@mekya Let me know if I can provide any more info to debug this issue.
The text was updated successfully, but these errors were encountered: