Hi,
My question is about Jetson Tx2 encoder capabilities.
What is maximum video encoding resolution in pixels?
H.264@30
H.264@60
it is stated in the documentation that it supports 4K or 2160. Does it support higher resolution? E.g. 4096 x 2160 (which is also 4K and 2160) or higher? What is practicle maximum width? What is maximum height? Can we encode 7000 width (from multiple image sensors) x 1180 height which still be around 8MP resolution.
Best regards,
Alexey
Max width is 4096. Max height is 4096. 7000x1180 is not supported.
Hi,
On tx2 I encountered problem with resolution bigger than 2896x2896 :gstreamer pipeline with omxh264enc with 1 fps simply stucks( no calls for getting data callback and no bus call with GST_MESSAGE_STREAM_START).
Please note, that same code checked on tx1 and it works fine up to 4096x4096 resolution.
Do you have any suggestions, probably?
With best regards,
Max
Hi maxim,
We can run below pipeline without any issue:
$ gst-launch-1.0 videotestsrc num-buffers=30 is-live=true pattern=18 ! video/x-raw,width=2896,height=2896,framerate=1/1 ! nvvidconv ! omxh264enc ! qtmux ! filesink location=a.mp4
What is the pipeline you are running?
Hi,
When I run your pipeline as it is all works fine, but when i increase the resolution by one pixel - i got error. the output below:
gst-launch-1.0 videotestsrc num-buffers=30 is-live=true pattern=18 ! video/x-raw,width=2897,height=2897,framerate=1/1 ! nvvidconv ! omxh264enc ! qtmux ! filesink location=~/Desktop/download
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
Framerate set to : 1 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4
===== MSENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2948): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming task paused, reason error (-5)
Execution ended after 0:00:00.128485088
Setting pipeline to PAUSED …
Setting pipeline to READY …
Setting pipeline to NULL …
Freeing pipeline …
As you can see the trouble exist. I trying to figure out what can cause this. As i wrote before, tx1 and tx2 behave different(on tx2 installed jetpack 3.2, so next thing is install it on tx1 and test)
Please note that on tx1 the pipeline does not produce errors with any resolution
HW does not support odd-value width and height. It is a bit surprising odd value s work on TX1.
Can you set even values to width and height?have to be 16 pixel alignment.
Ok, i tested with 2896x2896 and 2898x2898 on tx2 and behavior is different in:
2896x2896 working well, exit nicely with ^C, produces output file some about 35kB after 12 sec of run
2898x2898 seems like working, does not exit after ^C(stucks at exit flow), produces empty output file
the output of 2896x2896 run :
$ GST_DEBUG=3 gst-launch-1.0 videotestsrc num-buffers=30 is-live=true pattern=18 ! video/x-raw,width=2896,height=2896,framerate=1/1 ! nvvidconv ! omxh264enc ! qtmux ! filesink location=~/Desktop/download
0:00:00.029105708 9364 0x4f2560 WARN omx gstomx.c:2826:plugin_init: Failed to load configuration file: Valid key file could not be found in search dirs (searched in: /home/ubuntu/.config:/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg as per GST_OMX_CONFIG_DIR environment variable, the xdg user config directory (or XDG_CONFIG_HOME) and the system config directory (or XDG_CONFIG_DIRS)
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
0:00:00.053506634 9364 0x53a9e0 FIXME default gstutils.c:3766:gst_pad_create_stream_id_internal:videotestsrc0:src Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Setting pipeline to PLAYING …
New clock: GstSystemClock
0:00:00.054737798 9364 0x53a9e0 FIXME videoencoder gstvideoencoder.c:606:gst_video_encoder_setcaps: GstVideoEncoder::reset() is deprecated
Framerate set to : 1 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4
===== MSENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
0:00:00.055760353 9364 0x53a9e0 WARN omxvideoenc gstomxvideoenc.c:1860:gst_omx_video_enc_set_format: Error setting temporal_tradeoff 0 : Vendor specific error (0x00000001)
NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
===== MSENC blits (mode: 1) into tiled surfaces =====
0:00:00.207208709 9364 0x7f78003450 WARN qtmux gstqtmux.c:3951:gst_qt_mux_video_sink_set_caps: no codec_data in h264 caps
0:00:00.207247557 9364 0x7f78003450 WARN qtmux gstqtmux.c:4116:gst_qt_mux_video_sink_set_caps: pad video_0 refused caps video/x-h264, alignment=(string)au, profile=(string)baseline, level=(string)4, stream-format=(string)avc, width=(int)2896, height=(int)2896, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)1/1
0:00:00.207349829 9364 0x7f78003450 WARN qtmux gstqtmux.c:3951:gst_qt_mux_video_sink_set_caps: no codec_data in h264 caps
0:00:00.207369445 9364 0x7f78003450 WARN qtmux gstqtmux.c:4116:gst_qt_mux_video_sink_set_caps: pad video_0 refused caps video/x-h264, alignment=(string)au, profile=(string)baseline, level=(string)4, stream-format=(string)avc, width=(int)2896, height=(int)2896, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)1/1
0:00:00.207401188 9364 0x7f78003450 WARN GST_PADS gstpad.c:4092:gst_pad_peer_query:omxh264enc-omxh264enc0:src could not send sticky events
0:00:00.207895586 9364 0x7f78003450 FIXME basesink gstbasesink.c:3126:gst_base_sink_default_event: stream-start event without group-id. Consider implementing group-id handling in the upstream elements
^Chandling interrupt.
Interrupt: Stopping pipeline …
Execution ended after 0:00:26.125301487
Setting pipeline to PAUSED …
Setting pipeline to READY …
Setting pipeline to NULL …
Freeing pipeline …
the output of 2898x2898 run :
GST_DEBUG=3 gst-launch-1.0 videotestsrc num-buffers=30 is-live=true pattern=18 ! video/x-raw,width=2898,height=2898,framerate=1/1 ! nvvidconv ! omxh264enc ! qtmux ! filesink location=~/Desktop/download
0:00:00.028867980 9385 0x4f2560 WARN omx gstomx.c:2826:plugin_init: Failed to load configuration file: Valid key file could not be found in search dirs (searched in: /home/ubuntu/.config:/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg as per GST_OMX_CONFIG_DIR environment variable, the xdg user config directory (or XDG_CONFIG_HOME) and the system config directory (or XDG_CONFIG_DIRS)
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
0:00:00.061618346 9385 0x53a9e0 FIXME default gstutils.c:3766:gst_pad_create_stream_id_internal:videotestsrc0:src Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Setting pipeline to PLAYING …
New clock: GstSystemClock
0:00:00.062950628 9385 0x53a9e0 FIXME videoencoder gstvideoencoder.c:606:gst_video_encoder_setcaps: GstVideoEncoder::reset() is deprecated
Framerate set to : 1 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4
===== MSENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
0:00:00.064155744 9385 0x53a9e0 WARN omxvideoenc gstomxvideoenc.c:1860:gst_omx_video_enc_set_format: Error setting temporal_tradeoff 0 : Vendor specific error (0x00000001)
NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
NvH264MSEncSetCommonStreamAttribute: LevelIdc conformance violation
===== MSENC blits (mode: 1) into tiled surfaces =====
^Chandling interrupt.
Interrupt: Stopping pipeline …
Execution ended after 0:00:18.797352005
Setting pipeline to PAUSED …
Setting pipeline to READY …
^C
Ok, I made fresh install of jetpack3 on tx1 and runs the same test and got the same result.
So it doesn’t matter tx1 or tx2. The reason is jetpack3, try it by yourself, please.
In my program i got the same behavior, with big resolution the whole pipeline stuck after changing state to playing without producing any errors. Also the source cup is stuck at destruction flow - changing state gst_element_set_state(appsrc, NULL).
with best regards. Max
The width and height have to be 16 pixel alignment, not only even values. Please ignore previous comment.
What is the revision of Jetpack? OK on 2.3.1 and NG 3.2? What is the resolution?
Other posts about alignment:
https://devtalk.nvidia.com/default/topic/1022415/jetson-tx2/gstvideoencode-not-working/post/5204286/#5204286
https://devtalk.nvidia.com/default/topic/1023050/jetson-tk1/nvvidconv-issue-when-transform-non-standard-video/post/5205513/#5205513
and a sample verified on r28.2/TX2
$ g++ -Wall -std=c++11 a.cpp -o test $(pkg-config --cflags --libs gstreamer-app-1.0) -ldl
$ gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw,format=I420,width=2896,height=2896 ! filesink location=a.yuv
$ ./test
$ gst-launch-1.0 filesrc location= a.mp4 ! qtdemux ! h264parse ! omxh264dec ! nvvidconv ! 'video/x-raw(memory:NVMM),width=1024,height=1024' ! nvoverlaysink
a.cpp (2.59 KB)
Hi there, with 2896 resolution is always worked, please try to verify it with 2912x2912 resolution(next value alignment), but will be better if you, please, will verify it with 4096x4096, because this is an issue i trying to describe(our working resolution that was supported with JP 2.4)
the problem version is JetPackL4T_32_b196
i will try to express it in other way:
_________2896x2896__________4096x4096
JP 3.2_______ok_______________not ok
JP 2.4 ______ok_______________ok
once you can verify the case with “not ok”, we can go further.
PS I runs it with another resolution from attached post, and it seems to be ok with “standart” resolution like 3840x2160, but not ok with any another, like 3840x3840(each of them are aligned to 32 pixels)
wbr, Max
Please configure ‘level’:
$ gst-launch-1.0 videotestsrc num-buffers=30 is-live=true ! 'video/x-raw,width=4096,height=4096,framerate=1/1' ! nvvidconv ! omxh264enc ! 'video/x-h264,<b>level=(string)5</b>' ! qtmux ! filesink location= a.mp4
Yes, it works.
Thank you.
So the difference between JetPacks is some default gstreamer values of capsfilter?
With best regards, Max
Hi DaneLLL,
You said,
> The width and height have to be 16 pixel alignment, not only even values.
Is this limitation for only GStreamer ? Or for both GStreamer and MMAPI ?
H.264 coding rule has limitation, I know.
Then 1080P video will encode as a stream of 1088P, and decoder will crop it (after decoding).
CANNOT we use 1920x1080 resolution ?
** 1080 = (3 x 3 x 3 x 5)x 8, 1088 = (17 x 4)x 16
(About buffer creation and converter setting)
Best Regards,
Hi mynaemi,
1920x1080 is standard resolution so it is well handled. For other arbitrary WidthxHeight it is better to follow the rule.
I’m just adding this here in case it’s helpful to someone else. My experiments with h265 encoding on the Jetson Nano seem to show that it’s not sufficient to have number of pixels divisible by 16 and height and width even. It seems that both height and width have to be divisible by 4 for it to work.