feb6f41bcd
Changelog: =========== From 1.22.1: audio channel-mix: allow up to 64 channels (instead of up to 63 channels) avfvideosrc: Don't wait on main thread for permissions request avvidenc: avoid generating inaccurate output timestamps, especially with variable framerate streams AV1 video codec caps signalling improvements in various elements codectimestamper: Fix timestamping on sequence update d3d11overlaycompositor: fix texture width and height d3d11videosink: Fix rendering on external handle dashdemux2: fix seek operation taking a log time to finish for some streams nvencoder: Fix B-frame encoding on Linux and min buffers in auto GPU mode playbin3: fixing buffering for live pipelines playbin: fix potential deadlock when stopping stream with subtitles visible redenc: fix setting of extension ID for twcc rtspsrc: improved compatibility with more broken RTSP servers v4l2h264dec: Fix Raspberry Pi4 will not play video in application vtdec: fix jittery playback of H.264 Level 4.1 movies in macOS vtdec: Fix non-deterministic frame output after flushing seeks vtenc: fix handling of interlaced ProRes on Apple M1 hardware vtenc: don't advertise ARGB/RGBA64 input caps on M1 Pro/Max with macOS <13 wasapi2src: Fix loopback capture on Windows 10 Anniversary Update tools: better handling of non-ASCII command line arguments on Windows gst-libav: fix build against newer ffmpeg versions gst-python: Use arch-specific install dir for gi overrides cerbero: Fix setuptools site.py breakage in Python 3.11 macOS packages: Fix broken binaries on macos < 11.0 various bug fixes, memory leak fixes, and other stability and reliability improvements From 1.22.2: avdec_h264: fix decoder deadlocks with FFmpeg 6.0 rtspsrc: fix regression with URI protocols in OPTIONS requests for RTSP over TLS rtspsrc: improved control url handling compatibility for broken servers decklink: fix 10 bit RGB (r210) format auto detection for capture and fix playout if video caps are configured before audio caps d3d11videosink: Fix tearing in case of fullscreen mode playbin: fix deadlock when stopping stream with subtitles visible (even more) typefinding: fix regression not detecting application/dash+xml in some corner cases osxvideosink: fix broken aspect ratio and frame drawing region decodebin3, parsebin: Improve elementary stream handling when decoders are not present and fix hang when removing a failing stream urisourcebin: Propagate sticky events from parsebin, so that the STREAM_START event with the GstStream info is always available when pads get exposed v4l2: Add support for YVU420M format; mark JPEG content as parsed h264decoder, h265decoder: DPB bumping process and latency reporting fixes Opus: Fix reading of extended channel config in MPEG-TS and fix missing sample rate when remuxing from RTP to Matroska zxing: add support for building against zxing-c++ 2.0 cerbero: Fix packaging of Rust plugins on Android; fix modern Gentoo distro detection various bug fixes, memory leak fixes, and other stability and reliability improvements (From OE-Core rev: aed2b6833370b60c263afdd8beb0b1c20b9c2ec1) Signed-off-by: Steve Sakoman <steve@sakoman.com>
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
The project works using a mailing list patch submission process. Patches should be sent to the mailing list for the repository the components originate from (see below). Throughout the Yocto Project, the README files in the component in question should detail where to send patches, who the maintainers are and where bugs should be reported.
A guide to submitting patches to OpenEmbedded is available at:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
There is good documentation on how to write/format patches at:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.