-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
After pushing the audio and video data streams, when pushing pure video data to this channel, VLC player will have abnormal playback and the media information will display an additional audio codec information. #1630
Comments
Looking forward to the author taking a look at this issue, thank you.
|
Attempt with only video scenario, conclusion when video changes:
Below are the steps:
FFMPEG, VLC, and Flash can all successfully pull the video. This shows that there is no problem with the player restarting playback after changing the video. Note that if VLC is not disconnected, changing the codec and video size during streaming will result in a distorted screen. The first time VLC is like this: After the second streaming, VLC (if not disconnected) is like this: After disconnecting VLC and playing, it is normal. It can be seen that if the playback is not disconnected, VLC will have screen flickering after changing the video, while Flash is normal.
|
Trying with both audio and video, keeping the codec unchanged, changing from audio and video to pure video, the conclusions are as follows:
Below are the steps:
At this time, VLC playback fails while Flash playback succeeds. Using srs_rtmp_dump to view server data:
It can be observed that the SequenceHeader of the audio is cached. At this point, since there is no audio available, it causes VLC to fail in synchronizing the audio and video. If you wait long enough (around 10 seconds), the video can be played.
|
Well, but in actual usage, the waiting time for opening the live broadcast is too long, which will result in a poor user experience or be considered a bug.
|
In the case of pure audio, changing the encoding alters the behavior of the player. Conclusion:
The steps are as follows:
FFMPEG, VLC, and Flash can all successfully pull the stream. This indicates that there is no issue with the player restarting after changing the audio. Note that if VLC is not disconnected, changing the codec during streaming can result in audio abnormalities. The first time VLC is like this: After the second streaming, VLC (if not disconnected) looks like this, but the audio is distorted: After disconnecting VLC and playing, it is normal. It can be seen that if the playback is not disconnected, VLC will have audio abnormalities after changing the audio encoding, while Flash is normal.
|
In conclusion, the conclusion is as follows:
|
SRS cache video/audio sequence header has a purpose to avoid sending duplicate SequenceHeader to the same client. For example, if the player remains unchanged but the encoder re-pushes with the same encoding parameters, some players may encounter issues if the encoding and decoding information is directly sent to the client.
We need to separate these two functions.
After verification, this feature is also working fine.
|
Do not change the encoding header, especially for VLC testing, as follows:
Disable streamPush audio and video streams, then only push the video stream, and then only push the audio stream to observe VLC behavior.
New Video StreamPush the audio stream, then push the audio-video stream, and observe VLC behavior:
Replaying allows you to see the audio and video streams. Add audio streamPush video stream, then push audio and video stream, observe VLC behavior:
Repeated Sequence HeaderVLC has no problem with repeated Sequence Headers. It can handle repeated ones, but not different ones.
|
In summary: VLC relies on the initial encoding header information. Although SRS provides the correct encoding header, it still cannot correctly recognize the newly added stream.
|
Description'
Please ensure that you maintain the markdown structure.
Please ensure that you maintain the markdown structure.
3.0.121
Please ensure that you maintain the markdown structure.
Please ensure that you maintain the markdown structure.
Replay
Please ensure that you maintain the markdown structure.
How to replay bug?
The pure video data file used for replay can be found at: link (password: cnvp).
Please ensure that you maintain the markdown structure.
1. Pushing pure video stream data to channel A using ffmpeg, the rtmp playback is normal, and VLC's meta information also shows that only the video type stream is present.
Please ensure that you maintain the markdown structure.
2.
ffmpeg -re -i 1583334009334.flv -vcodec copy -f flv -y rtmp://localhost:1935/live/LIVEPL16DD80CE047_2
1. Whether using ffmpeg or pushing data containing both audio and video to ChannelA, the rtmp playback is normal, and VLC's meta information will display two streams, one for audio and one for video.
Please ensure that you maintain the markdown structure.
2.
ffmpeg -re -i 1583334009334.flv -vcodec copy -acodec copy -f flv -y rtmp://localhost:1935/live/LIVEPL16DD80CE047_2
1. Repeating the operation in step 1, pushing a stream of pure video data to Channel A results in abnormal rtmp playback (VLC cannot play, it remains black after a long buffering time). In VLC's meta information, besides displaying the video's meta information, an additional audio stream meta information will also be displayed.
2. Using ffmpeg to push the stream of pure video to a new channel B, rtmp playback is normal again.
3. Suspected that VLC or ffprobe may cache meta information, but even after closing and reopening VLC, the issue remains as described above.
4. Only after restarting the SRS service, the additional display of audio meta information will no longer occur.
Please ensure that you maintain the markdown structure.
Expected behavior
Expected behavior:
TRANS_BY_GPT3
The text was updated successfully, but these errors were encountered: