voctomix: Problem with newer ffmpegs (interlace-mode)

Newer ffmpegs set the fields in the mkv stream different, when the interlace-mode is unknown. Older ffmpegs just the the mode to progressive which is the value voctomix expects. Newer versions set it to undefined (which means that each frame has its own interlaced-flag). Voctomix can’t handle this format.

Setting -field_order 0 on ffmpeg forces ffmpeg to write the interlace-mode as progressive. We should check if older ffmpegs can live with this additional flag and extend all ffmpeg-based example-script with it.

Edit: Additionally voctocore should print out a helpful message when such a situation is encountered with a hint on how to change the sourcing ffmpeg script, to make it compatible again.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 21 (21 by maintainers)

Most upvoted comments

@a-tze I hope you don’t mind that I moved your comment about the deinterlacer in the decklink-sources to #154 – i would like to keep this already rather long issue focused on the compatibility between ffmpeg and voctomix – the decklink sources are a totally different story.

MaZderMind on Sep 5, 2017

@Florob In my mind the point of this Issue is to allow sourcing content with recent ffmpeg versions (whichever kind of content that is). The whole voctomix core is not capable of handling content marked as interlaced so at some point in the input chain something has to mark the content as progressive.

Ideally this would be ffmpeg as the root source, but the gstreamer bug does prevent this. Next in line is our TCPAVSource implementation. Following your preference I go forward and disallow sources which are marked as mixed or interlaces, printing a warning which is along the lines of

The video-stream received was marked as being of [interlaced|mixed (interlaced/progressive)] content. Voctomix can only handle content which is marked as being progressive (although it can handle interlaced content if you deinterlace the output correctly – but this is up to you).

Note that there is currently a bug in gstreamer which prevents correct detection of progressive content generated from ffmpeg 3.1+ – see https://github.com/voc/voctomix/issues/137

If you are sure that your source is correct, you can set the config-option [source.cam1] interpret-as-progressive=true to force voctomix to accept this source, despite it being marked [interlaced|mixed (interlaced/progressive)]

Setting this option would inject the capssetter, but this has to be a deliberate decision.

Regarding the decklinksources aready running yadif I opened #153 to update the example-scripts

MaZderMind on Sep 5, 2017