After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765549 - x265enc: problem with framerate=0/1 when re-encoding from rtp
x265enc: problem with framerate=0/1 when re-encoding from rtp
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.8.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-25 16:19 UTC by javiercubelos
Modified: 2018-11-03 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description javiercubelos 2016-04-25 16:19:23 UTC
Hello! 

I'm receiving a raw RTP stream as an input and I wanted to encode it and streaming it again through RTP.

I was using this command to do it encoding to h264 and it was working just great:

gst-launch-1.0 udpsrc port=9001 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)1280, height=(string)960, framerate=25/1, payload=(int)111" ! rtpvrawdepay ! x264enc bitrate=16384 ! rtph264pay ! udpsink host=127.0.0.1 port=1234

Now, i'm trying to encode to h265 and everything just stopped working. The command i'm using is:

gst-launch-1.0 udpsrc port=9001 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)4096, height=(string)2048, framerate=30/1, payload=(int)111" ! rtpvrawdepay ! x265enc bitrate=16384 ! rtph265pay ! udpsink host=127.0.0.1 port=1234

But now everything just stopped working and it returns:

"Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
/GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps = "application/x-rtp\,\ media\=\(string\)video\,\ clock-rate\=\(int\)90000\,\ encoding-name\=\(string\)RAW\,\ sampling\=\(string\)YCbCr-4:2:0\,\ depth\=\(string\)8\,\ width\=\(string\)4096\,\ height\=\(string\)2048\,\ framerate\=\(fraction\)30/1\,\ payload\=\(int\)111"
Setting pipeline to PLAYING ...
/GstPipeline:pipeline0/GstRtpVRawDepay:rtpvrawdepay0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)4096\,\ height\=\(int\)2048\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt709\,\ framerate\=\(fraction\)0/1"
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstX265Enc:x265enc0: Can not initialize x265 encoder.
Additional debug info:
gstx265enc.c(700): gst_x265_enc_init_encoder (): /GstPipeline:pipeline0/GstX265Enc:x265enc0
Execution ended after 0:00:00.000055373
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ..."

Everything looks okay appart the framerate that is set to 0 (variable). Do you have any idea of what could be happening? 

Thanks.
Comment 1 Tim-Philipp Müller 2016-04-30 15:09:37 UTC
The problem seems to be that the input framerate is 0/1 (variable frame rate).

x265 does not seem to support this yet: https://bitbucket.org/multicoreware/x265/issues/106/support-vfr

Not sure how to best handle this.

- if we disallow 0/1 as framerate than people will get link failures or not-negotiated later

- we could accept it but error out with an informative error message

- we could make the encoder base class normalise the input videorate-style, just like audioencoder does for audio input

- we could set some framerate like 50/60fps or so and hope things will still work well enough if we feed it fewer frames than that.
Comment 2 GStreamer system administrator 2018-11-03 13:49:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/381.