nrkno/sofie-casparcg-server

[2.1.3][2.1.4] File Consumer : dropped frames and choppy audio

Closed this issue · 6 comments

bfmags commented

Issues with the file consumer on NRK 2.1.3, 2.1.4

We are getting a lot of dropped frames that make the clips seem like they are running faster than real time. Running the same clips on 2.0.7 it plays and records fine.

Using a 1080i5000 channel, and getting warnings for buffer and ogl performance warning (buffer allocation/mapping blocked) in the logs, included below.

Tested w/ different machine specs:

hreinnbeck commented

I wonder if this points to a problem handling 4:4:4. Could you test a file that's 4:2:2 or 4:2:0?

Also from your gist it seem the original media is a ProRes file. Any specific reason why you transcode instead of using it? My workflow has been ProRes for CCG for the last 5-6 years.

  • 👍1
bfmags commented

Thank you for your suggestions @hreinnbeck.The original file is actually the transcoded ProRes which is yuv422p10le (I've updated the issue to make it more clear). I'll test outputting a file with 4:2:x profile.

Julusian commented

I have just given this a quick test in both 2.1.4 and 2.0.7 on my machine, and I have noticed a couple of thoughts on this

  1. my machine is happily able to cope with this, so it looks in part like it could be trying to do the encode in a higher quality than those machines can cope with doing in realtime.
    For me (on a 7800X) cpu usage increases by 55% in 2.1 and 15% in 2.0, so recording to file in 2.1 is definitely less performant.
    What is cpu usage like for you in both 2.0 and 2.1?
  2. the output files given from 2.0 and 2.1 are a little different. The only things I can see from the metadata is the chroma subsampling as @hreinnbeck has mentioned, and the audio being PCM in 2.1 and AAC in 2.0. Adding -vf format=yuv420p to the ADD 1 FILE command makes the subsampling match, and also reduces the cpu load by 20%.
    It would be a good idea to have a play around with customising the encode parameters used by ffmpeg to something more tuned to what you want rather than the very unconfigured default encode of ffmpeg. It is interesting that cpu usage did increase so much for me, especially as the output specs were basically the same. Perhaps it would be worth testing with ffmpeg on the command line to compare expected performance?
  3. If the performance is not available on the machine, it is expected that the output file will be missing frames, and due to how the consumer is written means that it will mess up the speed/duration in a not very nice fashion.
  4. Perhaps the frame buffering in 2.1 is not very high? I havent looked at the ffmpeg consumer code really, so don't know if that could have changed between 2.0 and 2.1
mint-dewit commented

On my Windows 10, e5-2670, 32gb, rtx2060 machine I have no problems with recording a 1080i50 channel that has go1080p25 playing on loop. I saw anywhere between 60% and 80% cpu usage.

That's a strange result seeing as that's a very similar setup to your second test machine.

bfmags commented

Thank you all for your input, did a quick test adding the file with yuv420p fastencode and it rendered better, so it looks like it might need some play around. We are going to run some more tests with ffmpeg. I'll come back with our progress.

bfmags commented

After some tweaking, we finally got a constant playable video. We opted for the dnxhd codec with yuv422p, resulting in much less CPU usage (and much larger files too 🙂 ). The host windows server was also missing some performance tuning (GPU and OS set for performance).

 -vcodec dnxhd -b:v 120M -pix_fmt yuv422p -acodec pcm_s16le -vf scale=0:0:interl=1:out_color_matrix=bt709:out_range=tv:flags=lanczos,format=yuv422p