search

ngraziano / SharpRTSP

A RTSP handling library
Other
557 stars 182 forks source link

h265payload question #83

Closed belveder79 closed 8 months ago

belveder79 commented 1 year ago

just another quick question concerning the H265Payload...

I stored the raw incoming packets (NALS, VPUs, etc.) to a raw .h265 file (and .aac for some more fun). The video is sent using ffmpeg with

ffmpeg -re -stream_loop -1 -i ~cat.mp4 -c:v libx265 -c:a aac -ar 44100 -b:a 128k -f rtsp rtsp://localhost:8554/live

and plays just nicely like that in VLC (no stuttering, no forth/back jumping of frames).

The code to write an mp4 file from the raw outcome is

ffmpeg -i out.h265 -i out.aac -c:v copy -c:a copy -f mp4 out.mp4

Looking at this video in Chrome, it stutters forth and back. While this might be due to Chrome not handling B-frames well, it is pretty similar in VLC. It stutters, but instead seems to drop frames... I know that the H265 does a lot of magic on the reordering of frames after decoding, but I guess there must be something missing (or off), if a plain copy of the received units creates bumpy videos.

Probably this happens also because we are streaming 25-30fps per sec, which means that the phenomenon just becomes visible there, and not for webcams with 5-10fps or so... however, I wanted to ask about your experience with the H265 payload parser and about the testing practice... probably I can fix it somehow...

RogerHardiman commented 1 year ago

Thanks for the question. I wonder if it is B-frames. When you made the x265 encoding from the cat video with libx265 there are extra flags you can add to ffmpeg to pass into libx265 to make only do I-Frames and P-Frames. They are called something like "presets" or "tune" A quick web search hinted at

ffmpeg -i test.avi -c:v libx265 -preset medium -x265-params crf=23:bframes=0 test_HEVC.mp4

The other thing to check is using SharpRTSP in TCP mode as SharpRTSP does not handle RTP packets being out of order on your LAN (ie UDP packets being out of order on the LAN if some network routing could cause one UDP packet to overtake another). Using RTP over RTSP (aka TCP mode) is fine as any out-of-order packet are handled in the OS TCP stack.

belveder79 commented 1 year ago

good hint... I did not really play around with the params or I/B/P frame settings... what I saw was that it is not an issue of TCP/UDP however, because it was doing the same thing regardless of the used protocol...

I ran the test again without B-frames and it works nicely - thx a lot...

RogerHardiman commented 1 year ago

glad it worked