"GStreamer" (GNOME Bugzilla)
2015-08-29 16:01:18 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=754291
Bug ID: 754291
Summary: Compositor fails with "reason not-negotiated" when
changing the pixel-aspect-ratio during runtime
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@mazdermind.de
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
Created attachment 310267
--> https://bugzilla.gnome.org/attachment.cgi?id=310267&action=edit
example program
The test-program attached to this bug contains a pipeline like this:
`
videotestsrc pattern=red !
video/x-raw,width=1920,height=1080,format=I420,framerate=25/1,pixel-aspect-ratio=1/1
!
videoscale !
capsfilter name=caps0 caps=video/x-raw !
mix.
compositor name=mix !
video/x-raw,width=1920,height=1080,format=I420,framerate=25/1,pixel-aspect-ratio=1/1
!
xvimagesink
`
The caps property of the capsfilter caps0 is, 1 second after the pipeline
starts, set to `video/x-raw,width=950,height=534`
Because the requested resolution 950:534 is not exactly 16:9 as the input, the
videoscaler will produce videoframes with a PAR of 1424/1425
`
video/x-raw, format=(string)I420, width=(int)950, height=(int)534,
framerate=(fraction)25/1, pixel-aspect-ratio=(fraction)1424/1425,
interlace-mode=(string)progressive
`
The compositor doesn't allow this change and terminates the pipeline.
Using videomixer instead of compositor does not show this behavior and forcing
a pixel-aspect-ratio of 1/1 between the videoscaler and the compositor also
fixes the issue.
What worries me is that this behavior was not visible in 1.5.1
Bug ID: 754291
Summary: Compositor fails with "reason not-negotiated" when
changing the pixel-aspect-ratio during runtime
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@mazdermind.de
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---
Created attachment 310267
--> https://bugzilla.gnome.org/attachment.cgi?id=310267&action=edit
example program
The test-program attached to this bug contains a pipeline like this:
`
videotestsrc pattern=red !
video/x-raw,width=1920,height=1080,format=I420,framerate=25/1,pixel-aspect-ratio=1/1
!
videoscale !
capsfilter name=caps0 caps=video/x-raw !
mix.
compositor name=mix !
video/x-raw,width=1920,height=1080,format=I420,framerate=25/1,pixel-aspect-ratio=1/1
!
xvimagesink
`
The caps property of the capsfilter caps0 is, 1 second after the pipeline
starts, set to `video/x-raw,width=950,height=534`
Because the requested resolution 950:534 is not exactly 16:9 as the input, the
videoscaler will produce videoframes with a PAR of 1424/1425
`
video/x-raw, format=(string)I420, width=(int)950, height=(int)534,
framerate=(fraction)25/1, pixel-aspect-ratio=(fraction)1424/1425,
interlace-mode=(string)progressive
`
The compositor doesn't allow this change and terminates the pipeline.
Using videomixer instead of compositor does not show this behavior and forcing
a pixel-aspect-ratio of 1/1 between the videoscaler and the compositor also
fixes the issue.
What worries me is that this behavior was not visible in 1.5.1
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.