Search code examples
videoffmpegrtmpflv

FLV Video packets sent over rtmp streamed with ffmpeg vs OBS


I'm using node-media-server npm module to host my rtmp server. I captured the video packets from the server and I noticed that video packets streamed with ffmpeg -f gdigrab -offset_x 1920 -framerate 60 -video_size hd1080 -i desktop -crf 0 -preset ultrafast -f flv rtmp://localhost starts with

  • 2200 0085 or
  • 2200 0084 and
  • 1200 0085, and
  • the very first packet starts with 1200 0084.

And when I stream to my rtmp server with OBS, I capture video packets that start with

  • 2701 0000 0000 00 and
  • the very first packet starts with 1701 0000 0000.

What I'm trying to do is that I capture these packets, store it, and send these packets to 'players' when they connect to my server. I got it working with the packets captured with ffmpeg AND video converted to flv format with ffmpeg.

However the players don't play the video packets streamed with OBS. However, the player does play well when my rtmp server is just 'relaying' what it receives instead of 'replaying' the captured packets. But the audio plays nicely.

I would like to know what those starting hexadecimals represent (whether it indicates that OBS is not using the flv file format).


Solution

  • (1)

    "...And when I stream to my RTMP server with OBS, I capture video packets that start with

    • 27 01 00 00 00 00 00 and

    • the very first packet starts with 17 01 00 00 00 00

    I would like to know what those starting hexadecimals represent (whether it indicates that OBS is not using the FLV file format)."

    Those byte values are correct for FLV format (see: "Video encoding" section under FLV Structure.

    Let's say packets begin with byte XY 01 00 00...

    • X is frame type... X == 1 for Keyframes (I-frame), and X == 2 for supporting P/B-frames.

    • Y is codec type... Y == 7 for codec H.264 (MPEG).

    You will notice that in your FFmpeg generated FLV the Y codec type is 2. By default FFmpeg outputs FLV with Sorenson Spark codec (which has low picture quality).

    To get FFmpeg to output H264 inside FLV use -c:v libx264, example:

    ffmpeg -f gdigrab -offset_x 1920 -framerate 60 -video_size hd1080 -i desktop -c:v libx264 -crf 0 -preset ultrafast -f flv rtmp://localhost
    


    (2)

    "However the players don't play the video packets streamed with OBS."

    I assume OBS means Open Broadcaster Software? Is there a way to provide a short sample output FLV file for analysis? Or else try to capture every byte (in order of appearance) sent by streaming process. If I'm a player/decoder what are the first 100+ bytes I receive from your RTMP link?

    Can you be sure that the FLV data sent to players contains correct data eg:

    Feeds into player/decoder...

    • an FLV header, followed by
    • A/V metadata (resolution, FPS, duration, etc).

    This should then be followed by (individual frames)...

    • (per frame) A/V tag setup that contains the video packets (eg: 09... until 27 01 00 00... etc).

    Basically make sure the FLV data is correct to work. What does player say about audio codec?

    Also is your audio sent in MP3 format? That's the only way I can imagine your "The audio plays nicely" since MP3 frames each have their own header and such data might be recognized among your bytes sent to the player (eg: player ignores unknown bytes but understands MP3 parts and so decodes that to your speakers). AAC audio sent with ADTS header might work too but an ADTS header should never be inside a media container (not FLV, MP4 or AVI).

    (3) I recommend you download a hex editor for your OS (if using Windows, try HxD).

    Compare bytes of both FLV files from FFmpeg vs OBS. Look for a typical structure like...
    (this is FLV header and metadata):

    46 4C 56 01 01 00 00 00 09 00 00 00 00 12 00 01     FLV............. 
    25 00 00 00 00 00 00 00 02 00 0A 6F 6E 4D 65 74     %..........onMet
    61 44 61 74 61 08 00 00 00 0C 00 08 64 75 72 61     aData.......dura
    74 69 6F 6E 00 40 46 D9 99 99 99 99 9A 00 05 77     tion.@FÙ™™™™š..w
    69 64 74 68 00 40 77 00 00 00 00 00 00 00 06 68     [email protected]
    65 69 67 68 74 00 40 75 00 00 00 00 00 00 00 0D     eight.@u........
    76 69 64 65 6F 64 61 74 61 72 61 74 65 00 40 8A     videodatarate.@Š
    0B F6 00 00 00 00 00 09 66 72 61 6D 65 72 61 74     .ö......framerat
    65 00 40 48 1A 20 84 C4 02 3E 00 0C 76 69 64 65     e.@H. „Ä.>..vide
    6F 63 6F 64 65 63 69 64 00 40 1C 00 00 00 00 00     ocodecid.@......
    

    And then an audio/video frame comes packed into an AV tag (data begins 09 if video, 08 if audio):

    09 XX XX XX XX XX XX 00 00 00 00 followed by frame data 27 01 00 00 XX 00 00 XX XX XX XX etc