zombie
June 29, 2018, 8:40am
1
Hi,
I use basic_example to record the video. I find the keyframe of the video is lost(played by ffplay),and the video is frozen.And I check chrome://webrtc-internals , the packetsLost of the video is zero. Maybe the same issue as this .I use the latest commit(https://github.com/lynckia/licode/commit/18c5562a312b080468f6fdc5f8a0ccec1abbcf54 ).
FYI, I remove minVideoBW and the scheme.
log
2018-06-29 16:25:25,906 - DEBUG [0x700007b13000] media.ExternalOutput - File …/web/a.mkv, audio offset msec: 02018-06-29 16:25:30,931 - DEBUG [0x70000a6e4000] media.ExternalOutput - Unexpected video sequence number; current 18652, previous 9912
you lost the keyframe during the video, or at the beginning?
Thanks for your reply. I played the record mkv file by ffplay ,after a while I got the keyframe lost error and the video is frozen.
Probably the nackgenerator didn’t worked well in this case.
I know that @zevarito is working on a new version of the externalOutput, maybe we should send a PLI here:
av_packet.stream_index = 1;
av_interleaved_write_frame(context_, &av_packet); // takes ownership of the packet
}
void ExternalOutput::writeVideoData(char* buf, int len) {
RtpHeader* head = reinterpret_cast<RtpHeader*>(buf);
uint16_t current_video_sequence_number = head->getSeqNumber();
if (current_video_sequence_number != last_video_sequence_number_ + 1) {
// Something screwy. We should always see sequence numbers incrementing monotonically.
ELOG_DEBUG("Unexpected video sequence number; current %d, previous %d",
current_video_sequence_number, last_video_sequence_number_);
// Restart the depacketizer so it looks for the start of a frame
if (depacketizer_!= nullptr) {
depacketizer_->reset();
}
}
last_video_sequence_number_ = current_video_sequence_number;
if (first_video_timestamp_ == -1) {
need_to_send_fir_ = true;
It will obviously arrive 5 seconds after, but it’s just a “safe” approach.
That’s why we implemented a google-like approach
lynckia:master ← Trisfald:new_nack_generator
opened 01:58PM - 18 Dec 17 UTC
<!--
For more information about contributing code to Licode see:
http://lynck… ia.com/licode/contribute.html
-->
**Description**
<!--
Add a short description here, please.
If the contribution needs and includes Unit Tests check the box below.
-->
This PR adds a new nack generator using an algorithm very similar to the one implemented Chrome. Tthe only difference is that Chrome leverages the decoder to have a more consistent PLI generation. RtcpFeedbackGenerationHandler has been slightly modified, because there are some changes between the old and the new interface; for example it sends a PLI when it fails to recover a packet.
We have deployed this new generator few months ago and got very good results.
[X] It needs and includes Unit Tests
**Changes in Client or Server public APIs**
<!--
Add a detailed description of any change in the public APIs.
If you have included related documentation check the box below.
-->
[] It includes documentation for these changes in `/doc`.