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
or2200 0084
and1200 0085
, and1200 0084
.And when I stream to my rtmp server with OBS, I capture video packets that start with
2701 0000 0000 00
and1701 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).
(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
andthe 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...
This should then be followed by (individual frames)...
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