Decklink Lip-sync trouble

[laurfb]

Summary of the bug:

Hi. I've have some trouble trying to save or play an rtmp stream with ffmpeg (lip-sync trouble).
The same stream plays without any trouble with ffplay!
Seems that ffmpeg connot manage very well (although ffplay can!) any DTS errors (see attached ffprobe report)

The ffmpeg package is build from the master ffmpeg git (N-74786-g50f2f7a).
The live stream can be viewed at rtmp://82.208.148.204:1935/live/tvriasi

I try variour -vsync/async option without any luck.
Any help will be appreciated.

best regards,
laurb

How to reproduce:

% ffmpeg -i rtmp://82.208.148.204:1935/live/tvriasi -c copy -f flv stream_test.flv
ffmpeg -i rtmp://10.10.32.128:1935/live/tvriasi -c copy -f flv rtmp_stream.flv -report
ffmpeg version N-74786-g50f2f7a Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.2.0 (Rev3, Built by MSYS2 project)
  configuration: --target-os=mingw32 --prefix=/local32 --bindir=/local32/bin-video --enable-static --disable-shared --disable-debug --enable-gpl --disable-w32threads --enable-avisynth --pkg-config-flags=--static --enable-librtmp --enable-frei0r --enable-libopenjpeg --enable-libass --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libschroedinger --enable-libsoxr --enable-libtwolame --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvo-aacenc --enable-libopus --enable-libvidstab --enable-libxavs --enable-libxvid --enable-libzvbi --enable-libdcadec --enable-libbs2b --enable-libcdio --enable-libfreetype --enable-fontconfig --enable-libfribidi --enable-opengl --enable-libvpx --enable-libx264 --enable-libx265 --enable-libkvazaar --enable-libwebp --enable-decklink --enable-libgme --enable-nonfree --enable-nvenc --enable-libfdk-aac --enable-openssl --extra-cflags=-DMODPLUG_STATIC --extra-cf  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100

[laurfb]

ffprobe report

[Carl Eugen Hoyos]

I tested the following and the output file plays in-sync here:

$ ffmpeg -i rtmp://82.208.148.204:1935/live/tvriasi -codec copy out.flv
ffmpeg version N-74796-g26a0cd1 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
[flv @ 0x2e493e0] Stream discovered after head already parsed
Input #0, flv, from 'rtmp://82.208.148.204:1935/live/tvriasi':
  Metadata:
    Server          : NGINX RTMP (github.com/arut/nginx-rtmp-module)
    displayWidth    : 720
    displayHeight   : 576
    fps             : 0
    profile         :
    level           :
  Duration: 00:00:00.00, start: 6323.712000, bitrate: N/A
    Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709), 720x576 [SAR 12:11 DAR 15:11], 2048 kb/s, 25 fps, 25 tbr, 1k tbn, 50 tbc
    Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp
[flv @ 0x2fa6aa0] Codec for stream 0 does not use global headers but container format requires global headers
[flv @ 0x2fa6aa0] Codec for stream 1 does not use global headers but container format requires global headers
Output #0, flv, to 'out.flv':
  Metadata:
    Server          : NGINX RTMP (github.com/arut/nginx-rtmp-module)
    displayWidth    : 720
    displayHeight   : 576
    fps             : 0
    profile         :
    level           :
    encoder         : Lavf56.40.101
    Stream #0:0: Video: h264 ([7][0][0][0] / 0x0007), yuv420p, 720x576 [SAR 12:11 DAR 15:11], q=2-31, 2048 kb/s, 25 fps, 25 tbr, 1k tbn, 1k tbc
    Stream #0:1: Audio: aac ([10][0][0][0] / 0x000A), 48000 Hz, stereo
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 5636 fps= 51 q=-1.0 Lsize=   26433kB time=00:01:53.57 bitrate=1906.6kbits/s
video:23630kB audio:2605kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.755971%

Please test and confirm: ​http://www.datafilehost.com/d/cf64c9c0

Note that I believe there are better tools if you only want to dump the flv stream, FFmpeg is primarily useful for filtering and transcoding.

[laurfb]

Hi. My mistake :(
Yes, ffplay, vlc, mpc or any other software player allways play well the saved file or live stream.
The lip-sync issue apperar allways when I try to play/output the live stream or saved files from ffmpeg to any decklink output card (video & audio). It's not related to decklink cause any proper flv file without timestamp error is allways played well.
Seems that ffmpeg cannot properly handle the DTS timestamp error while ffplay can!
The same stream/saved files plays allways without any trouble with ffplay!
Running ffprobe on out.flv file you provided or on any live stream from that live source we can see allways "Non-increasing DTS in stream..." error.
I think the lip-sync issue is related only to the way that ffmpeg handle that DTS error.

best regards,
laur

[Carl Eugen Hoyos]

Please test attached stream and provide the command line that allows to reproduce your issue together with the complete, uncut console output to make this a valid ticket.

[laurfb]

Hi. Please find in attach (ffmpeg-20150904-122756.log) the command line and the uncut console output for provided lipsync.flv file.
best regards,
laur

[Carl Eugen Hoyos]

Please remove the input option -r 25 (it could be responsible for your issue), or is it needed? In this case, please test the output option -r.
And please remove the unneeded audio options, imo they only make understanding the problem more difficult.

[laurfb]

Hi. Without "-r 25" option the decklink output is green.
I put in attach both report, generated with minimal command option for decklink output, with or without "-r 25").
best regards,
laur

[Carl Eugen Hoyos]

Replying to laurfb:

Hi. Without "-r 25" option the decklink output is green.

Is that expected? I don't see anything related in the documentation.
In any case, please use the output option -r, the input option -r afaict is supposed to produce a desync issue.

[laurfb]

Hi. Nope, is not expected; ussualy we don't need to explicit specify the frame rate on input.
-r option on output has no influence: output is green too (with sound)
In that particular case maybe the timestamp error need to specify the input frame rate.
Generally the -r option is not needed to play something on decklink (either on input or output).

best regards,
laur

[Carl Eugen Hoyos]

Does playback (as opposed to the green screen you see) work if you seek into the input file?

[laurfb]

Hi. Nothing changed.
Same result with various zeranoe build (from january 2015 till now) with three diferent DeckLink cards (Extreme, SDI, Mini Monitor).
Compiling ffmpeg I found that decklink code need some cleanup/reworking.
In compile log (attached) I've got :

• some warning about invalid/redundant declarations
• some warning about winsock2.h
• some warnig about deprecated functions

Don't know if fixing those warnings will solve timestamp/lip-sync issue related to decklink output.

best regards,
laur

[Carl Eugen Hoyos]

Replying to laurfb:

Hi. Nothing changed.

What did you test?

[laurfb]

Hi.
I try to play uploaded lipsync.flv test file (with -ss seeking option).

regards,
laur

[Carl Eugen Hoyos]

Did you try both seeking options?

[laurfb]

Yes :(
In first case (-ss option before -i) the output contain green field intercalated with normal image.
For -ss option after -i the image is normal but with lipsync issue...
In attach both report file (console output).
regards,
laur

[Carl Eugen Hoyos]

Replying to laurfb:

For -ss option after -i the image is normal but with lipsync issue...

Did you test without the input option -r?

[laurfb]

yes, output is all green.