Answers.Body: <p>I get the same result with your commands, however if I skip the pixel format conversion and use the input pixel format 'bgr0', then except for an initial frame drop, I get no further drops. Note that tune is a x264 parameter - it has no relevance for FFV1.</p>
  
  <p>And if I use gdigrab (my preferred grabbing device), I get no frame drops at all, even with bgra:-</p>
  
  <pre><code>ffmpeg -y -f gdigrab -i desktop -framerate 30 -c:v ffv1 -pix_fmt bgra -t 5 capture.mkv
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-11T20:37:07.497Z
Answers.Text: Oh, i have a weird problem. You know in order to have the libfdk_aac i compilated the ffmpeg build with the linux cross compile script https://github.com/rdp/ffmpeg-windows-build-helpers/blob/master/cross_compile_ffmpeg.sh but i guess gdigrab is missing. Also a dumb question that i would still like to ask, for screen recording the input will be always rgb24 or equivalents right? Make any sense using a 32bit (rgba) ?
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-11T20:50:16.357Z
Answers.Text: Yeah, no sense recording an alpha plane for screen capture. Just grab a static ffmpeg build from Zeranoe; rename that EXE and use it for capture.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-11T22:47:45.727Z
Answers.Text: You right about this, but I would like an omnicomprehensive ffmpeg executable. Tomorrow i will see if i can build a more complete version :) So about the alpha, asking it to record a 32 bit ver of a screen capture, the alpha will just be filled with zero?
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-11T22:56:53.157Z
Answers.Text: Oh and i tried the gdigrab, differently from the screen-capture-recorder that handles only the main monitor, gdigrab grabs ALL the monitors together, there's a more simple way for selecting the monitor like 1, 2, 3? Or the only possible way is to deal with the offsets? (this require specifying manually the resolution, thing that could change time by time if you want to use that batch somewhere else)
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-12T06:27:01.843Z
Answers.Text: The alpha plane will be useless. Not sure if it is zeroed or random data. Check in a compositing app. Can't find any qualifier right now to select only one monitor for capture. Since ffmpeg can capture a single window when given title, I think it may be possible if there is an equivalent ID assigned internally to a single monitor's output. Will need some research.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-12T09:11:35.217Z
Answers.Text: Thanks man ;) maybe I could try to send a mail to the developers and ask.
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-12T12:33:21.350Z
Answers.Text: You can post a bug report at https://ffmpeg.org/bugreports.html. Make sure to submit the syntax and console output, and ask specific questions :)
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-11T19:31:51.823Z
Answers.LastActivityDate: 2015-11-11T19:31:51.823Z
Answers.UserDisplayName: Gyan
Body: <p>Can you help me to figure out what's going on here?</p>
  
  <p>I'm trying to capture in realtime my screen and save it losslessy via ffv1 codec.</p>
  
  <p><a href="https://i.sstatic.net/nzXQM.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/nzXQM.png" alt="ffmpeg encoding ffv1 errors on console"></a></p>
  
  <p>CPU usage while recording is not so much, as comparison h264 in ultrafast profile takes lot more cpu than ffv1.</p>
  
  <p>Here's the command I'm using:</p>
  
  <pre><code>ffmpeg -f dshow -y -i video="screen-capture-recorder" -framerate 30 -c:v ffv1 -pix_fmt bgra -t 5 capture.mkv
  </code></pre>
  
  <p>I tried also adding the tuning and rtbufsize but nothing changes :\</p>
  
  <pre><code>ffmpeg -f dshow -y -i video="screen-capture-recorder" -framerate 30 -c:v ffv1 -pix_fmt bgra -t 5 -tune zerolatency -rtbufsize 2100M capture.mkv
  </code></pre>
  
  <p>Any suggestions? :)</p>
  
Tags: <ffmpeg><codec>
Title: ffv1 realtime capture throws out a lot of frame dropped messages!
UserDisplayName: user3450548
ThreadText: # ffv1 realtime capture throws out a lot of frame dropped messages!
  
  (Asked by: username_0 on 2015-11-11)
  
  Can you help me to figure out what's going on here?
  
  I'm trying to capture in realtime my screen and save it losslessy via ffv1 codec.
  
  [![ffmpeg encoding ffv1 errors on console](https://i.sstatic.net/nzXQM.png)](https://i.sstatic.net/nzXQM.png)
  
  CPU usage while recording is not so much, as comparison h264 in ultrafast profile takes lot more cpu than ffv1.
  
  Here's the command I'm using:
  
  ```
  ffmpeg -f dshow -y -i video="screen-capture-recorder" -framerate 30 -c:v ffv1 -pix_fmt bgra -t 5 capture.mkv
  
  ```
  
  I tried also adding the tuning and rtbufsize but nothing changes :\
  
  ```
  ffmpeg -f dshow -y -i video="screen-capture-recorder" -framerate 30 -c:v ffv1 -pix_fmt bgra -t 5 -tune zerolatency -rtbufsize 2100M capture.mkv
  
  ```
  
  Any suggestions? :)
  
  **Tags:** ffmpeg, codec
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-11-11. Score: 3
  
  I get the same result with your commands, however if I skip the pixel format conversion and use the input pixel format 'bgr0', then except for an initial frame drop, I get no further drops. Note that tune is a x264 parameter - it has no relevance for FFV1.
  
  And if I use gdigrab (my preferred grabbing device), I get no frame drops at all, even with bgra:-
  
  ```
  ffmpeg -y -f gdigrab -i desktop -framerate 30 -c:v ffv1 -pix_fmt bgra -t 5 capture.mkv
  
  ```
  
  > **Comments:**
  > **username_0**: Oh, i have a weird problem. You know in order to have the libfdk_aac i compilated the ffmpeg build with the linux cross compile script https://github.com/rdp/ffmpeg-windows-build-helpers/blob/master/cross_compile_ffmpeg.sh but i guess gdigrab is missing. Also a dumb question that i would still like to ask, for screen recording the input will be always rgb24 or equivalents right? Make any sense using a 32bit (rgba) ?  
  > **username_1**: Yeah, no sense recording an alpha plane for screen capture. Just grab a static ffmpeg build from Zeranoe; rename that EXE and use it for capture.  
  > **username_0**: You right about this, but I would like an omnicomprehensive ffmpeg executable. Tomorrow i will see if i can build a more complete version :) So about the alpha, asking it to record a 32 bit ver of a screen capture, the alpha will just be filled with zero?  
  > **username_0**: Oh and i tried the gdigrab, differently from the screen-capture-recorder that handles only the main monitor, gdigrab grabs ALL the monitors together, there's a more simple way for selecting the monitor like 1, 2, 3? Or the only possible way is to deal with the offsets? (this require specifying manually the resolution, thing that could change time by time if you want to use that batch somewhere else)  
  > **username_1**: The alpha plane will be useless. Not sure if it is zeroed or random data. Check in a compositing app. Can't find any qualifier right now to select only one monitor for capture. Since ffmpeg can capture a single window when given title, I think it may be possible if there is an equivalent ID assigned internally to a single monitor's output. Will need some research.  
  > **username_0**: Thanks man ;) maybe I could try to send a mail to the developers and ask.  
  > **username_1**: You can post a bug report at https://ffmpeg.org/bugreports.html. Make sure to submit the syntax and console output, and ask specific questions :)  
  
  ---
  
  