GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:32:14Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/112mpegtsmux: performance issue2021-09-24T14:32:14ZBugzilla Migration Usermpegtsmux: performance issue## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#709826)](https://bugzilla.gnome.org/show_bug.cgi?id=709826)**
## Description
Created attachment 256917
callgrind graph of mpegtsmux usage
mpegtsmux does a lot...## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#709826)](https://bugzilla.gnome.org/show_bug.cgi?id=709826)**
## Description
Created attachment 256917
callgrind graph of mpegtsmux usage
mpegtsmux does a lot of allocation, mapping and adapter usage.
Ideally it should introduce very little overhead (it doesn't even need to read the input data, just mux it).
right now it uses` ~80000` cpu instructions per incoming buffer.
**Attachment 256917**, "callgrind graph of mpegtsmux usage":
![mpegtsmux-callgrind](/uploads/805b3534b5f1c919d24350e8f38f03b4/mpegtsmux-callgrind.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/111h264parse: Add a method to blindly timestamp based on framerate2021-09-24T14:32:14ZBugzilla Migration Userh264parse: Add a method to blindly timestamp based on framerate## Submitted by Robert Swain
**[Link to original bug (#709756)](https://bugzilla.gnome.org/show_bug.cgi?id=709756)**
## Description
Sometimes one may encounter a raw h.264 file that doesn't have any timestamp information. It may be ...## Submitted by Robert Swain
**[Link to original bug (#709756)](https://bugzilla.gnome.org/show_bug.cgi?id=709756)**
## Description
Sometimes one may encounter a raw h.264 file that doesn't have any timestamp information. It may be useful, at least for testing purposes, to be able to apply timestamps to the frames using h264parse.
The idea is that if the sink pad caps state the stream-format=byte-stream and contain a framerate, this is can be used to override the buffer timestamps by starting from zero and adding the frame duration for each frame.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/109opencv: new plugin to make smooth slowmotion2021-09-24T14:32:13ZBugzilla Migration Useropencv: new plugin to make smooth slowmotion## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#708545)](https://bugzilla.gnome.org/show_bug.cgi?id=708545)**
## Description
The plugin uses code from slowmovideo, porting it from QT and its own internal decodin...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#708545)](https://bugzilla.gnome.org/show_bug.cgi?id=708545)**
## Description
The plugin uses code from slowmovideo, porting it from QT and its own internal decoding "framework" based on ffmpeg to gstreamer.
the code is available there :
https://github.com/MathieuDuponchelle/gst-plugins-base/commits/slowmotion
and is up for trial / review, one issue I am aware of and will fix is the fact that it should be in bad/ext/opencv.
example launch line:
gst-launch-1.0 -e uridecodebin uri=file:///any/file ! videoconvert ! videorate rate=0.1 ! video/x-raw, format=RGB ! slowmo ! videoconvert ! theoraenc ! oggmux ! filesink location=somewhere.ogv
The videoconversion is necessary, as the code will only accept either RGB or BGR for now.
The videorate is also necessary, with a patch from that comment:
https://bugzilla.gnome.org/show_bug.cgi?id=699077#c25
Please do the review here, as github throws away commit comments when pushing non fast forward.
There's plenty of room for optimization and cleanup, contributions are more than welcome :)
### Depends on
* [Bug 699077](https://bugzilla.gnome.org/show_bug.cgi?id=699077)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/108xvid: Port plugin to 1.0.2023-05-16T17:10:44ZBugzilla Migration Userxvid: Port plugin to 1.0.## Submitted by Jonathan Horowitz
**[Link to original bug (#707433)](https://bugzilla.gnome.org/show_bug.cgi?id=707433)**
## Description
Created attachment 254028
Changes to xvid plugin as of 0.10 API
Get the xvid plugin work...## Submitted by Jonathan Horowitz
**[Link to original bug (#707433)](https://bugzilla.gnome.org/show_bug.cgi?id=707433)**
## Description
Created attachment 254028
Changes to xvid plugin as of 0.10 API
Get the xvid plugin working with the 1.0 API.
~~**Patch 254028**~~, "Changes to xvid plugin as of 0.10 API":
[xvid-1.0.7.patch](/uploads/1c8fc022b29164899fa99fc2749cb341/xvid-1.0.7.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/107vc1parse: misc things that need doing2021-09-24T14:32:12ZBugzilla Migration Uservc1parse: misc things that need doing## Submitted by Tim Müller `@tpm`
**[Link to original bug (#707123)](https://bugzilla.gnome.org/show_bug.cgi?id=707123)**
## Description
Just dropping this somewhere, since it comes up regularly. Might not be entirely up-to-date.
...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#707123)](https://bugzilla.gnome.org/show_bug.cgi?id=707123)**
## Description
Just dropping this somewhere, since it comes up regularly. Might not be entirely up-to-date.
For vc1parse the following has to be done still:
* baseparse: Add a convert vfunc to baseparse that is called after
check_valid_frame and before parse_frame to allow subclasses to convert
one frame to another stream format. This vfunc should return a list of
buffers.
* vc1parse: Implement convert vfunc for all the million stream formats
* vc1parse: check_valid_frame for BDU stream formats always gets
everything up to and including a complete frame, i.e. seqhdr,
entrypoint, frame, field, slice splitted later
* vc1parse: Add conversion from EBDU to RBDU and the other way around.
For ASF in simple/main profile the content has to be RBDU, for the BDU
stream formats with startcode in the beginning it has to be EBDU. See
the VC1 spec about this, EBDU is RBDU with some byte sequences escaped.
### See also
* [Bug 743948](https://bugzilla.gnome.org/show_bug.cgi?id=743948)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/103Add mpeg2 slice header information to GstMpegVideoMeta2021-09-24T14:32:11ZBugzilla Migration UserAdd mpeg2 slice header information to GstMpegVideoMeta## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#704865)](https://bugzilla.gnome.org/show_bug.cgi?id=704865)**
## Description
Created attachment 250112
mpegvideometa: Add slice information to the GstMpegVide...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#704865)](https://bugzilla.gnome.org/show_bug.cgi?id=704865)**
## Description
Created attachment 250112
mpegvideometa: Add slice information to the GstMpegVideoMeta.
+++ This bug was initially created as a clone of [Bug 691712](https://bugzilla.gnome.org/show_bug.cgi?id=691712) +++
~~**Patch 250112**~~, "mpegvideometa: Add slice information to the GstMpegVideoMeta.":
[0001-mpegvideometa-Add-slice-information-to-the-GstMpegVi.patch](/uploads/5ea6c06f701ab3a944ed8d9f9d0d071d/0001-mpegvideometa-Add-slice-information-to-the-GstMpegVi.patch)
### Blocking
* [Bug 734547](https://bugzilla.gnome.org/show_bug.cgi?id=734547)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/102mpegvideoparse: Add GstVideoCropMeta2021-09-24T14:32:10ZBugzilla Migration Usermpegvideoparse: Add GstVideoCropMeta## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#704794)](https://bugzilla.gnome.org/show_bug.cgi?id=704794)**
## Description
Created attachment 250011
mpegvideoparse: Add GstVideoCropMeta
If the encode...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#704794)](https://bugzilla.gnome.org/show_bug.cgi?id=704794)**
## Description
Created attachment 250011
mpegvideoparse: Add GstVideoCropMeta
If the encoded stream has any associated crop rectangle (SequenceDispalyExtension), then send it as GstVideoCropMeta to the downstream.
Similar bugs: https://bugzilla.gnome.org/show_bug.cgi?id=694068
**Patch 250011**, "mpegvideoparse: Add GstVideoCropMeta":
[0001-mpegvideoparse-Add-GstVideoCropMeta.patch](/uploads/d4bf7be1503f8e36ddec55699a9e35c7/0001-mpegvideoparse-Add-GstVideoCropMeta.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/99New plugin with convenience RTP source/sink elements2019-09-18T18:12:25ZBugzilla Migration UserNew plugin with convenience RTP source/sink elements## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#703111)](https://bugzilla.gnome.org/show_bug.cgi?id=703111)**
## Description
These are two modules
- rtpsink
- rtpsrc
They register the rtp uri handler a...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#703111)](https://bugzilla.gnome.org/show_bug.cgi?id=703111)**
## Description
These are two modules
- rtpsink
- rtpsrc
They register the rtp uri handler and and allow receiving and sending data over the network with RTP and RTCP on the standard sockets.
Furthermore, the URI handling is such that all the GStreamer properties can be encoded in the URI in a standards fashion:
e.g.
rtp://239.1.2.3:1234?encoding-name=H264
use:
gst-launch-1.0 rtpsrc uri=rtp://239.1.2.3:1234?encoding-name=H264 ! decodebin ! autovideosink
I will provide a version that is a bit more cleaned up:
- recently work on encryption has been done; we need to figure out if it fits in these modules or not
This will be added as the code is moved out our our code base gradually and as it is tested on amd64 and armhf in the seperate form.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/98videomeasure: port to 1.02023-06-07T10:10:51ZBugzilla Migration Uservideomeasure: port to 1.0## Submitted by LRN
**[Link to original bug (#703093)](https://bugzilla.gnome.org/show_bug.cgi?id=703093)**
## Description
subj## Submitted by LRN
**[Link to original bug (#703093)](https://bugzilla.gnome.org/show_bug.cgi?id=703093)**
## Description
subjhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/97tsdemux: reverse playback support2021-09-24T14:32:09ZBugzilla Migration Usertsdemux: reverse playback support## Submitted by Lori Anderson
**[Link to original bug (#702595)](https://bugzilla.gnome.org/show_bug.cgi?id=702595)**
## Description
I'm working on playspeed support related to mpeg-ts using latest GStreamer-1.X code on Ubuntu 12.4....## Submitted by Lori Anderson
**[Link to original bug (#702595)](https://bugzilla.gnome.org/show_bug.cgi?id=702595)**
## Description
I'm working on playspeed support related to mpeg-ts using latest GStreamer-1.X code on Ubuntu 12.4. I have been testing with the GStreamer playspeed tutorial - "Basic tutorial 13: Playback speed" (http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+13%3A+Playback+speed). (See [Bug 694369](https://bugzilla.gnome.org/show_bug.cgi?id=694369) for code attachment and a sample mpeg2 ts file).
The tutorial fails when attempting to switch to a reverse playspeed. To demonstrate issue, enter "S" to switch from 1x to 2x playback speed. Then enter "D" option to change direction from 2x to -2x rate
I get the following error:
GStreamer-CRITICAL **: gst_segment_clip: assertion `segment->format == format' failed
0:00:39.902699443 11915 0xb5d144f0 WARN mpeg2dec gstmpeg2dec.c:474:gst_mpeg2dec_discard_buffer: Could not find buffer 1822, will be leaked until next reset
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/94[PATCH] shm: Allow caps to change in PLAYING state2021-09-24T14:32:09ZBugzilla Migration User[PATCH] shm: Allow caps to change in PLAYING state## Submitted by Joshua M. Doe
**[Link to original bug (#699352)](https://bugzilla.gnome.org/show_bug.cgi?id=699352)**
## Description
I'd like to extend shmsrc/shmsink to support changing of caps while in the PLAYING state, though I'...## Submitted by Joshua M. Doe
**[Link to original bug (#699352)](https://bugzilla.gnome.org/show_bug.cgi?id=699352)**
## Description
I'd like to extend shmsrc/shmsink to support changing of caps while in the PLAYING state, though I'm really only interested in width and height changing. A new ShmPipe command would be needed, such as COMMAND_NEW_CAPS, which would include a string set by gst_caps_to_string in shmsink. Upon shmsrc receiving this command, in 0.10 the new caps would just be set to the subsequent buffers, and in 1.0 a CAPS event would be sent. Certainly this breaks API compatibility somewhat, but this could be mitigated by adding an allow-reconfigure property to shmsink that defaults to FALSE. Is any of this reasonable?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/93shm: Port shared memory plugin to Windows2023-05-23T18:03:57ZBugzilla Migration Usershm: Port shared memory plugin to Windows## Submitted by Joshua M. Doe
**[Link to original bug (#698657)](https://bugzilla.gnome.org/show_bug.cgi?id=698657)**
## Description
I've ported shmsink and shmsrc to Windows. I've used the simplest method possible, just #ifdef'ing ...## Submitted by Joshua M. Doe
**[Link to original bug (#698657)](https://bugzilla.gnome.org/show_bug.cgi?id=698657)**
## Description
I've ported shmsink and shmsrc to Windows. I've used the simplest method possible, just #ifdef'ing code to swap out Unix sockets for TCP sockets, and to use Windows shared memory functions CreateFileMapping/MapViewOfFile instead of shm_open/mmap. Permissions are much trickier on Windows, so I've opted to #ifdef that property out. I'll attach a patch as soon as I get release approval, but before then I'd like to know if my method is acceptable.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/92videosignal ported to 1.02023-06-07T10:14:42ZBugzilla Migration Uservideosignal ported to 1.0## Submitted by Kees Blom
**[Link to original bug (#697797)](https://bugzilla.gnome.org/show_bug.cgi?id=697797)**
## Description
Created attachment 241255
patch to port videosignal to gstreamer 1.0
The elements videoanalyse, ...## Submitted by Kees Blom
**[Link to original bug (#697797)](https://bugzilla.gnome.org/show_bug.cgi?id=697797)**
## Description
Created attachment 241255
patch to port videosignal to gstreamer 1.0
The elements videoanalyse, videodetect and videomark are not yet ported to gstreamer 1.0.
As we needed these in some applications, we ported them ourselves.
We did not change names (as requested in a recent FIXME comment) nor functionality
and only tested on Linux Ubuntu 12.04 for a limit number of properties.
The resulting patch is attached. (for gst-plugin-bad as on 2013-04-11 00:00).
~~**Patch 241255**~~, "patch to port videosignal to gstreamer 1.0":
[videosignal-1.0.patch](/uploads/086bf6793d8cf2967f923cefba3977c8/videosignal-1.0.patch)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/91kate: port Kate subtitle plugin to 1.02021-09-24T14:32:08ZBugzilla Migration Userkate: port Kate subtitle plugin to 1.0## Submitted by Brendan Long
**[Link to original bug (#697071)](https://bugzilla.gnome.org/show_bug.cgi?id=697071)**
## Description
Created attachment 240329
Patch to port Kate subtitles to 1.0
I need Kate plugins to work for...## Submitted by Brendan Long
**[Link to original bug (#697071)](https://bugzilla.gnome.org/show_bug.cgi?id=697071)**
## Description
Created attachment 240329
Patch to port Kate subtitles to 1.0
I need Kate plugins to work for a project I'm working on, but it hasn't been ported yet, so I went through and did some work on it myself. The plugin seems to work with this patch, but the overlay subtitles aren't showing up, so I assume I missed something.
If I run it through a test program which attaches buffer probes to every pad, I see all of the subtitles, but they don't show up on the video.
Could someone take a look at this? I can work on it more, but I'm not sure what I'm missing.
~~**Patch 240329**~~, "Patch to port Kate subtitles to 1.0":
[0001-Port-Kate-subtitles-to-GStreamer-1.0.patch](/uploads/0be3e9b2ac199d7853454f6786da370b/0001-Port-Kate-subtitles-to-GStreamer-1.0.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/90geometrictransform: add angle property variants with degrees instead of radia...2021-09-24T14:32:07ZBugzilla Migration Usergeometrictransform: add angle property variants with degrees instead of radians as unit## Submitted by Gilbert
**[Link to original bug (#696513)](https://bugzilla.gnome.org/show_bug.cgi?id=696513)**
## Description
perceived:
a mouse over hint which says "radians" and to rotate approximately 90° I actually needed hel...## Submitted by Gilbert
**[Link to original bug (#696513)](https://bugzilla.gnome.org/show_bug.cgi?id=696513)**
## Description
perceived:
a mouse over hint which says "radians" and to rotate approximately 90° I actually needed help by a calculator
expected:
able to enter angles in degrees
comment:
I am a human and not that much into fractions of PI, srsly. thanks
Version: 1.0.6
### Blocking
* [Bug 594752](https://bugzilla.gnome.org/show_bug.cgi?id=594752)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/89Frei0r plugins expose incorrectly split properties for RGB stuff2021-09-24T14:32:07ZBugzilla Migration UserFrei0r plugins expose incorrectly split properties for RGB stuff## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#695884)](https://bugzilla.gnome.org/show_bug.cgi?id=695884)**
## Description
Created attachment 238937
screenshot
gst-inspect-1.0 frei0r-filter-white-balan...## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#695884)](https://bugzilla.gnome.org/show_bug.cgi?id=695884)**
## Description
Created attachment 238937
screenshot
gst-inspect-1.0 frei0r-filter-white-balance
Yields the following element properties besides name, parent, qos:
neutral-color-r : Choose a color from the source image that should be white.
flags: readable, writable, controllable
Float. Range: 0 - 1 Default: 1
neutral-color-g : Choose a color from the source image that should be white.
flags: readable, writable, controllable
Float. Range: 0 - 1 Default: 1
neutral-color-b : Choose a color from the source image that should be white.
flags: readable, writable, controllable
Float. Range: 0 - 1 Default: 1
green-tint : Adjust the level of green.
flags: readable, writable, controllable
Double. Range: 0 - 1 Default: 1.2
Looking at frei0r's balanc0r.c, I see only one single "neutral-color" property. I can guess that GStreamer somehow split that property into three.
The problem is that the description incorrectly stays the same for all three virtual properties, so when you display them in a GUI like pitivi, the descriptions are all identical.
What's worse however is that in pitivi (and this is both in 0.10 and 1.x git), the property "names" that are exposed to us by gstreamer are somehow incorrect, as the attached screenshot demonstrates: instead of "Neutral R color value", "Neutral G color value", "Neutral B color value", you get only "Neutral Color:" shown twice and one "Neutral Color-R:"
Not only that, the actual value prop boundaries don't seem to make sense. If my understanding of the gst inspect output above is correct, it goes from 0.0 to 1.0... but RGB would be 0 to 255 each, no?
This is not necessarily specific to frei0r's white balance filter, various other frei0r filters seem to be affected in similar ways, especially when it comes to the naming of human-readable properties names, or descriptions being missing. Is there a central place where you are overriding frei0r's strings somewhere in gstreamer?
~~**Attachment 238937**~~, "screenshot":
![Capture_du_2013-03-14_18_01_18](/uploads/fc47b753c42e639c0fd0f5c8ea6b18c4/Capture_du_2013-03-14_18_01_18.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/87h264parser: Parse the cropping-rectangle separately.2021-09-24T14:32:07ZBugzilla Migration Userh264parser: Parse the cropping-rectangle separately.## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#694068)](https://bugzilla.gnome.org/show_bug.cgi?id=694068)**
## Description
Created attachment 236561
h264parser: Parse the cropping-rectangle separately.
...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#694068)](https://bugzilla.gnome.org/show_bug.cgi?id=694068)**
## Description
Created attachment 236561
h264parser: Parse the cropping-rectangle separately.
The h264parser should parse the cropping rectangle separately. Because we have to pass the cropping rectangle to the renderer instead of using the cropped-values for decoding.Which means the width and height of SPS header will be un-cropped dimensions.
example case: many of the 1920x1088 samples of h264 have 8 padding lines to make the height as a multiple of 16. The actual picture dimension will be 1920x1080.
**Patch 236561**, "h264parser: Parse the cropping-rectangle separately.":
[0001-h264parser-Parse-the-cropping-rectangle-separately.patch](/uploads/0bb9e99f870fdb25bb0adcf7f295d71b/0001-h264parser-Parse-the-cropping-rectangle-separately.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/86bayer: Caps for 16-bit Bayer2023-06-15T13:02:29ZBugzilla Migration Userbayer: Caps for 16-bit Bayer## Submitted by Joshua M. Doe
**[Link to original bug (#693666)](https://bugzilla.gnome.org/show_bug.cgi?id=693666)**
## Description
Currently in both 0.10 and 1.0 the caps for Bayer are limited to 8-bits, however 16-bit is quite co...## Submitted by Joshua M. Doe
**[Link to original bug (#693666)](https://bugzilla.gnome.org/show_bug.cgi?id=693666)**
## Description
Currently in both 0.10 and 1.0 the caps for Bayer are limited to 8-bits, however 16-bit is quite common, and I've seen 12-bit as well. I have seen three different ways to extend this to at least 16-bit:
1) I have used video/x-raw-bayer,format=(string){gbrg16, bggr16, grbg16, rggb16} so as to not conflict with the current expectation of 8-bit data from bayer2rgb and rgb2bayer. Alternatively, something like video/x-raw-bayer16 could work as well, if not an elegant solution.
2) gst-plugins-elphel has a "bpp" property in their bayer2rgb2 element which when true assumes the data to be 16-bit, otherwise 8-bit:
http://code.google.com/p/gst-plugins-elphel/source/browse/trunk/bayer2rgb2/src/gstbayer2rgb2.c#267
3) Aravis simply adds bpp and depth to the video/x-raw-bayer caps:
http://git.gnome.org/browse/aravis/tree/src/arvmisc.c#n635
`
#2` is clearly not a good solution since it moves the bpp out of the caps.` #3` is the most robust solution, though it would mean some applications would break, though if supporting elements always prioritize bpp=8,depth=8, then breakage would be minimal I believe. If changing the existing caps are unacceptable, then we'd have to go with` #1`.1.23.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/85New plugin for MPEG TS time shifting2018-11-05T10:23:17ZBugzilla Migration UserNew plugin for MPEG TS time shifting## Submitted by Krzysztof Konopko
**[Link to original bug (#692397)](https://bugzilla.gnome.org/show_bug.cgi?id=692397)**
## Description
Created attachment 234220
Proposed implementation
tstimeshift: New plugin for MPEG TS ti...## Submitted by Krzysztof Konopko
**[Link to original bug (#692397)](https://bugzilla.gnome.org/show_bug.cgi?id=692397)**
## Description
Created attachment 234220
Proposed implementation
tstimeshift: New plugin for MPEG TS time shifting
This is an initial proposal. I'd like to ask for any help, views, suggestions and directions.
The plugin is base on Fluendo timeshift element [1] although quite substantially changed. The proposed code is maintained on GitHub [2]. The gsttstimeshift comprises several elements that can be used for MPEG TS time shifting:
tsshifter : Time Shift for MPEG TS streams
tsshifterbin : Time Shift + TS parser for MPEG TS streams
tsseeker : Time Shift seeker
tsindexer : Indexer for MPEG-TS streams
A typical pipeline that makes use of them would look like:
`<some MPEG TS src>` ! tsshifterbin ! `<some MPEG TS sink>`
The tsshifterbin element will instantiate elements as follows:
tsparse ! tsindexer ! tsshifter ! tsseeker
and prepare tsindexer ("tune" it to look for the right PID containing PCRs).
Potentially tsshifter can be replaced with queue2 (see the problems below) and this is actually one of the goals.
Problems still to be considered/solved/improved:
---------------------------------------
- naming
Both tsindexer and tsseeker are supposed to be MPEG TS agnostic but ATM they are TS specific, hence their names.
Also the tsshifter is actually a ring buffer.
- tsindexer
* uses overengineered for this use case and abandoned GstIndex API (local copy)
* can't remove index entries
* can't write the index to the disk
* duplicates parsing TS packets logic from tsparse
tsparse would have to be improved to send some additional timestamp information (e. g. as tags or as buffer timestamps) so that the indexer could pick them up. The indexer itself could be a generic component (no knowledge about TS packets), hard to come up with the right format though.
- tsindexer and tsseeker share an index object while it should be shared through some index database
- tsshifter
* it's actually a ring buffer, not a shifter (see naming notes above)
* ideally it should be replaced with queue2
* as a first attempt, replacement could be optional (both tsshifter and queue2 co-exist)
There are still some issues when using queue2 instead of tsshifter that have to be solved.
* as a goal tsshifter could be completely replaced with queue2 which might require some changes/improvements of the latter:
* custom allocator can be used (see FileMemAllocator: https://bugzilla.gnome.org/show_bug.cgi?id=691299)
- tests still to be written
- documentation
[1] https://github.com/kkonopko/gst-fluendo-timeshift
[2] https://github.com/kkonopko/gst-plugins-bad/tree/ts-timeshifter-element
**Patch 234220**, "Proposed implementation":
[0001-tstimeshift-New-plugin-for-MPEG-TS-time-shifting.patch](/uploads/bc023c5128ab9309e8ac13904b038774/0001-tstimeshift-New-plugin-for-MPEG-TS-time-shifting.patch)
### See also
* [Bug 691299](https://bugzilla.gnome.org/show_bug.cgi?id=691299)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/84[API] codecparsers: add GstMetas to pass parsing results downstream2021-09-24T14:32:06ZBugzilla Migration User[API] codecparsers: add GstMetas to pass parsing results downstream## Submitted by Tim Müller `@tpm`
**[Link to original bug (#691712)](https://bugzilla.gnome.org/show_bug.cgi?id=691712)**
## Description
Some work-in-progress here:
http://cgit.freedesktop.org/~bilboed/gst-plugins-bad/log/
##...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#691712)](https://bugzilla.gnome.org/show_bug.cgi?id=691712)**
## Description
Some work-in-progress here:
http://cgit.freedesktop.org/~bilboed/gst-plugins-bad/log/
### Blocking
* [Bug 689562](https://bugzilla.gnome.org/show_bug.cgi?id=689562)
* [Bug 734547](https://bugzilla.gnome.org/show_bug.cgi?id=734547)