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 710948 - omxvideodec: Doesn't recover after aspect ratio changes
omxvideodec: Doesn't recover after aspect ratio changes
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-omx
1.2.4
Other Linux
: Normal normal
: 1.2.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 711288 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-27 00:25 UTC by m][sko
Modified: 2016-01-19 07:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description m][sko 2013-10-27 00:25:13 UTC
mpeg2 decoder don't recover after aspect ration changes

I attached file that you can use for repeat problem

as quick workaround I commented line with

is_format_change |= (self->codec_data != state->codec_data);
Comment 1 m][sko 2013-10-27 00:26:39 UTC
openmax on raspberry pi device
debian wheezy
Comment 2 Sebastian Dröge (slomo) 2013-10-30 18:25:17 UTC
Can you get a debug log with GST_DEBUG=omx*:6 and attach it here?
Comment 3 m][sko 2013-10-30 21:04:14 UTC
omx:9,omxvideodec:9
http://www.mdragon.org/problem2.log

test file
http://www.mdragon.org/problem.ts
Comment 4 Sebastian Dröge (slomo) 2013-11-11 18:05:30 UTC
*** Bug 711288 has been marked as a duplicate of this bug. ***
Comment 5 Sebastian Dröge (slomo) 2014-06-24 10:58:59 UTC
It fails for me with "Unsupported setting" all the time. Can you try latest GIT master of everything to see if it makes a difference for you?
Comment 6 Sebastian Dröge (slomo) 2014-06-24 11:20:32 UTC
Ah nevermind, my new RPi does not have the codec license keys yet. Bought and will retry when I got them.
Comment 7 Sebastian Dröge (slomo) 2014-06-24 11:43:21 UTC
This seems to be fixed by now with latest git master of everything. At least your sample clip just works for me.
Comment 8 m][sko 2014-06-30 21:42:31 UTC
try this test file
http://www.mdragon.org/test_ar_problem2.ts


GST_DEBUG="*:1,multifilesink:0,omxvideoenc:0,h264parse:4,mpegtsmux:0,omxvideodec:0" \
gst-launch-1.0 -v  uridecodebin uri="http://www.mdragon.org/test_ar_problem2.ts" use-buffering=false name=demux \
 ! "video/x-raw, format=I420" \
 ! omxh264enc target-bitrate=1000000 control-rate=1 inline-header=true periodicty-idr=250 interval-intraframes=250 ! "video/x-h264, profile=high" \
 ! h264parse ! "video/x-h264, alignment=au" \
 ! mpegtsmux name=mux0 \
 ! filesink location="test_ar_problem2_out.ts" sync=true \
 demux. ! "audio/x-raw" ! fakesink \
 2>&1


pipeline simple stop
Comment 9 Tim-Philipp Müller 2014-06-30 22:19:48 UTC
This bug was originally about the *decoder* not handling AR changes, now you have a convoluted test pipeline with encoder as well. Does the issue also happen with  gst-launch-1.0 -v uridecodebin uri=... ! fakesink silent=false ?
Comment 10 m][sko 2014-07-01 06:36:00 UTC
sorry
I will open another bug for encoder
Comment 11 Randeep 2016-01-19 05:26:04 UTC
Hi,

I need to use 'omxh264enc' gstreamer plugin to encode a video stream. When I gst-inspect, it is showing the plugin details correctly (libgstomx.so), but when i'm running it using a gstreamer pipeline i'm getting error as 'Could not initialize supporting library' and additional debug info as:
videoencoder.c (1428): gst_video_encoder_change_state (): Failed to open encoder.

    Is there any dependent library that we need to provide for this plugin to work ? Can you please help me with this issue.
Comment 12 Sebastian Dröge (slomo) 2016-01-19 07:48:16 UTC
Please file a new bug for that, and include a debug log in there. With GST_DEBUG=6 ideally.