Results 1 to 4 of 4

Thread: Windows FFMPEG with NDI outputs interlaced on progressive sources

  1. #1
    Registered User
    Join Date
    Mar 2017
    Location
    Bordeaux
    Posts
    6

    Windows FFMPEG with NDI outputs interlaced on progressive sources

    Hi

    I'm having issues with my progressive incoming feeds (RTMP, RTSP, HLS, TS, ...) being converted to interlaced for NDI even though they are seen as progressive by FFMPEG...
    Tried the "-allow_video_fields 0" argument (which is for receiving only if I'm right), but still Monitor or Diag Tool see my feed as interlaced after conversion (though it is not interlaced)

    So basically I have 25p IN and 50i OUT (at least in metadata, cos I don't feel like it's really interlaced)

    Any clue?

    Guillaume

    PS : I'm using the FFMPEG build provided by Newtek in SDK

  2. #2
    Registered User
    Join Date
    Apr 2017
    Location
    Massachusetts
    Posts
    156
    I've gone through some similar ffmpeg/NDI issues, and have gathered some tips I learned myself and that I got via the helpful FogBugz ticket I submitted:

    1. Use the "-re" option to read the file/stream at the file's reported framerate, I had some issues with ffmpeg feeding to ndi too quickly resulting in stuttering
    2. According to NewTek, ffmpeg has a bug involving reading progressive files, so add this option to force it to read as progressive: "-field_order progressive"
    3. Finally, try the "-clock_video true -clock_audio true" settings, which relies on the video file to "clock" rather than ffmpeg itself (I don't really understand this one fully, but it worked for me!)

    Here's the command I ended up with for testing that worked well for a 720p60 source:

    ffmpeg.exe -re -i "test720p60.ts" -field_order progressive -c:v wrapped_avframe -pix_fmt uyvy422 -c:a pcm_s16le -f libndi_newtek -clock_video true -clock_audio true -y NDIFFMPEG

    Thanks to Andrew for the help via FogBugz
    TriCaster TC1 #1
    TriCaster TC1 #2
    NC1 Studio I/O Module
    TriCaster Mini SDI Advanced #1
    TriCaster Mini SDI Advanced #2
    Video Nerd

  3. #3
    Registered User
    Join Date
    Mar 2017
    Location
    Bordeaux
    Posts
    6
    Thanks to you and Luke!

    the "-field_order progressive" argument solves the incorrect conversion to 50i on 25p sources. Good!

    However the "-re" argument cannot be used when FFMPEG behaves as a server with "listen" argument which I do for RTMP (my encoder streams to FFMPEG directly, there's no other RTMP server involved). I tried anyway but it results in many encoding artefacts as it does work in realtime anymore (speed = 0.99x) and I see a warning about reorder buffer being increased to 1 (Will investigate this).

    I already use "-re" argument for HLS, TS and so on... I will also try with FFMPEG acting as an RTMP client behind a regular server where "-re" argument is required.

    I also tried with "wrapped_avframe" but I think it's unnecessary as it's already done by FFMPEG libndi by default

    Regarding "-clock_video true -clock_audio true", it also results in many artefacts and encoding process being slowed down to under realtime (speed 0.99x). According to the poor documentation, these arguments are supposed to be used for files only to keep correct sync. My work is about streaming protocols where no files are involved at all.

    So far, it's close to perfect. I only experience 2 last issues:
    - very slight audio "stuttering" from time to time. Will try to improve cache and buffer settings for this. My incoming RTMP stream is perfect, so it's a conversion issue for sure...
    - very strange bitrate fluctuation when I use NDI Diagnostic. It reports bitrates from 30 to 250 Mbits for a 720p NDI feed. Not sure how to interpret this. I was expecting something like constant 70/75 Mbits on my feed. Will test more to try to understand.

    Thanks again!
    Guillaume
    Last edited by DWAM; 11-11-2018 at 07:24 AM.

  4. #4
    Registered User
    Join Date
    Mar 2017
    Location
    Bordeaux
    Posts
    6
    I'm not sure who's to blame for this issue with FFMPEG but it seems FFMPEG correctly detects inputs as progressive as seen in this screenshot below

    Click image for larger version. 

Name:	ffmpeg.png 
Views:	16 
Size:	510.7 KB 
ID:	143339

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •