GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-10-22T07:40:50Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/43autoconnect fails with tsdemux and h264parse, it didn't try other decoders2021-10-22T07:40:50ZBugzilla Migration Userautoconnect fails with tsdemux and h264parse, it didn't try other decoders## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#770535)](https://bugzilla.gnome.org/show_bug.cgi?id=770535)**
## Description
URL:
https://vodcdn.mobcrush.com/u/video/57a5c1a051f31fbb6d62cd53/recording.mp...## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#770535)](https://bugzilla.gnome.org/show_bug.cgi?id=770535)**
## Description
URL:
https://vodcdn.mobcrush.com/u/video/57a5c1a051f31fbb6d62cd53/recording.mp4.m3u8
Attempting to play this stream fails with a not-negotiated error.
0:00:00.745837289 18551 0x1972ad0 WARN basetransform gstbasetransform.c:1414:gst_base_transform_setcaps:`<capsfilter0>` transform could not transform video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal, width=(int)1196, height=(int)720, framerate=(fraction)0/1, parsed=(boolean)true, profile=(string)baseline, level=(string)3.1 in anything we support
GStreamer 1.8.3
VA-API version: 0.39 (libva 1.7.1)
Intel i965 driver for Intel(R) Haswell Desktop - 1.7.1
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/41vaapidecodebin ! glimagesink fails performing vaapi postprocessing2021-10-22T07:40:50ZBugzilla Migration Uservaapidecodebin ! glimagesink fails performing vaapi postprocessing## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#769253)](https://bugzilla.gnome.org/show_bug.cgi?id=769253)**
## Description
With latest gst master with vaapi available/enabled, gst-launch-1.0 playbin uri=blah vi...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#769253)](https://bugzilla.gnome.org/show_bug.cgi?id=769253)**
## Description
With latest gst master with vaapi available/enabled, gst-launch-1.0 playbin uri=blah video-sink=glimagesink results in pipeline failure with:
ERROR vaapipostproc gstvaapipostproc.c:803:gst_vaapipostproc_process_vpp: failed to apply VPP filters (error 2)
Running on an intel chip
Also, vaapidecode doesn't seem to exist anymore by itself so simple testing without vaapipostproc is problematic.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/39vaapidecode: mpeg-2 don't render with ximagesink2021-10-22T07:40:50ZBugzilla Migration Uservaapidecode: mpeg-2 don't render with ximagesink## Submitted by Tim Müller `@tpm`
**[Link to original bug (#766978)](https://bugzilla.gnome.org/show_bug.cgi?id=766978)**
## Description
$ gst-play-1.0 https://people.freedesktop.org/~tpm/samples/bbcnews.m2t
Doesn't work at all...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#766978)](https://bugzilla.gnome.org/show_bug.cgi?id=766978)**
## Description
$ gst-play-1.0 https://people.freedesktop.org/~tpm/samples/bbcnews.m2t
Doesn't work at all for me with gstreamer-vaapi (i.e. if vaapisink is picked as sink which it is by default). Lots of criticals and a pink image. Works with glimagesink and xvimagesink.
### Depends on
* [Bug 771382](https://bugzilla.gnome.org/show_bug.cgi?id=771382)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/38vaapipostproc: deinterlace produces video jerking2021-10-22T07:40:50ZBugzilla Migration Uservaapipostproc: deinterlace produces video jerking## Submitted by Lim Siew Hoon
**[Link to original bug (#766862)](https://bugzilla.gnome.org/show_bug.cgi?id=766862)**
## Description
Created attachment 328488
test_video_h264_info.txt
Gstreamer framework 1.7.90 version
Gstr...## Submitted by Lim Siew Hoon
**[Link to original bug (#766862)](https://bugzilla.gnome.org/show_bug.cgi?id=766862)**
## Description
Created attachment 328488
test_video_h264_info.txt
Gstreamer framework 1.7.90 version
Gstreamer-vaapi: 1.7.90 version.
command:
gst-launch-1.0 filesrc location=/home/root/H264_Main_Interlaced_Sound_ToTheLimit.mp4 ! qtdemux ! vaapidecode ! vaapipostproc deinterlace-mode=1 deinterlace-method=1 ! vaapisink fullscreen=true
Combination:
deinterlace-mode=1 and deinterlace-method=0
deinterlace-mode=1 and deinterlace-method=1
deinterlace-mode=1 and deinterlace-method=2
deinterlace-mode=0 and deinterlace-method=0
deinterlace-mode=0 and deinterlace-method=1
deinterlace-mode=0 and deinterlace-method=2
H264 interlace video with vaapipostproc with above combination will causing the video jerking. The issue also able to reproduce in 1.8.1 version too.
flags = 0x0 and ttf=0x1
Original version: gst_vaapipostproc_process function
/* Second field */
append_output_buffer_metadata (postproc, outbuf, inbuf, 0);
meta = gst_buffer_get_vaapi_video_meta (outbuf);
outbuf_flags = flags;
outbuf_flags |= deint ? (tff ?
GST_VAAPI_PICTURE_STRUCTURE_BOTTOM_FIELD :
GST_VAAPI_PICTURE_STRUCTURE_TOP_FIELD) :
GST_VAAPI_PICTURE_STRUCTURE_FRAME;
gst_vaapi_video_meta_set_render_flags (meta, outbuf_flags);
Modify version:
/* Second field */
append_output_buffer_metadata (postproc, outbuf, inbuf, 0);
meta = gst_buffer_get_vaapi_video_meta (outbuf);
outbuf_flags = flags;
outbuf_flags |= deint ? (tff ?
GST_VAAPI_PICTURE_STRUCTURE_TOP_FIELD :
GST_VAAPI_PICTURE_STRUCTURE_BOTTOM_FIELD) :
GST_VAAPI_PICTURE_STRUCTURE_FRAME;
gst_vaapi_video_meta_set_render_flags (meta, outbuf_flags);
After I make the arrangement in outbuf_flags same as the fieldbuf_flags logic checking, the video jerking issue go away.
**Attachment 328488**, "test_video_h264_info.txt":
[test_video_h264_info.txt](/uploads/128fc2b9d7d364e0b3722202323af598/test_video_h264_info.txt)
Version: 1.7.90https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/37Encoder: HEVC: Add Packed SEI header support2021-10-22T07:40:50ZBugzilla Migration UserEncoder: HEVC: Add Packed SEI header support## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#766047)](https://bugzilla.gnome.org/show_bug.cgi?id=766047)**
## Description
VA-backed driver might not insert SEI headers in to the encoded stream by itself. W...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#766047)](https://bugzilla.gnome.org/show_bug.cgi?id=766047)**
## Description
VA-backed driver might not insert SEI headers in to the encoded stream by itself. We are supposed to provide the SEI headers from upper layer. It is good provide buffering_period and picture_timing SEI headers as VAEncPackedHeaders while enabling CBR mode encode.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/36Fail to vaapidecode mpegts streams starting between keyframes2021-10-22T07:40:50ZBugzilla Migration UserFail to vaapidecode mpegts streams starting between keyframes## Submitted by Tanner
**[Link to original bug (#764103)](https://bugzilla.gnome.org/show_bug.cgi?id=764103)**
## Description
Hi,
vaapidecode element has been unable to decode previously chunked ts files from filesrc and udpsrc...## Submitted by Tanner
**[Link to original bug (#764103)](https://bugzilla.gnome.org/show_bug.cgi?id=764103)**
## Description
Hi,
vaapidecode element has been unable to decode previously chunked ts files from filesrc and udpsrc. It appears the vaapidecode element doesn't deal with the garbage before a keyframe and bails.
Using the following pipeline I am unable to play a udpsrc mpegts stream and receive no valid frames before end of stream from the vaapidecode element.
gst-launch-1.0 -v udpsrc uri=(makeoneupmulticast) ! tsparse ! video/x-h264 ! h264parse ! vaapidecode ! vaapisink
However, if I modify the pipeline to use avdec_h264 and x264enc to feed into the vaapidecode element, then it is able to play the stream.
gst-launch-1.0 -v udpsrc uri=(makeoneupmulticast) ! tsparse ! video/x-h264 ! h264parse ! avdec_h264 ! x264enc ! vaapidecode ! vaapisink
To test the above, produce a test ts file and confirm you can play it with vaapidecode ! vaapisink. Next, use a multifilesink to chunk it into several pieces. Play the first chunk using a single filesrc (it should play). But then try playing one of the middle chunks. This should reproduce the error. If you chunk on keyframes, then you are less likely to experience the error so I suggest chunking on buffersize.
(I am unable to add attachments due to company policy)
Version: 1.7.91https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/35jpeg decoder: gen75_mfd.c:2203: gen75_mfd_jpeg_decode_init: Assertion `0' failed2021-10-22T07:40:50ZBugzilla Migration Userjpeg decoder: gen75_mfd.c:2203: gen75_mfd_jpeg_decode_init: Assertion `0' failed## Submitted by Tim Müller `@tpm`
**[Link to original bug (#762500)](https://bugzilla.gnome.org/show_bug.cgi?id=762500)**
## Description
Created attachment 321907
vaapi-assert.jpg
Not sure if this is an issue with the jepg pa...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#762500)](https://bugzilla.gnome.org/show_bug.cgi?id=762500)**
## Description
Created attachment 321907
vaapi-assert.jpg
Not sure if this is an issue with the jepg parser / vaapi or lower levels in the stack:
$ gst-play-1.0 vaapi-assert.jpg
libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
Redistribute latency...
lt-gst-play-1.0: gen75_mfd.c:2203: gen75_mfd_jpeg_decode_init: Assertion `0' failed.
Aborted (core dumped)
**Attachment 321907**, "vaapi-assert.jpg":
![vaapi-assert](/uploads/ee0c36277e43fea5b20356962f521de4/vaapi-assert.jpg)
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=67150https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/34GstVaapiVideoMemory doesn't allow GST_MAP_WRITE mapping2021-10-22T07:40:50ZBugzilla Migration UserGstVaapiVideoMemory doesn't allow GST_MAP_WRITE mapping## Submitted by Michał Wróbel
**[Link to original bug (#751711)](https://bugzilla.gnome.org/show_bug.cgi?id=751711)**
## Description
Trying to map the buffer in GST_MAP_READ | GST_MAP_WRITE mode fails with gst.vaapivideomemory unsup...## Submitted by Michał Wróbel
**[Link to original bug (#751711)](https://bugzilla.gnome.org/show_bug.cgi?id=751711)**
## Description
Trying to map the buffer in GST_MAP_READ | GST_MAP_WRITE mode fails with gst.vaapivideomemory unsupported map flags (0x3) at gstreamer-vaapi/gst/vaapi/gstvaapivideomemory.c:436. Is there any particular reason why gst_vaapi_video_memory_map() doesn't just use the same kind of mapping it does for GST_MAP_READ? LibVA documentation [1] doesn't seem mention that vaMapBuffer-mapped buffers shouldn't be tampered with...
[1] http://01org.github.io/libva_master_doxygen/group__api__core.html#gaf14c698af1d0920f4aeb5eb11f81b6aahttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/33h264 decoder: One too many unref of a codecframe2021-10-22T07:40:50ZBugzilla Migration Userh264 decoder: One too many unref of a codecframe## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#750754)](https://bugzilla.gnome.org/show_bug.cgi?id=750754)**
## Description
The most obvious symptom is:
** (mmfd:10989): CRITICAL **: gst_video_codec_frame_unref:...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#750754)](https://bugzilla.gnome.org/show_bug.cgi?id=750754)**
## Description
The most obvious symptom is:
** (mmfd:10989): CRITICAL **: gst_video_codec_frame_unref: assertion 'frame->ref_count > 0' failed
With some interlaced H.264 streams, in the presence of packet loss (simulated with identity drop-probablity=0.01), the first field decoding fails in dpb_dump() (from gst_vaapi_decoder_decode->do_decode->do_decode_1->end_frame->decode_current_picture->dpb_add), this results in gst_vaapi_decoder_decode returning an error and gst_video_decoder_drop_frame() being called.
The problem is that before failing in dpb_bump(), the picture has been stored in a framestore which has been added to priv->prev_frames. And from prev_frames, find_first_field() retrieves it on the next frame and uses it as a base, which will cause it to push outputted by pushing it to gst_video_decoder_finish_frame.
This caues a problem, as when handle_frame is called, a single reference is given to the subclass, calling drop_frame() drops this reference... But calling finish_frame expects another reference!
I'm not sure how to solve that problem exactly.
### Blocking
* [Bug 758397](https://bugzilla.gnome.org/show_bug.cgi?id=758397)
### See also
* [Bug 751434](https://bugzilla.gnome.org/show_bug.cgi?id=751434)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/32mpeg2: verify bug 749607 patches2021-10-22T07:40:50ZBugzilla Migration Usermpeg2: verify bug 749607 patches## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#750221)](https://bugzilla.gnome.org/show_bug.cgi?id=750221)**
## Description
There doubts in these two commits ([bug 749607](https://bugzilla.gnome.org/s...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#750221)](https://bugzilla.gnome.org/show_bug.cgi?id=750221)**
## Description
There doubts in these two commits ([bug 749607](https://bugzilla.gnome.org/show_bug.cgi?id=749607)):
commit d6255be9398f5d6803c0997446a4b89c10beab26
Author: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Date: Wed May 27 10:49:56 2015 +0200
mpeg2: avoid crash when seeking with debug logs
Move down the debug message when the state of the decoder is verified
so the slice header is not NULL.
commit f1a60ec6a2d9523c10713a43871df22ddc68d720
Author: Jan Schmidt <jan@centricular.com>
Date: Wed Dec 17 00:41:10 2014 +1100
mpeg2: Avoid crashes and warnings on re-opened decoder after a seek
Reset state and add some checks for safe state to avoid a crash and
a warning after the decoder is destroyed/recreated during a seek.
In commit d6255be9
(In reply to Gwenole Beauchesne from comment 13)
> It would be better to know why slice_hdr or unit is NULL. Committing this is
> just hiding the core issue more...
In commit f1a60ec6 (from discussion in https://github.com/thaytan/gstreamer-vaapi/commit/b84e65ada15f9396b8c9ab507c1cb5f10c3f3914)
>+ if (!is_valid_state(decoder, GST_MPEG_VIDEO_STATE_VALID_PIC_HEADERS))
>+ return GST_VAAPI_DECODER_STATUS_SUCCESS;
>+
> This part should not be necessary. This is already tracked at decode time. I
> would just push the two other hunks.
This bug is to verify if those changeset are correct or not.
### Blocking
* [Bug 758397](https://bugzilla.gnome.org/show_bug.cgi?id=758397)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/31Encoder: HEVC: Add more tuning options2021-10-22T07:40:50ZBugzilla Migration UserEncoder: HEVC: Add more tuning options## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#749853)](https://bugzilla.gnome.org/show_bug.cgi?id=749853)**
## Description
The va-intel-driver is not supporting all encoding tools, but still we can add a co...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#749853)](https://bugzilla.gnome.org/show_bug.cgi?id=749853)**
## Description
The va-intel-driver is not supporting all encoding tools, but still we can add a couple of features to enable High Compression Tuning option.
-- Enable B-frames for High Compression
-- Current implementation is Using 32x32 CTU by default. Use 16x16 mode as default and Change it to 32x32 or 64x64 based on tuning options.
BTW, 64x64 is not yet supported by the driver.
-- Add support for B-frame Reference Picture Encoding.
### Blocking
* [Bug 758397](https://bugzilla.gnome.org/show_bug.cgi?id=758397)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/28encoder: h264: add support Inter-view prediction2021-10-22T07:40:50ZBugzilla Migration Userencoder: h264: add support Inter-view prediction## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#745096)](https://bugzilla.gnome.org/show_bug.cgi?id=745096)**
## Description
Add support for Interview prediction in H264 MVC encoding.## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#745096)](https://bugzilla.gnome.org/show_bug.cgi?id=745096)**
## Description
Add support for Interview prediction in H264 MVC encoding.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/21vaapipostproc: failed to deinterlace from decodebin with SW decoder2023-06-27T17:53:15ZBugzilla Migration Uservaapipostproc: failed to deinterlace from decodebin with SW decoder## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735360)](https://bugzilla.gnome.org/show_bug.cgi?id=735360)**
## Description
Based on [bug 731460](https://bugzilla.gnome.org/show_bug.cgi?id=731460), vaapipostproc ...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735360)](https://bugzilla.gnome.org/show_bug.cgi?id=735360)**
## Description
Based on [bug 731460](https://bugzilla.gnome.org/show_bug.cgi?id=731460), vaapipostproc fails to deinterlace from decodebin with SW decoder, e.g. mpeg2dec.
$ gst-launch-1.0 -v filesrc location=/Videos/mpeg2/interlaced/syntax_720.mpg ! decodebin ! vaapipostproc deinterlace-mode=auto deinterlace-method=none width=400 height=300 ! vaapisink
### Depends on
* [Bug 704078](https://bugzilla.gnome.org/show_bug.cgi?id=704078)
* [Bug 735379](https://bugzilla.gnome.org/show_bug.cgi?id=735379)
* [Bug 735391](https://bugzilla.gnome.org/show_bug.cgi?id=735391)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/20vaapopostproc: deinterlacing don't set the correct PTS for mpeg22021-10-22T07:40:49ZBugzilla Migration Uservaapopostproc: deinterlacing don't set the correct PTS for mpeg2## Submitted by Simon Farnsworth
**[Link to original bug (#734135)](https://bugzilla.gnome.org/show_bug.cgi?id=734135)**
## Description
When using:
gst-launch-1.0 filesrc location=interlace-test.mpg ! tsdemux name=mux ! queue ...## Submitted by Simon Farnsworth
**[Link to original bug (#734135)](https://bugzilla.gnome.org/show_bug.cgi?id=734135)**
## Description
When using:
gst-launch-1.0 filesrc location=interlace-test.mpg ! tsdemux name=mux ! queue ! mpegvideoparse ! vaapidecode ! queue ! vaapipostproc deinterlace-method=4 ! queue ! vaapisink
or deinterlace-method=3, Haswell graphics from an i3-4350T doesn't deinterlace cleanly - I get flicker and jerkiness, and even green frames.
This also happens if I use interlaced streams over UDP.
I'm using gstreamer-vaapi as of:
commit 7ac501d026036887c114b28bc9fb4aabc557e91a
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date: Fri Aug 1 06:32:32 2014 +0200
build: fix with --no-undefined linker flags.
https://bugzilla.gnome.org/show_bug.cgi?id=729352
libva-intel-driver as of:
commit 82d2ed8d7da3619c0ea467c06604f5626fc0b901
Author: Zhao Yakui <yakui.zhao@intel.com>
Date: Wed Jul 23 13:46:17 2014 +0800
Add more check of H264 slice param to avoid GPU hang caused by the incorrect parameter
This is to fix the GPU hang in https://bugs.freedesktop.org/show_bug.cgi?id=76363
V1->V2: Use the new check based on Haihao's comment. Discard the current frame with the error
slice_param instead of smart fix. In such case it can prompt that the error slice_param
can be fixed by the upper-middle.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: ValdikSS <iam@valdikss.org.ru>
Reviewed-by: Xiang Haihao <haihao.xiang@intel.com>
(cherry picked from commit 04202281135149a13a32dfb8a902debfac1331fe)
and the released libva-1.3.0.
I would expect smooth deinterlacing, at least as good as I get using the same code on IVB.
### Depends on
* [Bug 734386](https://bugzilla.gnome.org/show_bug.cgi?id=734386)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/17encoder: h264: fix coded buffer size for MVC2021-10-22T07:40:49ZBugzilla Migration Userencoder: h264: fix coded buffer size for MVC## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#732678)](https://bugzilla.gnome.org/show_bug.cgi?id=732678)**
## Description
The coded buffer size calculation need to compensate for extra storage that might be nee...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#732678)](https://bugzilla.gnome.org/show_bug.cgi?id=732678)**
## Description
The coded buffer size calculation need to compensate for extra storage that might be needed for Prefix NAL or more specifically Subset SPS NAL units + MVC specific additions into others.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/15MADI doesn't respect hardware limits, and assumes that any surface type is ac...2021-10-22T07:40:49ZBugzilla Migration UserMADI doesn't respect hardware limits, and assumes that any surface type is acceptable as the reference surface## Submitted by Simon Farnsworth
**[Link to original bug (#730925)](https://bugzilla.gnome.org/show_bug.cgi?id=730925)**
## Description
As per https://bugs.freedesktop.org/show_bug.cgi?id=79377#c2 I'm filing this bug.
When I ha...## Submitted by Simon Farnsworth
**[Link to original bug (#730925)](https://bugzilla.gnome.org/show_bug.cgi?id=730925)**
## Description
As per https://bugs.freedesktop.org/show_bug.cgi?id=79377#c2 I'm filing this bug.
When I have a YUY2 source feeding gstreamer-vaapi with the patch at https://bugzilla.gnome.org/show_bug.cgi?id=726361 applied, I get horrible colour effects from the deinterlacing. My pipeline is:
gst-launch-1.0 v4l2src ! vaapipostproc deinterlace-mode=interlaced deinterlace-method=motion-adaptive ! vaapisink
gstreamer-vaapi provides YUY2 surfaces to VPP for deinterlacing; SNB and IVB can only deinterlace NV12, so I get horrible artifacting.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/14encoder: add h264 scalable encoder2021-10-22T07:40:49ZBugzilla Migration Userencoder: add h264 scalable encoder## Submitted by XuGuangxin
**[Link to original bug (#725536)](https://bugzilla.gnome.org/show_bug.cgi?id=725536)**
## Description
Created attachment 270746
add svc profile. h264 have many differences compare to pure h264, such as ...## Submitted by XuGuangxin
**[Link to original bug (#725536)](https://bugzilla.gnome.org/show_bug.cgi?id=725536)**
## Description
Created attachment 270746
add svc profile. h264 have many differences compare to pure h264, such as bit rate control, frame type assignment. So I created total new profile for svc.
Init commit for h264 scalable.Only temporal supported.
**Patch 270746**, "add svc profile. h264 have many differences compare to pure h264, such as bit rate control, frame type assignment. So I created total new profile for svc.":
[0001-profile-add-svc-profile.patch](/uploads/97c8eea25ad47eab83c858d3372774ff/0001-profile-add-svc-profile.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/11encoder: mpeg2: add packed headers to slices2021-10-22T07:40:49ZBugzilla Migration Userencoder: mpeg2: add packed headers to slices## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#722906)](https://bugzilla.gnome.org/show_bug.cgi?id=722906)**
## Description
This the MPEG-2 companion bug to` #722905`. Some drivers require packed headers for slic...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#722906)](https://bugzilla.gnome.org/show_bug.cgi?id=722906)**
## Description
This the MPEG-2 companion bug to` #722905`. Some drivers require packed headers for slices too, but we currently only support packed headers for sequence and picture parameters.
### Blocking
* [Bug 758397](https://bugzilla.gnome.org/show_bug.cgi?id=758397)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/8encoder: h264: calculate a better slice_qp_delta in running time2021-10-22T07:40:49ZBugzilla Migration Userencoder: h264: calculate a better slice_qp_delta in running time## Submitted by Wind Yuan
**[Link to original bug (#722082)](https://bugzilla.gnome.org/show_bug.cgi?id=722082)**
## Description
gstvaapi H.264 encoder need set a proper slice_qp_delta in encoding slices. The currently code only set...## Submitted by Wind Yuan
**[Link to original bug (#722082)](https://bugzilla.gnome.org/show_bug.cgi?id=722082)**
## Description
gstvaapi H.264 encoder need set a proper slice_qp_delta in encoding slices. The currently code only set a fixed value. It's better to make slice_qp_delta more flexible in running. some possible options.
1. CQP mode, keep 0.
2. bitrate control mode, need to check the bitrate fluctution. always keep a window size there and compare the summary of last few encoded frame size, if larger than window, set slice_qp_delta > 0 to reduce next frame size. If less than avg, set to < 0 try to fill the window, but make sure init_qp + slice_qp_delta >= min_qp.
3. none rate-control mode, maybe set to 0, or random between [init_qp - n, init_qp + m]. certainly if can consider about quality changes should be much better.
Any suggestions/comments welcome.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/7plugins: fix GLTextureUploadMeta check for native texture changes2021-10-22T07:40:49ZBugzilla Migration Userplugins: fix GLTextureUploadMeta check for native texture changes## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#720728)](https://bugzilla.gnome.org/show_bug.cgi?id=720728)**
## Description
Currently, in the GLTextureUploadMeta::upload() implementation for GLX, we check that th...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#720728)](https://bugzilla.gnome.org/show_bug.cgi?id=720728)**
## Description
Currently, in the GLTextureUploadMeta::upload() implementation for GLX, we check that the supplied texture changed by its name. This is OK for the general case but there is still a possibility that the upper layer (e.g. glimagesink) releases that texture, and next create a new one, but with different dimensions.
Note: that's not a big deal currently because we usually create a GL texture that is as large as the original VA surface. For performance reasons, e.g. 2160p surface -> 1080p display, it could be enough to upload to a smaller texture.
Possible solutions:
1) Fix gst_vaapi_texture_upload() to also check for the supplied texture dimensions. This causes the GL pipeline to sync since a glGetTexLevelParameteriv() would be involved for GL_WIDTH and GL_HEIGHT params. i.e. that doesn't look a good approach for performance reasons, but this is a correct one.
2) Mandate, and document, GLTextureUploadMeta _upload() hook to required that supplied texture characteristics (format, size) need to be consistent for the lifetime of the meta. Benefit: no code change, efficient. Only doc update needed.
3) Change the upload API to let the upper layer (caller) supply the dimensions for the various textures in the _upload() arguments.
### Depends on
* [Bug 720336](https://bugzilla.gnome.org/show_bug.cgi?id=720336)