gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:33:06Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/229vtenc: eliminate gst_video_frame_copy on iOS in non-CVPixelBuffer case2021-09-24T14:33:06ZBugzilla Migration Uservtenc: eliminate gst_video_frame_copy on iOS in non-CVPixelBuffer case## Submitted by Ilya Konstantinov
**[Link to original bug (#747222)](https://bugzilla.gnome.org/show_bug.cgi?id=747222)**
## Description
In gst_vtenc_encode_frame, we do:
meta = gst_buffer_get_core_media_meta (frame->input_...## Submitted by Ilya Konstantinov
**[Link to original bug (#747222)](https://bugzilla.gnome.org/show_bug.cgi?id=747222)**
## Description
In gst_vtenc_encode_frame, we do:
meta = gst_buffer_get_core_media_meta (frame->input_buffer);
if (meta != NULL) {
pbuf = gst_core_media_buffer_get_pixel_buffer (frame->input_buffer);
}
#ifdef HAVE_IOS
if (pbuf == NULL) {
...
/* FIXME: iOS has special stride requirements that we don't know yet.
* Copy into a newly allocated pixelbuffer for now. Probably makes
* sense to create a buffer pool around these at some point.
*/
...
if (!gst_video_frame_copy (&outframe, &inframe)) {
...
The gst_video_frame_copy is a performance issue.
---
Case in point, in OpenWebRTC we have avfvideosrc upstream, so the pixel layout should be Apple-compatible. The need for this gst_video_frame_copy should be reevaluated.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/230avfvideosrc: BUFFER_QUEUE_SIZE too small2021-09-24T14:33:07ZBugzilla Migration Useravfvideosrc: BUFFER_QUEUE_SIZE too small## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#747270)](https://bugzilla.gnome.org/show_bug.cgi?id=747270)**
## Description
In avfvideosrc.m, we have:
#define BUFFER_QUEUE_SIZE...## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#747270)](https://bugzilla.gnome.org/show_bug.cgi?id=747270)**
## Description
In avfvideosrc.m, we have:
#define BUFFER_QUEUE_SIZE 2
This buffer queue is used in a producer-consumer fashion between the AV capture callbacks (on AVFoundation's thread) and the element (on the main thread).
With such a small queue, we were constantly:
a) losing performance due to the main thread going to sleep constantly
b) periodically dropping frames in this code:
if ([bufQueue count] == BUFFER_QUEUE_SIZE)
[bufQueue removeLastObject];
Increasing the queue size to e.g. 32 improves performance significantly. On iPhone 5s, improvement of` ~7`% is seen in the following pipeline:
avfvideosrc device-index=0 ! video/x-raw,width=1280,height=720,framerate=30/1 ! vtenc_h264 bitrate=400 ! fakesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/231avfvideosrc: orientation property2021-09-24T14:33:08ZBugzilla Migration Useravfvideosrc: orientation property## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#747378)](https://bugzilla.gnome.org/show_bug.cgi?id=747378)**
## Description
Adding orientation property.
According to docs:
http...## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#747378)](https://bugzilla.gnome.org/show_bug.cgi?id=747378)**
## Description
Adding orientation property.
According to docs:
https://developer.apple.com/library/ios/qa/qa1744/_index.html
"Clients may receive physically rotated CVPixelBuffers in their AVCaptureVideoDataOutput -captureOutput:didOutputSampleBuffer:fromConnection: delegate callback. All 4 AVCaptureVideoOrientation modes are supported, and rotation is hardware accelerated."https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/232tsdemux: lacks locking in the seeking code2021-09-24T14:33:08ZBugzilla Migration Usertsdemux: lacks locking in the seeking code## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#747442)](https://bugzilla.gnome.org/show_bug.cgi?id=747442)**
## Description
+++ This bug was initially created as a clone of [Bug 735100](https://bugzilla.gnom...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#747442)](https://bugzilla.gnome.org/show_bug.cgi?id=747442)**
## Description
+++ This bug was initially created as a clone of [Bug 735100](https://bugzilla.gnome.org/show_bug.cgi?id=735100) +++
Comment from ocrete in the original bug:
Not specific to this patch, but it seems the whole tsdemux has no locking at all in the seeking code, so we shouldn't be surprised if seeking sometimes exhibits random behaviours...
### Depends on
* [Bug 735100](https://bugzilla.gnome.org/show_bug.cgi?id=735100)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/233tsparse: doesn't output aligned ts packets (streaming from file to vlc doesn'...2021-09-24T14:33:09ZBugzilla Migration Usertsparse: doesn't output aligned ts packets (streaming from file to vlc doesn't recover on unaligned ts)## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#747457)](https://bugzilla.gnome.org/show_bug.cgi?id=747457)**
## Description
i've observed that i couldn't stream certain ts files from gst-rtsp-server to vlc (gst...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#747457)](https://bugzilla.gnome.org/show_bug.cgi?id=747457)**
## Description
i've observed that i couldn't stream certain ts files from gst-rtsp-server to vlc (gstreamer as a client works) so i digged a bit and found out that the trigger for the issue were random bytes before the first ts packet
this is easily reproducable:
just prepend a few bytes before a valid, working ts file
printf "blafaselfoobar1234567890abcdefghijk" | cat - streamtest.ts > streamtest-broken.ts
start gst-rtsp-server
test-launch "( filesrc location=streamtest-broken.ts ! tsparse set-timestamps=true ! queue ! rtpmp2tpay name=pay0 pt=96 )"
playback with vlchttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/234avfvideosrc: GLMemory should be preferred caps2021-09-24T14:33:09ZBugzilla Migration Useravfvideosrc: GLMemory should be preferred caps## Submitted by Ilya Konstantinov
**[Link to original bug (#747519)](https://bugzilla.gnome.org/show_bug.cgi?id=747519)**
## Description
GLMemory allows higher performance than SystemMemory and should be placed higher.
* avfvid...## Submitted by Ilya Konstantinov
**[Link to original bug (#747519)](https://bugzilla.gnome.org/show_bug.cgi?id=747519)**
## Description
GLMemory allows higher performance than SystemMemory and should be placed higher.
* avfvideosrc ! glimagesink will have high performance out-of-the-box, conforming to user expectation
* Bugs like 747352 will be detected earlier
### Depends on
* [Bug 747352](https://bugzilla.gnome.org/show_bug.cgi?id=747352)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/236gsthlsdemux.c/gstadaptivedemux.c: Possible Improvement: Variant selection doe...2021-09-24T14:33:12ZBugzilla Migration Usergsthlsdemux.c/gstadaptivedemux.c: Possible Improvement: Variant selection doesn't consider hysteresis## Submitted by David Guthrie
**[Link to original bug (#747558)](https://bugzilla.gnome.org/show_bug.cgi?id=747558)**
## Description
When the average bitrate is calculated, this resultant bitrate (when multiplied by bitrate_limit) c...## Submitted by David Guthrie
**[Link to original bug (#747558)](https://bugzilla.gnome.org/show_bug.cgi?id=747558)**
## Description
When the average bitrate is calculated, this resultant bitrate (when multiplied by bitrate_limit) could be very close to a variant in the m3u8 playlist file. Which could result in the variant selection oscillating between two different variants after each segment is downloaded. In any system which make a decision based on an input switching an output based on the inputs magnitude, it is normal to add hysteresis to the calculation as this will prevent random noise from causing instability. The instability in this cause would be the viewer being able to observe frequent changes in variants when playing back video.
A hysteresis variable could be added to the final bitrate value used to select the variant from the playlist. This variable is set to -50kbps when changing download a variant and set to 0 when changing up a variant. This would allow for 50kbps of noise in the final bitrate calculation which would not influence the variant selection when the download rate is near constant.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/238applemedia: expose GstCoreMediaMeta to app2021-09-24T14:33:12ZBugzilla Migration Userapplemedia: expose GstCoreMediaMeta to app## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#747707)](https://bugzilla.gnome.org/show_bug.cgi?id=747707)**
## Description
An OS X and iOS app might use appsink to get resulting GstB...## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#747707)](https://bugzilla.gnome.org/show_bug.cgi?id=747707)**
## Description
An OS X and iOS app might use appsink to get resulting GstBuffers from a pipeline containing applemedia elements. Furthermore, it can wish to access (and retain) the underlying CMSampleBufferRef or CMPixelBufferRef, as they're needed:
1) to work with AVFoundation, Core Video and Core Image
2) for GL rendering done by app
How can we expose some of the applemedia stuff (e.g. coremediabuffer.h) as API?
### Depends on
* [Bug 747216](https://bugzilla.gnome.org/show_bug.cgi?id=747216)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/239opencv: make cascades relocatable on win322021-09-24T14:33:13ZBugzilla Migration Useropencv: make cascades relocatable on win32## Submitted by LRN
**[Link to original bug (#747711)](https://bugzilla.gnome.org/show_bug.cgi?id=747711)**
## Description
Default cascade paths are hardcoded as:
OPENCV_PREFIX + PATH_TO_CASCADE
where OPENCV_PREFIX is obta...## Submitted by LRN
**[Link to original bug (#747711)](https://bugzilla.gnome.org/show_bug.cgi?id=747711)**
## Description
Default cascade paths are hardcoded as:
OPENCV_PREFIX + PATH_TO_CASCADE
where OPENCV_PREFIX is obtained by pkg-conifg from opencv.pc
First problem is that w32 pkg-config by default gets a DOS version
of OPENCV_PREFIX, so the resulting cascade path is:
A) Absolute
B) DOS
This can be fixed by passing --dont-define-prefix to pkg-config
(a trick well-known to anyone who builds anything with MinGW/MSYS),
which makes it output prefix that starts with '/' (usually '/mingw').
So now cascade path is:
A) Absolute
B) POSIX
Which fixes nothing, since Windows does not understand POSIX paths.
However, in this case some code and path wizardry can fix the situation
(see the patch attached).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/240h264parser/h264parse: Handle trailing 0s in NALU2021-09-24T14:33:13ZBugzilla Migration Userh264parser/h264parse: Handle trailing 0s in NALU## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#747850)](https://bugzilla.gnome.org/show_bug.cgi?id=747850)**
## Description
the H264 spec allows to have leading/traling zeros in byte stream
The problem is th...## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#747850)](https://bugzilla.gnome.org/show_bug.cgi?id=747850)**
## Description
the H264 spec allows to have leading/traling zeros in byte stream
The problem is that we don't know about it, and therefore we iterating over
NALU we are never guaranteed to end at the next NALU start code, but instead
on potentially trailing zero bytes
This would cause h264parse to tell baseparse to skip those few bytes, resulting
in the next buffer being a DISCONT one ... whereas it's not.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/242mpegtsmux: Need set right pid if pid is 0 when create streams.2021-09-24T14:33:14ZBugzilla Migration Usermpegtsmux: Need set right pid if pid is 0 when create streams.## Submitted by kevin
**[Link to original bug (#748288)](https://bugzilla.gnome.org/show_bug.cgi?id=748288)**
## Description
when camerabin use mpegtsmux as muxer, start video recording and then stop video recording and then start v...## Submitted by kevin
**[Link to original bug (#748288)](https://bugzilla.gnome.org/show_bug.cgi?id=748288)**
## Description
when camerabin use mpegtsmux as muxer, start video recording and then stop video recording and then start video recording, mpegtsmux get wrong pid. Attached patch to fix the issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/243vtdec: strange error handling2021-09-24T14:33:15ZBugzilla Migration Uservtdec: strange error handling## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#748439)](https://bugzilla.gnome.org/show_bug.cgi?id=748439)**
## Description
In gst_vtdec_handle_frame:
status =
VTDecomp...## Submitted by Ilya Konstantinov
Assigned to **Ilya Konstantinov**
**[Link to original bug (#748439)](https://bugzilla.gnome.org/show_bug.cgi?id=748439)**
## Description
In gst_vtdec_handle_frame:
status =
VTDecompressionSessionDecodeFrame (vtdec->session, cm_sample_buffer,
input_flags, frame, NULL);
if (status != noErr && FALSE)
goto error;
I guess the "&& FALSE" is debug-time code that sneaked into the commit. Introduced in:
commit b1a756fda730d5edde0d6d83df723d8923008f98
Author: Alessandro Decina <alessandro.d@gmail.com>
Date: Sat Dec 7 23:55:13 2013 +0100
applemedia: rewrite VideoToolbox decoder based on GstVideoDecoderhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/244vtenc: support VT buffer pool2021-09-24T14:33:15ZBugzilla Migration Uservtenc: support VT buffer pool## Submitted by Ilya Konstantinov
**[Link to original bug (#748503)](https://bugzilla.gnome.org/show_bug.cgi?id=748503)**
## Description
VT provides VTCompressionSessionGetPixelBufferPool to get a CVPixelBufferPool. Using CVPixelBuf...## Submitted by Ilya Konstantinov
**[Link to original bug (#748503)](https://bugzilla.gnome.org/show_bug.cgi?id=748503)**
## Description
VT provides VTCompressionSessionGetPixelBufferPool to get a CVPixelBufferPool. Using CVPixelBuffers from this pool will avoid memcpy into hardware buffers.
For this, we should implement:
1) GstCoreVideoMemory ([bug 747216](https://bugzilla.gnome.org/show_bug.cgi?id=747216))
2) GstCoreVideoBufferPool extending GstBufferPool with a custom alloc_buffer
3) vtenc's propose_allocation with a single GstCoreVideoBufferPool allocation pool
### Depends on
* [Bug 747216](https://bugzilla.gnome.org/show_bug.cgi?id=747216)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/245codecparsers_h265: fails (core dump) to parse h265 sample2021-09-24T14:33:16ZBugzilla Migration Usercodecparsers_h265: fails (core dump) to parse h265 sample## Submitted by Athanasios Oikonomou
**[Link to original bug (#748641)](https://bugzilla.gnome.org/show_bug.cgi?id=748641)**
## Description
Hi,
I get the following error when trying to play h256 file.
root@dm800se:/var/vo...## Submitted by Athanasios Oikonomou
**[Link to original bug (#748641)](https://bugzilla.gnome.org/show_bug.cgi?id=748641)**
## Description
Hi,
I get the following error when trying to play h256 file.
root@dm800se:/var/volatile/tmp# GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:3 gst-launch-1.0 -v playbin uri=file:///media/usb/1/140626_720p_hm130_4s_sao_dbf_qp27.265.mkv
Setting pipeline to PAUSED ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: use-buffering = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: download = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: uri = file:///media/usb/1/140626_720p_hm130_4s_sao_dbf_qp27.265.mkv
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: connection-speed = 0
0:00:00.227617000 579 0x649780 WARN basesrc gstbasesrc.c:3481:gst_base_src_start_complete:`<source>` pad not activated yet
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: source = "\(GstFileSrc\)\ source"
0:00:00.237162296 579 0x649780 WARN basesrc gstbasesrc.c:3481:gst_base_src_start_complete:`<source>` pad not activated yet
Pipeline is PREROLLING ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = "NULL"
0:00:00.599147963 579 0x76142200 WARN codecparsers_h265 gsth265parser.c:1824:gst_h265_parse_pps: value not in allowed range. value: 0, range 1-19
0:00:00.599541963 579 0x76142200 WARN codecparsers_h265 gsth265parser.c:1869:gst_h265_parse_pps: error parsing "Picture parameter set"
0:00:00.599739963 579 0x76142200 WARN h265parse gsth265parse.c:562:gst_h265_parse_process_nal:`<h265parse0>` failed to parse PPS:
0:00:00.600066519 579 0x76142200 WARN codecparsers_h265 gsth265parser.c:1951:gst_h265_parser_parse_slice_hdr: couldn't find associated picture parameter set with id: 0
*** Error in `gst-launch-1.0': free(): invalid pointer: 0x75365d34 ***
Aborted (core dumped)
Above error is happening on Enigma2 STB using latest HEAD (compiled using openembedded few minutes ago).
Currently there is no Enigma2 STB that supports h265 and there is no video sink that has h265 caps.
Here you can find above sample http://www.elecard.com/assets/files/other/clips/140626_720p_hm130_4s_sao_dbf_qp27.265https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/247compositor: only paint background if actually needed2021-09-24T14:33:17ZBugzilla Migration Usercompositor: only paint background if actually needed## Submitted by Tim Müller `@tpm`
**[Link to original bug (#748748)](https://bugzilla.gnome.org/show_bug.cgi?id=748748)**
## Description
+++ This bug was initially created as a clone of [Bug 746147](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#748748)](https://bugzilla.gnome.org/show_bug.cgi?id=748748)**
## Description
+++ This bug was initially created as a clone of [Bug 746147](https://bugzilla.gnome.org/show_bug.cgi?id=746147) +++
Subject says it all.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/248opencv: cvequalizehist: add color support2021-09-24T14:33:17ZBugzilla Migration Useropencv: cvequalizehist: add color support## Submitted by ji0..@..ng.com
**[Link to original bug (#748858)](https://bugzilla.gnome.org/show_bug.cgi?id=748858)**
## Description
Created attachment 302826
patch for extending an input format
The original "cvequalizehist"...## Submitted by ji0..@..ng.com
**[Link to original bug (#748858)](https://bugzilla.gnome.org/show_bug.cgi?id=748858)**
## Description
Created attachment 302826
patch for extending an input format
The original "cvequalizehist" element only accepts a grayscale image as an input.
However, the most images users want to handle are colored images.
I extended its input format from grayscale to colored.
Please find the attached patch.
This patch was modified from d4703fa8806cf7d9cc778fb43370daebb37e70cd,
and you can check it using the following command.
gst-launch-1.0 videotestsrc pattern=13 ! tee name=t t. ! queue ! videoconvert ! xvimagesink t. ! queue ! cvequalizehist ! videoconvert ! xvimagesink
Thank you.
~~**Patch 302826**~~, "patch for extending an input format":
[equalize_hist_colored_image.diff](/uploads/24e22080239429ac3943015ba2c5b018/equalize_hist_colored_image.diff)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/249videofilters: Add plugin for pseudo-color effect2021-09-24T14:33:18ZBugzilla Migration Uservideofilters: Add plugin for pseudo-color effect## Submitted by RaviKiran
**[Link to original bug (#748994)](https://bugzilla.gnome.org/show_bug.cgi?id=748994)**
## Description
Add a new plugin for pseudo-color effect.
http://en.wikipedia.org/wiki/False_color#Pseudocolor
T...## Submitted by RaviKiran
**[Link to original bug (#748994)](https://bugzilla.gnome.org/show_bug.cgi?id=748994)**
## Description
Add a new plugin for pseudo-color effect.
http://en.wikipedia.org/wiki/False_color#Pseudocolor
This plugin takes Gray scale image as input and adds color to it based on hue, saturation properties (HSL to RGB). And produces RGB output.
Although videobalance element can adjust hue/saturation of an image, it doesn't add color to a gray scale image.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/250hlsdemux: set uri handler blocksize to reduce CPU usage2021-09-24T14:33:18ZBugzilla Migration Userhlsdemux: set uri handler blocksize to reduce CPU usage## Submitted by Duncan Palmer
**[Link to original bug (#749090)](https://bugzilla.gnome.org/show_bug.cgi?id=749090)**
## Description
When streaming some encrypted HD content (bitrate about 7 Mbps) using HLS demux, I found CPU usage ...## Submitted by Duncan Palmer
**[Link to original bug (#749090)](https://bugzilla.gnome.org/show_bug.cgi?id=749090)**
## Description
When streaming some encrypted HD content (bitrate about 7 Mbps) using HLS demux, I found CPU usage was hitting 100% on my embedded processor (a Sigma SMP8674). An unencrypted version of the same content was using 47% of the CPU.
A bit of digging shows that is because of the default 4K blocksize used by souphttpsrc. Increasing this to 64K reduced CPU usage to 47% for the encrypted stream, and 27% for the clear stream.
The solution I've implemented is to modify hlsdemux to set the blocksize property on it's uri_handler.
The value set for blocksize is calculated from the bitrate of the current variant, to ensure we can fill a block in 125ms (which seems like a nice low number to me - this shouldn't introduce too much jitter into the pipeline). I set a lower blocksize limit of 4K (as used by gstbasesrc), and a higher limit of 64K. Testing with both clear and encrypted versions of my test stream shows no improvement once blocksize is increased beyond 64K. Block sizes are incremented in 4K steps.
With this algorithm, all variants below 262144 bps use a 4K blocksize, and above 4194304 bps use a 64K blocksize.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/251vtdec_hw attempts to play back 422-encoded h2642021-09-24T14:33:19ZBugzilla Migration Uservtdec_hw attempts to play back 422-encoded h264## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#749226)](https://bugzilla.gnome.org/show_bug.cgi?id=749226)**
## Description
When trying to play back 422-encoded h264, vtdec_hw still tries to decode the stre...## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#749226)](https://bugzilla.gnome.org/show_bug.cgi?id=749226)**
## Description
When trying to play back 422-encoded h264, vtdec_hw still tries to decode the stream, even though the HW decoder is only able to decode 420. This results in corrupt images since the stream is interpreted as 420.
There are a few things that can be done:
* Make sure to also pass on the pixel format in gst_vtdec_set_format
* Use CMVideoFormatDescriptionCreateFromH264ParameterSets to get the correct description (works when stream-format=avc, should be available in codec_data in caps). I guess this should be the preferred way.
A sample 422-encoded file is attached.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/252rsndvdsrc: please tell me if my drive's region code is not yet set2021-09-24T14:33:19ZBugzilla Migration Userrsndvdsrc: please tell me if my drive's region code is not yet set## Submitted by Fabian Greffrath
**[Link to original bug (#749229)](https://bugzilla.gnome.org/show_bug.cgi?id=749229)**
## Description
Hi there,
I have been camping with my kids over the easter holidays. One day, it was rainin...## Submitted by Fabian Greffrath
**[Link to original bug (#749229)](https://bugzilla.gnome.org/show_bug.cgi?id=749229)**
## Description
Hi there,
I have been camping with my kids over the easter holidays. One day, it was raining outside and the kids were bored. I wanted to do them a favor and unpacked my Thinkpad to play a DVD for them. I inserted the DVD into the drive, started Totem and... nothing. "Ah, crap" I thought, "I need libdvdcss, this is a commercial DVD by one of the big studios". So, I pulled out my smartphone, enabled tethering for the laptop, grabbed the sources, compiled and installed the library. Phew. Tried again and... still nothing. Now, the kids were bored and disappointed. :/
Now, a few weeks later, I found out that the region code for my DVD drive was still unset and that this is a common issue when trying to decrypt DVD content. However, I was a bit disenchanted by the fact that attempting to play a DVD on Linux was still such an unsatisfying experience.
What I'd like to see improved:
1) Is there a way to detect that libdvdcss2 is not installed but will be needed for the current DVD to play? Please tell me.
2) Is there a way to detect that the region code for my drive is currently unset but needs to be set for the current DVD to play? Please tell me.
2a) Bonus points for offering me a way to set the DVD region code from within Totem.
3) Still need to verify, but I believe the DVD in question was additionally "protected" by ARccOS. I don't know if it will work now that I have libdvdcss2 installed and my region code set. But, if it is possible to detect that the "copy protection" mechanism of the disc is responsible for it not playing, please tell me. The current error message is a bit vague and could mean anything.
Thank you very much!
- Fabian