Unable to playback hardware encoded H.264 to RED5 server using FFmpeg on Windows

[lhastie]

I have a USB camera that is capable of H.264 on-board compression. I use the following FFmpeg command line to grab the encoded H.264 from the camera and put it in a 'flv' container :

ffmpeg -y -f dshow -vcodec h264 -i video="USB Camera" -vcodec copy -copyinkf -f flv c:\temp\test.flv

This works as expected and I can view the video using VLC no problem. Following this principle I then attempt to stream to a RED5 server using the following command :

ffmpeg -y -f dshow -vcodec h264 -i video="USB Camera" -vcodec copy -copyinkf -f flv rtmp://192.168.75.34/live/livestream

The RED5 server detects the stream but I am unable to connect to it and view it using my basic Python program.

If I do the same thing but use FFmpeg to carry out H.264 encoding of the default capture pin (MJPEG), it will stream correctly.

Here is the FFmpeg version and log output from the second FFmpeg command :

ffmpeg -y -f dshow -vcodec h264 -i video="USB Camera" -copyinkf -vcodec copy -f flv rtmp://192.168.75.176/live/livestream
ffmpeg version N-93252-gf948082e5f Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.2.1 (GCC) 20190212
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
  libavutil      56. 26.100 / 56. 26.100
  libavcodec     58. 47.102 / 58. 47.102
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  6.101 / 58.  6.101
  libavfilter     7. 48.100 /  7. 48.100
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Input #0, dshow, from 'video=USB Camera':
  Duration: N/A, start: 1936614.028000, bitrate: N/A
    Stream #0:0: Video: h264 (Main) (H264 / 0x34363248), yuv420p, 1920x1080, 30 fps, 30 tbr, 10000k tbn, 20000k tbc
Output #0, flv, to 'rtmp://192.168.75.176/live/livestream':
  Metadata:
    encoder         : Lavf58.26.101
    Stream #0:0: Video: h264 (Main) ([7][0][0][0] / 0x0007), yuv420p, 1920x1080, q=2-31, 30 fps, 30 tbr, 1k tbn, 10000k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
frame= 1426 fps=5.0 q=-1.0 Lsize=   34955kB time=00:04:44.94 bitrate=1004.9kbits/s speed=1.01x

I'm not sure if there is some flag in the command line that I might be missing? Any help with this issue would be much appreciated.

[Carl Eugen Hoyos]

Replying to lhastie:

The RED5 server detects the stream but I am unable to connect to it and view it using my basic Python program.

If I do the same thing but use FFmpeg to carry out H.264 encoding of the default capture pin (MJPEG), it will stream correctly.

This sounds to me as if you want to report a bug to your hardware provider or the RED5 developers, no?

[lhastie]

I raised the issue with the hardware provider and they assured me that the camera should work on Windows with DShow, although they said that they do not use FFmpeg themselves. I have managed to get the camera to stream to RED5 using FFmpeg pipes. See command below :

ffmpeg -y -f dshow -vcodec h264 -i video="USB Camera" -vcodec copy -copyinkf -f flv pipe:1 | ffmpeg -i pipe:0 -c copy -f flv rtmp://192.168.75.34/live/livestream

Although I cannot explain why this works and my command without the pipes doesn't. Any insight would be appreciated.

[Carl Eugen Hoyos]

Does the original command line also fail if you don’t force copying initial non-key frames?

[lhastie]

If I remove the copyinkf flag from the original command line, FFmpeg just freezes and no video is captured - the frame count stays at zero.