# Video Record issue

**URL:** <https://discourse.lynckia.com/t/video-record-issue/803>\
**Category:** Support\
**Created:** [June 29, 2018, 8:40am UTC](https://discourse.lynckia.com/t/video-record-issue/803 "2018-06-29T08:40:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![zombie](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.lynckia.com/zombie/32/37_2.png) [@zombie](https://discourse.lynckia.com/u/zombie)\
**Post date:** [June 29, 2018, 8:40am UTC](https://discourse.lynckia.com/t/video-record-issue/803/1 "2018-06-29T08:40:16Z")

</div>

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](https://discourse.lynckia.com/t/bug-licode-fails-to-record-properly-can-pay-3000-or-more-for-the-help/767/4).I use the latest commit([https://github.com/lynckia/licode/commit/18c5562a312b080468f6fdc5f8a0ccec1abbcf54](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: 0  
2018-06-29 16:25:25,917 - DEBUG [0x700007b13000] media.ExternalOutput - File …/web/a.mkv, video offset msec: 11  
**2018-06-29 16:25:30,931 - DEBUG [0x70000a6e4000] media.ExternalOutput - Unexpected video sequence number; current 18652, previous 9912**  
2018-06-29 16:29:29.436 - INFO: Publisher - message: Removing ExternalOutput, url: …/web/a.mkv  
2018-06-29 16:29:29,437 - DEBUG [0x700009ddb000] OneToManyProcessor - Remove subscriber …/web/a.mkv

* * *

---

<div class="post-metadata">

**Author:** ![Francesco\_Durighetto](https://avatars.discourse-cdn.com/v4/letter/f/a9a28c/32.png) [@Francesco\_Durighetto](https://discourse.lynckia.com/u/Francesco_Durighetto)\
**Post date:** [July 3, 2018, 7:03am UTC](https://discourse.lynckia.com/t/video-record-issue/803/2 "2018-07-03T07:03:39Z")

</div>

you lost the keyframe during the video, or at the beginning?

---

<div class="post-metadata">

**Author:** ![zombie](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.lynckia.com/zombie/32/37_2.png) [@zombie](https://discourse.lynckia.com/u/zombie)\
**Post date:** [July 3, 2018, 7:18am UTC](https://discourse.lynckia.com/t/video-record-issue/803/3 "2018-07-03T07:18:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Francesco\_Durighetto](https://avatars.discourse-cdn.com/v4/letter/f/a9a28c/32.png) [@Francesco\_Durighetto](https://discourse.lynckia.com/u/Francesco_Durighetto)\
**Post date:** [July 3, 2018, 7:42am UTC](https://discourse.lynckia.com/t/video-record-issue/803/4 "2018-07-03T07:42:45Z")

</div>

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:

> <https://github.com/lynckia/licode/blob/18c5562a312b080468f6fdc5f8a0ccec1abbcf54/erizo/src/erizo/media/ExternalOutput.cpp#L217>

> need\_to\_send\_fir\_ = true;

It will obviously arrive 5 seconds after, but it’s just a “safe” approach.  
The nack generator should ensure that everything is arriving correctly to the server but sometimes it misses something…

That’s why we implemented a google-like approach

> <https://github.com/lynckia/licode/pull/1096>
>
> \<!--
> 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\`.