- 23 Jul, 2021 6 commits
-
-
The print_ref_pic_list_b now not only needs to trace the ref_pic_list_b0/1, but also need to trace the ref_frame_list_0_short_term. We need to pass the name directly to it rather than an index to refer to ref_pic_list_b0/1. Part-of: <gstreamer/gst-plugins-bad!2425>
-
The array sort of ref_frame_list_0_short_term has some typo. The typo makes this list not in the POC ascend order and generate wrong decoding result for interlaced streams. Part-of: <!2425>
-
When driver return error on update plane request, kmssink disables the scaling and retries plane update. While doing so kmssink was matching the source rectangle dimensions to the target rectangle dimensions which were calculated as per scaling but this is incorrect, instead what we want here is that target rectangle dimensions should match the source rectangle dimensions as scaling is disabled now and so we match result rectangle dimensions with source rectangle dimensions. While at it, also match the result rectangle coordinates for horizontal and vertical offsets with source rectange coordinates, as since there is no scaling being done so no recentering is required. Part-of: <gstreamer/gst-plugins-bad!2415>
-
Some cut VP9 streams begin with a non key frame. The current code just bail out the parse_process_frame() if not a key frame. Because of this, we do not set the valid caps before we push the data of the first frame(even this first frame will be discarded by the downstream decoder because it is not a key frame). The pipeline such as: gst-launch-1.0 filesrc location=some.ivf ! ivfparse ! vp9parse ! vavp9dec ! fakesink will get a negotiation error and the pipeline can not continue. The correct behaviour should be: the decoder discard the first frame and continue to decode later frames successfully. So, when the parse does not have valid stream info(should be the first frame case), we should continue and report caps. Part-of: <gstreamer/gst-plugins-bad!2427>
-
Nirbheek Chauhan authored
pipewiresrc outputs audio buffers without a valid duration, so we need to calculate it manually in that case. Upstream issue: pipewire/pipewire#1438 Part-of: <gstreamer/gst-plugins-bad!2419>
-
We may need to drop the slices such as RASL pictures with the NoRaslOutputFlag, so the current picture of h265decoder may be freed. We should not assign the frame-> output_buffer too early until we really output it. Or, the later coming slices will allocate another picture and trigger the assert of: gst_video_decoder_allocate_output_frame_with_params: assertion 'frame->output_buffer == NULL' failed Part-of: <gstreamer/gst-plugins-bad!2421>
-
- 22 Jul, 2021 2 commits
-
-
Some programs specify a PCR PID but don't actually store any PCR values, or are way too far apart. In order to gracefully handle those situations, we will queue up to a certain amount of pending buffers before deciding to give up on that PCR PID and not use any (i.e. using DTS/PTS values as-is) Fixes gstreamer/gst-plugins-bad#1629 Part-of: <gstreamer/gst-plugins-bad!2422>
-
He Junyan authored
In H265, the stream may have odd bit depth such as 9 or 11. And the bit depth of luma and chroma may differ. For example, the stream with luma depth of 8 and chroma depth of 9 should use the 10 bit rtformat as the decoded picture format. Part-of: <gstreamer/gst-plugins-bad!2420>
-
- 21 Jul, 2021 19 commits
-
-
In low_latency mode, try to bump the picture as soon as possible without the frames disorder: 1. We can directly output the continuous non-reference frame. 2. Consider max_num_reorder_frames, which is special useful for I-P mode. 3. Consider the leading pictures with negative POC. 4 Output small POC pictures when non-reference frame comes. 4. Output the POC increment<=2 pictures. This is not 100% safe, but in practice this condition can be used. Part-of: <!2373>
-
The max_num_reorder_frames can be useful for bump check. We store it in the DPB and no need for the decoder now. Part-of: <!2373>
-
The picture->ref field will change from time to time according to decoder's state and reference sliding window. We need another flag to record whether the picture is a reference picture when it is created, and this can help the bumping check. Part-of: <!2373>
-
The current behavior is different from the SPEC. We should check and bump the DPB or drain the DPB before we insert the current picture into it. This may cause the output picture disorder. Part-of: <!2373>
-
Accord to spec, we should not add the current picture into the DPB when we check whether it needs to bump, so the checks of the IDR and the "memory_management_control_operation equal to 5" are no needed. And the spec also says that the DPB only needs to bump when there is no empty frame buffer left(We handle the IDR cases in other places). We need to follow that and the max_num_reorder_frames is useless. We also minus 1 in has_empty_frame_buffer because the current frame has not been added yet. Part-of: <!2373>
-
Part-of: <!2373>
-
When current frame memory_management_control_operation equal to 5, that means we need to drain the dpb and the current picture act as an IDR frame. So it should have smaller poc than the later pictures to ensure the output order. Part-of: <!2373>
-
grmbl Part-of: <gstreamer/gst-plugins-bad!2371>
-
* If we have an index table for non-framed essence, we can handle it * The demuxer has a state which indicates whether it will next fetch a KLV or data contained *within* a KLV. * The position on Essence Tracks always correspond to the next entry to fetch, demuxer offset will be skipped accordingly whenever we switch between partitions (in case of resyncs). A copy of the main clip/custom KLV for that partition is kept to track the position within the essence of that partition. * For clip/custom-wrapped raw audio, if the edit rate is too small (and would cause plenty of tiny buffers to be outputted), specify a minimum number of edit units per buffer. Part-of: <gstreamer/gst-plugins-bad!2371>
-
* For pull-based, this avoids pulling content if it's not needed (ex: skipping filler packet, not downloading the content if we only need to know if/where an essence packet is, etc...). Allows reducing i/o usage to the minimum. * This also allows doing sub-klv position tracking, and opens the way for non-frame-wrapping handling Part-of: <gstreamer/gst-plugins-bad!2371>
-
This provides a summary of the number/type of tracks in the Material and File Packages Part-of: <gstreamer/gst-plugins-bad!2371>
-
In order to figure out the exact start position (backed by a keyframe) accross all tracks, we first figure out the backing keyframe position, and *then* seek to that position. Avoids ending up in situations where we would properly seek to the backing keyframe on video ... but not on the audio streams (they would have been set to the original non-keyframe position). Fixes key-unit seeking. Part-of: <gstreamer/gst-plugins-bad!2371>
-
Defined by Amendment 2:2013 to SMPTE ST 382:2007 Also define a new "UNKNOWN" wrapping type to make the difference with known wrapping types Part-of: <gstreamer/gst-plugins-bad!2371>
-
The picture essence coding matching was wrong. Use the proper "base" MXFUL for video mpeg compression for matching. Also handle the case where some old files would put the essence container label in the essence coding field Part-of: <gstreamer/gst-plugins-bad!2371>
-
* Streamline offset <=> entry handling. Historically the demuxer didn't support information from index tables and stored the discovered information in an array per track. When index table support was added, a parallel system was setup for that relationship. This commit unifies this into one system with the `find_edit_entry()` and `find_entry_for_offset()` functions. * By extension, per-track offset entry tables are only created/used if no index table is present for those tracks. * Use index table information as-is. The index table system from MXF is quite complex and there are various ways to use the information contained within. Instead of converting that information we store the data from the tables as-is and extract the needed information when needed. * Handle index tables without entries (i.e. all content package units are of the same size). * Allow collecting index table segments as we go instead of only once if a random-index-pack is present. This also improves support of some files in push-mode. * When searching for keyframe entries, use the keyframe_offset if present (speeds up searching). * For interleaved content (i.e. several tracks in the sample essence container), we use a system to be able to identify the position of each track in the delta entries of index tables. * Handle temporal offset only on tracks which *do* need it (as specified in the delta entries of the index tables). If present, those offsets are stored in a pre-processed table which allows computing PTS from DTS with a simple offset. * Add a quirk for files which are known to be have wrongly stored temporal offsets. * Overall opens the way to handle more types of MXF files, especially those with non-frame-wrapping. Part-of: <gstreamer/gst-plugins-bad!2371>
-
Part-of: <gstreamer/gst-plugins-bad!2371>
-
By printing out the various known flag values Part-of: <gstreamer/gst-plugins-bad!2371>
-
A Source Clip can have zero'd SourcePackageID and SourceTrackID, this indicates it terminates the source reference chain Part-of: <gstreamer/gst-plugins-bad!2371>
-
This is similar to how the same issue was handled in qtdemux. In order for the "DTS <= PTS" constraint to be respected, we calculate the maximum temporal reordering that can happen (via index tables). If there is a non-0 temporal reordering, we: * Shift all outgoing PTS by that amount * Shift segment for that stream by that amount * Don't modify DTS (i.e. they might end up having negative running-time, before the start of the segment) Also ensure all entries have a valid PTS set, previously this wouldn't be set for entries with a temporal offset of 0. Fixes gstreamer/gst-plugins-bad#584 (and maybe a lot of other issues) Part-of: <gstreamer/gst-plugins-bad!2371>
-
- 17 Jul, 2021 5 commits
-
-
Víctor Manuel Jáquez Leal authored
Added a comment with a future to-do, enhanced another comment and fixed a typo in an error log message. Part-of: <gstreamer/gst-plugins-bad!2417>
-
Víctor Manuel Jáquez Leal authored
Move up gst_va_decoder_get_config() to group decoders function in the same file area. Part-of: <!2417>
-
Víctor Manuel Jáquez Leal authored
Change gst_va_decoder_format_changed() to gst_va_decoder_config_is_equal(), which is more similar with other GStreamer API. The function call is replaced but it has to be negated because the return value is the opposite. Part-of: <gstreamer/gst-plugins-bad!2417>
-
Víctor Manuel Jáquez Leal authored
Rename gst_va_decoder_change_resolution() to gst_va_decoder_update_frame_size() which resembles gst_va_decoder_set_frame_size(). Also added a comment to clarify the function use and makes more specific the error message. Part-of: <gstreamer/gst-plugins-bad!2417>
-
Víctor Manuel Jáquez Leal authored
Renamed gst_va_decoder_set_format() to gst_va_decoder_set_frame_size_with_surfaces() which resembles better the passed parameters. Internally it creates the vaContext. Added gst_va_decoder_set_frame_size() which is an alias of gst_va_decoder_set_frame_size_with_surfaces() without surfaces. This is the function which replaces gst_va_decoder_set_format() where used. Part-of: <gstreamer/gst-plugins-bad!2417>
-
- 16 Jul, 2021 2 commits
-
-
He Junyan authored
We should use the NumPocTotalCurr value stored in decoder, which is a calculated valid value, rather than use the invalid value in the slice header. Most of the time, the NumPocTotalCurr is 0 and make the tmp_refs a very short length, and causes the decoder's wrong result. By the way, the NumPocTotalCurr is not the correct name specified in H265 spec, its name should be NumPicTotalCurr. We change it to the correct name. Part-of: <gstreamer/gst-plugins-bad!2414>
-
He Junyan authored
The VA's ReferenceFrames should only contain the reference frame, we should not add the non reference frames into this list. Part-of: <gstreamer/gst-plugins-bad!2414>
-
- 15 Jul, 2021 6 commits
-
-
... if closedcaption plugin is available Part-of: <gstreamer/gst-plugins-bad!2411>
-
Some GPUs support BGRA format and it will be converted to subsampled YUV format by GPU internally. Disable this implicit conversion since the conversion parameters such as input/output colorimetry are not exposed nor it's written in bitstream (e.g., VUI). We prefer explicit conversion via our conversion elements. Part-of: <gstreamer/gst-plugins-bad!2410>
-
The temp guint8 var of delta_chroma_offset_l0 and delta_chroma_offset_l1 can not cover the full range of delta_chroma_weight_l0/1 in the slice header. When overflow happens, the decoder result is wrong. Part-of: <gstreamer/gst-plugins-bad!2412>
-
Some manifests use the ContentProtection node to store additional information such as the license server url. Our MPD parser used to process the ContentProtection node, extracting Playready PSSH boxes. However for other DRM systems, only the `value` attribute was passed down to the protection event, so for example, Widevine data was not parsed at all and "Widevine" was passed to the event, which is not very useful for decryptors that require a PSSH init data. Parsing should now be done by decryptors which will receive the entire ContentProtection XML node as a string. This gives more "freedom" to the decryptor which can then detect and parse custom nodes as well. Part-of: <gstreamer/gst-plugins-bad!2400>
-
The VP9 streams have the ability to change the resolution dynamically at any time point. It does not send ad KEY frame before change the resolution, even the INTER frame can change the resolution immediately. So we need to check the resolution change for each frame and do the re-negiotiation if needed. Some insaned stream may play in resolution A first and then dynamically changes to B, and after 1 or 2 frames, it use a show_existing_frame to repeat the old frame of resolution A before. So, not only new_picture(), but also duplicate_picture() need to check this. Part-of: <gstreamer/gst-plugins-bad!2407>
-
The driver for VP9 should have the ability to handle the dynamical resolution changes. So if only the resolution changes, we should not re-create the config and context in negotiation. Part-of: <gstreamer/gst-plugins-bad!2407>
-
