Change colorspace to 4:2:2

[a-tze]

Rumors say that the current (default) config uses YUV420 as colorspace. This might be too lossy for some sophisticated scenarios. Therefore the default should be changed to YUV422.

Note: YUV444 does not make sense, since single-link HD SDI carries "only" YUV422 signals.

[MaZderMind]

The ffmpeg pix_fmt yuv422p is detected by gstreamer as video/x-unknown, codec-id=(string)V_UNCOMPRESSED.

The Decklink-Cards produce video with a pix_fmt of uyvy422 which gstreamer detects as video/x-raw, format=(string)UYVY -- so this would be a good start.

Interestingly the avenc_huffyuv encoder (and fwiw also the avenc_ffvhuff) encoder mentioned in https://github.com/voc/voctomix/issues/9#issuecomment-161053845 only support Y42B which may or may bot be just another name for the same thing. anyways, there will be at least one colorspace conversion here (in the ui-preview chain).

[MaZderMind]

Testing this in practice turned a small problem up: after ~12 minutes, the input queue in ffmpeg's decklink code hits 1GB and ffmpeg starts to drop buffers by hitting this codepath: https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_dec.cpp#L116

ffmpeg then starts to print lots and lots of ""Decklink input buffer overrun!" messages while still repoorting 25fps being pushed out. On the gstreamer-side it seems that not enough frames are received (or not in time), so that the intervideosrc starts to inject black frames which makes the video look like it's flickering on/off/on/off.

This can be reproduced with this command (on gstreamer 1.5.90):

ffmpeg -y \
  -f decklink \
  -i 'DeckLink Mini Recorder (1)@10' \
  -c:v rawvideo -c:a pcm_s16le \
  -f matroska \
  pipe: | gst-launch-1.0 fdsrc ! matroskademux name=demux \
    demux. ! queue ! video/x-raw,format=UYVY,width=1920,height=1080,framerate=25/1,pixel-aspect-ratio=1/1 ! intervideosink \
    demux. ! queue ! audio/x-raw,format=S16LE,channels=2,layout=interleaved,rate=48000 ! interaudiosink

changing intervideosink and interaudiosink to fakesinks fixes the problem, as well as changing from UYVY/uyvy422 back to I420/yuv420p. For this reason on our production-system we reverted to the latter.

It's currently unclear weather this is a bug in gstreamer of ffmpeg or it it is me, holding it wrong.

[MaZderMind]

Ran another test on this tonight and it seems that leaving away the audio makes things work again:

ffmpeg -y \
  -f decklink \
  -i 'DeckLink Mini Recorder (1)@10' \
  -map 0:v \
  -c:v rawvideo \
  -f matroska \
  pipe: | gst-launch-1.0 fdsrc ! matroskademux name=demux \
    demux. ! queue ! video/x-raw,format=UYVY,width=1920,height=1080,framerate=25/1,pixel-aspect-ratio=1/1 ! intervideosink

[MaZderMind]

More tests show, that it's likely a combination. running voctocore with one declink source in 422 worked for 42 hours, added a second one and both stopped working after ~1 hour.

Also, running ffmpeg on a decklink-card that has no source connected, triggers the issue with all colorspaces and resolutions.

My current guess is that using 422 upps the stream bandwidth from 593 MBit/s to 791 MBit/s and that triggers something in either ffmpeg or the core or the kernel handling the tcp connection.

[MaZderMind]

cleaned up the thread, removed false assumptions and added explanation of the issue.

[MaZderMind]

Example of how the problematic processes show up:

And a Video of how this looks in the GUI: https://c3voc.mazdermind.de/permanent/issue-33-gui.mp4

[a-tze]

The screenshot shows a "-pix_fmt yuv420p" in the ffmpeg lines for capturing?

[MaZderMind]

@a-tze yes, true. The screenshot showed the problem when no source would be connected. In this case the colorspace would not matter.

[MaZderMind]

@a-tze is this still a thing after #143 or should we stay at 420?

[a-tze]

Well 422 would still be nice but I think most users (or even all) end up with 420 in their final encoded essences and it's "only" a quality thing.