FullHD stream

[ihora]

Hello,

could anyone advice me how to stream FullHD stream over UDP from Raspicam V2? I am using following pipeline, but the video is always cropped and not FULLHD: rpicamsrc preview=false !video/x-raw, width=1920,height=1080,framerate=24/1 ! clockoverlay ! omxh264enc target-bitrate=1000000 control-rate=variable ! video/x-h264,width=1280, height=720, framerate=30/1, profile=(string)high ! h264parse ! rtph264pay name=pay0 pt=96

I tried to change the caps to obtain video/x-h264 directly from rpicamsrc without explicitly using omx codec, but I face the same problem. There is not problem obtaining FULLHD video via raspivid application, but I need to transfer the stream over UDP and piping RASPIVID to gstreamer is of no use for I am using gst-rtsp-server and I don't think the pipeline could be assembled in such a way it allows external program to feed stream to gstreamer

Thank you Best regards, Ivo

[thaytan]

I don't understand your problem. The pipeline you have above won't run - you can't feed 1920x1080 24fps video into omxh264enc and then ask it to encode 720p 30fps output - it'll just fail.

A fixed pipeline reports 1080p encoding as expected, and the same if I just let rpicamsrc do the encode directly (which uses less CPU because the raw video is not transferred to system memory before encoding):

gst-launch-1.0 rpicamsrc preview=false ! video/x-raw, width=1920,height=1080,framerate=24/1 ! clockoverlay ! omxh264enc target-bitrate=1000000 control-rate=variable ! 'video/x-h264,profile=(string)high' ! h264parse ! rtph264pay name=pay0 pt=96 ! fakesink -v

/GstPipeline:pipeline0/GstRtpH264Pay:pay0.GstPad:sink: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, profile=(string)high, level=(string)4, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)24/1, parsed=(boolean)true, codec_data=(buffer)01640028ffe1001027640028ac2b403c0113f2c03c489a8001000528ee01372c

Can you define what you mean by 'cropped'?

[ihora]

Dear sir thank you very much,by cropping I mean reduced field of view for 1080p compared to 720p,I want to achieve the same result as when using 1080p with raspivid. I am sorry,I left the 1280x720 in the pipeline by accident,the same resolution(720p) was before requested from rpicamsrc also,I should have changed resolution of both elements. I am requesting raw because of clockoverlay element or do you think there is another way how to pass h264 through clockoverlay instead of raw?

On 8/28/18, Jan Schmidt [email protected] wrote:

I don't understand your problem. The pipeline you have above won't run - you can't feed 1920x1080 24fps video into omxh264enc and then ask it to encode 720p 30fps output - it'll just fail.

A fixed pipeline reports 1080p encoding as expected, and the same if I just let rpicamsrc do the encode directly (which uses less CPU because the raw video is not transferred to system memory before encoding):

gst-launch-1.0 rpicamsrc preview=false ! video/x-raw, width=1920,height=1080,framerate=24/1 ! clockoverlay ! omxh264enc target-bitrate=1000000 control-rate=variable ! 'video/x-h264,profile=(string)high' ! h264parse ! rtph264pay name=pay0 pt=96 ! fakesink -v

/GstPipeline:pipeline0/GstRtpH264Pay:pay0.GstPad:sink: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, profile=(string)high, level=(string)4, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)24/1, parsed=(boolean)true, codec_data=(buffer)01640028ffe1001027640028ac2b403c0113f2c03c489a8001000528ee01372c

Can you define what you mean by 'cropped'?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/thaytan/gst-rpicamsrc/issues/82#issuecomment-416685335

[thaytan]

I don't know why you'd get reduced FoV for 1920x1080 vs 1280x720. Probably something to do with how the driver selects the sensor / binning mode and then crops out a suitable ROI for encoding.

You are correct - you can't draw a clock-overlay onto H.264, you have to do it in raw. You can use the overlay features of the hardware encoder to draw a clock with something like 'rpicamsrc annotation-mode=date/time' if the result meets your needs - or you can write code and set custom annotation text

[ihora]

Thank you,I did not notice the annotation,you are also fully right with the fullHD,seems like it's not so easy to achieve.

On 9/3/18, Jan Schmidt [email protected] wrote:

I don't know why you'd get reduced FoV for 1920x1080 vs 1280x720. Probably something to do with how the driver selects the sensor / binning mode and then crops out a suitable ROI for encoding.

You are correct - you can't draw a clock-overlay onto H.264, you have to do it in raw. You can use the overlay features of the hardware encoder to draw a clock with something like 'rpicamsrc annotation-mode=date/time' if the result meets your needs - or you can write code and set custom annotation text

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/thaytan/gst-rpicamsrc/issues/82#issuecomment-417963532

[nopmop]

A matrix of FoV <---> resolutions values is available here for RPi Cam v1 & v2:

https://picamera.readthedocs.io/en/release-1.12/fov.html