GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2018-11-04T10:15:08Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/88RTSP pipeline freezes when set to a resume after a pause (PLAYING->PAUSED->PL...2018-11-04T10:15:08ZBugzilla Migration UserRTSP pipeline freezes when set to a resume after a pause (PLAYING->PAUSED->PLAYING), with Jitterbuffer in Buffering Mode## Submitted by vfu..@..ia.com
**[Link to original bug (#705355)](https://bugzilla.gnome.org/show_bug.cgi?id=705355)**
## Description
The RTP timestamp gap induced (nearly equal to the time the server/source has spent in PAUSED stat...## Submitted by vfu..@..ia.com
**[Link to original bug (#705355)](https://bugzilla.gnome.org/show_bug.cgi?id=705355)**
## Description
The RTP timestamp gap induced (nearly equal to the time the server/source has spent in PAUSED state), currently makes the jitter-buffer completely reset itself. This leads to freezing of the pipeline, due to the RTP-TS difference (equal to the time spent in PAUSED state) between the first RTP packet received after the the source/server has been set to PLAYING and the packet that was last received during the PAUSED state. This leads to a huge gap (TS discontinuity) between the first outgoing buffer from the jitter-buffer post-PAUSED (PLAYING before PAUSED) state and the last buffer that was sent pre-PAUSED (PLAYING after PAUSED) state. This leads to a long halt at the sink depending upon the time spent in PAUSED state . i.e long freeze of the pipeline.
Version: 1.1.3https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/11Check test suite fails on Windows2018-11-04T10:15:20ZBugzilla Migration UserCheck test suite fails on Windows## Submitted by Lubosz Sarnecki
**[Link to original bug (#706586)](https://bugzilla.gnome.org/show_bug.cgi?id=706586)**
## Description
Created attachment 252754
Log of make check (2 tests running separately)
The tests have to...## Submitted by Lubosz Sarnecki
**[Link to original bug (#706586)](https://bugzilla.gnome.org/show_bug.cgi?id=706586)**
## Description
Created attachment 252754
Log of make check (2 tests running separately)
The tests have to be run with CK_FORK=no, otherwise 14 of 15 tests fail.
$ CK_FORK=no make check
This is a problem of all gstreamer test suites
https://bugzilla.gnome.org/show_bug.cgi?id=697693
The test suite does not finish, because 2 tests freeze (project and mixers). The suite does not kill them after a timeout. They have to be removed manually from check_PROGRAMS in tests/check/Makefile.
* mixer test completes with 100%, but does not terminate.
* project test freezes after complaining about parser errors and freezes before showing the score.
Without the freezing tests, the test suite completes with "3 of 13 tests failed".
The failing tests are basic, uriclip and timelineedition.
* basic crashes in glib, as described in this bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=706584
* uriclip prints errors and crashes at ges/uriclip.c:150
* timelineedition has an critical error
Unexpected critical/warning: g_object_set_valist: object class `GESCustomSourceClip' has no property named `'(((GESTimelineElement*)trackelement2)->duration)' (%I64u) is not equal to '60' (%I64u)'
There are tests that have errors but do not fail:
* layer has a gnonlin error
gnlcomposition gnlcomposition.c:2293:compare_relink_single_node: Not enough sinkpads to link all objects to the operation ! 2 / 1
* simplelayer has ges errors
ges ges-simple-layer.c:226:gstl_recalculate: two transitions in sequence!
ges ges-simple-layer.c:248:gstl_recalculate: 0, 500000000: overlapping transitions!
* transition has a gnonlin error
gnlcomposition gnlcomposition.c:2295:compare_relink_single_node: Operation has no child objects to be connected to !!!
So i would say 8 out of 15 fail ;)
**Attachment 252754**, "Log of make check (2 tests running separately)":
[make-check.log](/uploads/8a02505049fb4a43dcbdb044cd3344f1/make-check.log)
### Depends on
* [Bug 712724](https://bugzilla.gnome.org/show_bug.cgi?id=712724)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/92qtdemux: add support for webvtt subtitles2018-11-04T10:16:25ZBugzilla Migration Userqtdemux: add support for webvtt subtitles## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#707032)](https://bugzilla.gnome.org/show_bug.cgi?id=707032)**
## Description
Add support for WebVTT subtitles## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#707032)](https://bugzilla.gnome.org/show_bug.cgi?id=707032)**
## Description
Add support for WebVTT subtitleshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/95souphttpsrc: Need ability to exclude HTTP Range header and set content size2018-11-04T10:16:33ZBugzilla Migration Usersouphttpsrc: Need ability to exclude HTTP Range header and set content size## Submitted by Lori Anderson
**[Link to original bug (#709117)](https://bugzilla.gnome.org/show_bug.cgi?id=709117)**
## Description
Need to be able to disable the inclusion of the range header by souphttpsrc. The HTTP Range header ...## Submitted by Lori Anderson
**[Link to original bug (#709117)](https://bugzilla.gnome.org/show_bug.cgi?id=709117)**
## Description
Need to be able to disable the inclusion of the range header by souphttpsrc. The HTTP Range header is not allowed for dtcp encyrpted content. Also the HTTP Range header interferes with the usage of TimeSeekRange.dlna.org and Playspeed.dlna.org headers. The Range header should not be included when these other headers are added or for dtcp encrypted content. The proper headers will be added by the dlnasrc element which is a "manager" type element and will set the "exclude-range-header" property on souphttpsrc. The souphttpsrc will still use the starting byte position and all the same logic should be performed by souphttpsrc and basesrc,
The attached patch creates a boolean property "exclude-range-header" which specifies if the Range header should be included. The default is false. When false, souphttpsrc will include the Range header as it does currently. When this property is set to true, souphttpsrc will formulate the HTTP request as it does now except it will not include the Range header. It will be the responsibility of the dlnasrc "manager" element to do this.
If the HTTP Range header is not included, souphttpsrc will not be able to determine the size of the content. The ability to set the content size is needed when the Range header is not included. This patch adds the ability to set the content size through the "content-size" property. The dlnasrc "manager" element will set the size as necessary such as for dtcp/ip encrypted content.
Version: 1.x
### Blocking
* [Bug 709455](https://bugzilla.gnome.org/show_bug.cgi?id=709455)https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/4Example demonstrating segmenting a video stream every X keyframes and saving ...2018-11-04T10:17:12ZBugzilla Migration UserExample demonstrating segmenting a video stream every X keyframes and saving it to disk## Submitted by xlinkz0
**[Link to original bug (#724643)](https://bugzilla.gnome.org/show_bug.cgi?id=724643)**
## Description
As __tim must surely be relieved that i finally achieved this and will not pester him so much about block...## Submitted by xlinkz0
**[Link to original bug (#724643)](https://bugzilla.gnome.org/show_bug.cgi?id=724643)**
## Description
As __tim must surely be relieved that i finally achieved this and will not pester him so much about blocking probes ( atleast for a while.. ), I present to you my masterpiece, my greatest achievement since modifying the ffmpeg tool to be a function inside a library.
As the title says, this is a simple example that cuts a video stream ( i only tested the general principles on h264 and raw yuv streams ) into multiple files each 'numframes' key-frames.
I still don't know for sure why it works so I'll ask some questions here if anyone cares to answer..
Does the tee save the h264 header to be sent to new dynamic elements?
It doesn't lose frames right now from the tests i conducted but should i send FLUSH_START on the tee, block events on the tee's src-pad and only then link the new sink?
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/109souphttpsrc: add support to disconnect on playing->paused transition2018-11-04T10:17:32ZBugzilla Migration Usersouphttpsrc: add support to disconnect on playing->paused transition## Submitted by Branislav Katreniak
**[Link to original bug (#724786)](https://bugzilla.gnome.org/show_bug.cgi?id=724786)**
## Description
We implement playback from Pandora music service. The complication is that Pandora has hard r...## Submitted by Branislav Katreniak
**[Link to original bug (#724786)](https://bugzilla.gnome.org/show_bug.cgi?id=724786)**
## Description
We implement playback from Pandora music service. The complication is that Pandora has hard requirement to disconnect the http connection on playing -> paused transition.
Is such functionality interesting upstream?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/147dashdemux: max-bitrate is not applied2018-11-04T10:20:29ZBugzilla Migration Userdashdemux: max-bitrate is not applied## Submitted by Davide Bertola
**[Link to original bug (#730192)](https://bugzilla.gnome.org/show_bug.cgi?id=730192)**
## Description
Created attachment 276603
Proposed solution
max-bitrate paramenter is not used in dashdemux...## Submitted by Davide Bertola
**[Link to original bug (#730192)](https://bugzilla.gnome.org/show_bug.cgi?id=730192)**
## Description
Created attachment 276603
Proposed solution
max-bitrate paramenter is not used in dashdemux adaptation logic.
I think it's supposed to set an upper limit to the estimated channel bitrate used for finding the most appropriate representation during playback. This way dashdemux would never select representations with bitrate higher than "max-bitrate".
**Patch 276603**, "Proposed solution":
[0001-dashdemux-use-max-bitrate-to-limit-bandwidth.patch](/uploads/8681ad7461768daabd1a3b2c6b4fd5a5/0001-dashdemux-use-max-bitrate-to-limit-bandwidth.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/61pluginscanner: Selinux enhanced file rights not handled correctly2018-11-04T10:22:14ZBugzilla Migration Userpluginscanner: Selinux enhanced file rights not handled correctly## Submitted by kas..@..ain.de
**[Link to original bug (#733001)](https://bugzilla.gnome.org/show_bug.cgi?id=733001)**
## Description
Following steps to reproduce
1. Installing Fluendo Code package
2. Enable Selinux
3. run gst...## Submitted by kas..@..ain.de
**[Link to original bug (#733001)](https://bugzilla.gnome.org/show_bug.cgi?id=733001)**
## Description
Following steps to reproduce
1. Installing Fluendo Code package
2. Enable Selinux
3. run gst-inspect-1.0
4. now all newy added codecs are blacklisted because we have not relabled the new installation
5. Disable Selinux
6. run gst-inspect will not change anything because files are unchanged and already on blacklist
Only deleting the registry would help.
Correct handling would be in
gst/gstregistry.c in function gst_registry_scan_path_level
and add in the checks for regular file
if (access(filename,X_OK)!=0) {
GST_TRACE_OBJECT (context->registry, "%s file status SeLinux executable file, ignoring",
filename);
g_free (filename);
continue;
}
So we check if the file is executable ( normal file rights and SeLinux). If not executable we just ignore it.
Tested on Linux it is working.https://gitlab.freedesktop.org/gstreamer/www/-/issues/4GStreamer: artwork2018-11-04T10:24:21ZBugzilla Migration UserGStreamer: artwork## Submitted by ArtBoy
**[Link to original bug (#733812)](https://bugzilla.gnome.org/show_bug.cgi?id=733812)**
## Description
Created attachment 281807
GStreamer logos (zip archive of eps files)
I just ran across the old .eps...## Submitted by ArtBoy
**[Link to original bug (#733812)](https://bugzilla.gnome.org/show_bug.cgi?id=733812)**
## Description
Created attachment 281807
GStreamer logos (zip archive of eps files)
I just ran across the old .eps GStreamer logo files I created back in the RidgeRun days. They can be added (at long, long last) to the GStreamer art page.
Here is the file names and descriptions:
logoGstreamer.eps : GStreamer logo
logoGstreamerK.eps : GStreamer logo (for use on dark backgrounds)
logoGstreamerText.eps : GStreamer logo with "open source multimedia framework" text
logoGstreamerTextK.eps : GStreamer logo with "open source multimedia framework" text (for use on dark backgrounds)
The files above are dated 2002-02-23! They are attached to this bug as a ZIP archive.
-Brock
**Attachment 281807**, "GStreamer logos (zip archive of eps files)":
[logoGstreamerEPS.zip](/uploads/8d2ee84b4a32f538c472bf129bf3beb3/logoGstreamerEPS.zip)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/126videobox: Much slower than videocrop2018-11-04T10:24:44ZBugzilla Migration Uservideobox: Much slower than videocrop## Submitted by Stirling Westrup
**[Link to original bug (#734679)](https://bugzilla.gnome.org/show_bug.cgi?id=734679)**
## Description
I have an application that needs to do both video cropping and padding and which works with 4K v...## Submitted by Stirling Westrup
**[Link to original bug (#734679)](https://bugzilla.gnome.org/show_bug.cgi?id=734679)**
## Description
I have an application that needs to do both video cropping and padding and which works with 4K videos. We chose videobox for the task because its the only element that does reasonable padding and the fact that it can also crop was a major bonus.
However, in time trials we've found that videobox is much, MUCH slower than videocrop, even when its just cropping. For example, using gstreamer 1.4.0, this pipeline runs on a stock ivy-bridge server driving a SMSC zero client display at about 45 fps:
gst-launch-1.0 -v filesrc location=Sintel-4K.mkv ! decodebin ! videoconvert ! videocrop left=100 ! videoscale ! fpsdisplaysink sync=false video-sink="xvimagesink display=:2"
The same pipeline, with videobox used instead of videocrop gives us an average of about 20 fps, which is a huge drop. Worse the video in question is 24 fps, so with videobox we cannot play realtime without dropping frames.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/75basesink: preroll issue for some clips which audio is shorter than video2018-11-04T10:25:07ZBugzilla Migration Userbasesink: preroll issue for some clips which audio is shorter than video## Submitted by kevin
**[Link to original bug (#736655)](https://bugzilla.gnome.org/show_bug.cgi?id=736655)**
## Description
I have some clips which audio is shorter than video. The player can't change state from PLAYING to PAUSE st...## Submitted by kevin
**[Link to original bug (#736655)](https://bugzilla.gnome.org/show_bug.cgi?id=736655)**
## Description
I have some clips which audio is shorter than video. The player can't change state from PLAYING to PAUSE state after audio is finish and video is playing. The root cause is audio sink hasn't received GAP event and can't finish preroll and video sink changed to PAUSE state.
It is ok if send EOS when audio finish, but streamsynchronizer send GAP event. I haven't seem streamsynchronizer send GAP event when player change state from PLAYING to PAUSE state.
Can give me some advice or do you need more information?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/177mpegts : add new descriptors and cleanup2018-11-04T10:25:29ZBugzilla Migration Usermpegts : add new descriptors and cleanup## Submitted by cha..@..il.com
**[Link to original bug (#738033)](https://bugzilla.gnome.org/show_bug.cgi?id=738033)**
## Description
Some cleanup to better follow specifications
Numerous descriptors added like metadata
Split so...## Submitted by cha..@..il.com
**[Link to original bug (#738033)](https://bugzilla.gnome.org/show_bug.cgi?id=738033)**
## Description
Some cleanup to better follow specifications
Numerous descriptors added like metadata
Split some files and clean them
Should apply to 1.5 branch without problem
Any reviewer ?
Version: 1.4.3
### Blocking
* [Bug 738034](https://bugzilla.gnome.org/show_bug.cgi?id=738034)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/182Add demuxer/parser for Apple's Core Audio Format (CAF)2018-11-04T10:26:24ZBugzilla Migration UserAdd demuxer/parser for Apple's Core Audio Format (CAF)## Submitted by Peter G. Baum
**[Link to original bug (#738538)](https://bugzilla.gnome.org/show_bug.cgi?id=738538)**
## Description
Created attachment 288536
Patch to implement a CAF parser
CAF is Apple's core audio format. ...## Submitted by Peter G. Baum
**[Link to original bug (#738538)](https://bugzilla.gnome.org/show_bug.cgi?id=738538)**
## Description
Created attachment 288536
Patch to implement a CAF parser
CAF is Apple's core audio format.
https://developer.apple.com/library/mac/#documentation/MusicAudio/Reference/CAFSpec/CAF_overview/CAF_overview.html#//apple_ref/doc/uid/TP40001862-CH209-TPXREF101
It is of course very common in the Apple world.
It can be seen as an enhanced WAV format.
Unlike WAV it has for example no limitation to the file length.
It is therefor also useful to use it on other platforms.
~~**Patch 288536**~~, "Patch to implement a CAF parser":
[0001-audioparsers-add-parser-for-CAF.patch](/uploads/093a6d31b842c41f99efb7c203a4ee5f/0001-audioparsers-add-parser-for-CAF.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/390dvbsrc cannot switch from HD to SD or SD to HD channels2018-11-04T12:45:26ZBugzilla Migration Userdvbsrc cannot switch from HD to SD or SD to HD channels## Submitted by Russel Winder `@Russel`
**[Link to original bug (#766501)](https://bugzilla.gnome.org/show_bug.cgi?id=766501)**
## Description
Using GStreamer and all plugins built from source as at 2016-05-16T05:30+01:00 using play...## Submitted by Russel Winder `@Russel`
**[Link to original bug (#766501)](https://bugzilla.gnome.org/show_bug.cgi?id=766501)**
## Description
Using GStreamer and all plugins built from source as at 2016-05-16T05:30+01:00 using playbin to create a dvbsrc pipeline allows for SD or HD channels to be played. Switching between SD channels is fine. Switching between HD channels is fine. However trying to switch from SD to HD or from HD to SD causes an immediate tuning fail and pipeline crash.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/96queue2: incorrect current-level-time reported after seek (with packetized data)2018-11-05T08:29:36ZBugzilla Migration Userqueue2: incorrect current-level-time reported after seek (with packetized data)## Submitted by Aleksander Wabik
**[Link to original bug (#744587)](https://bugzilla.gnome.org/show_bug.cgi?id=744587)**
## Description
Created attachment 296913
The testcase
Steps to reproduce the bug:
1) Have a queue2 ...## Submitted by Aleksander Wabik
**[Link to original bug (#744587)](https://bugzilla.gnome.org/show_bug.cgi?id=744587)**
## Description
Created attachment 296913
The testcase
Steps to reproduce the bug:
1) Have a queue2 element,
2) Send SEGMENT (GST_FORMAT_TIME) event with non-zero start/position/time.
3) Start pushing buffers with PTSes starting at 0 to the queue.
Effects:
1) As soon the queue obtains buffers with valid in-segment PTS, it reports buffered time level correctly,
2) As soon the queue pushes first buffer with PTS < segment.start to the srcpad, the queue stops reporting buffered time level correctly, it reports 0 buffered.
This is caused by rewriting src_segment.position with buffer's PTS, and then gst_segment_to_running_time() returns GST_CLOCK_TIME_NONE.
At this point, if we have a very fast source element, and a very slow decoder, the decoder may block on the first frame (with PTS below segment start) for quite a long time (especially if it's a software decoder decoding 1080p HEVC or VP9 frame). In this time, the queue reports current-level-time == 0, and what's worse, if the queue has buffer & byte limits 0, and only the time limit set, fast source may push megabytes of data, tens of seconds of data, even though the limit may be 0.5 seconds. The queue will not block, as it thinks it's 0% filled.
Additional bug (fixed by the same fix): some streams have non-monotonic PTSes. Push buffer with PTS=1s, duration=1s, and then push buffer with PTS=0s, duration=1s. The queue has now 2 seconds of data buffered, but it will report only one second.
I am attaching the extended unit tests for queue2 element that demonstrate both these problems.
~~**Patch 296913**~~, "The testcase":
[patch1-queue2-testcase.patch](/uploads/45ddd0f507d0096b9ec0cbeea377265c/patch1-queue2-testcase.patch)https://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-good/-/issues/145avidemux doesn't set PTS on keyframes when operating in push mode2018-11-05T10:55:42ZBugzilla Migration Useravidemux doesn't set PTS on keyframes when operating in push mode## Submitted by Maroš Ondrášek
**[Link to original bug (#740961)](https://bugzilla.gnome.org/show_bug.cgi?id=740961)**
## Description
1.pull mode(PTS written on KF):
gst-launch-1.0 -v filesrc location='/tmp/xvid_packed_AS.avi' ...## Submitted by Maroš Ondrášek
**[Link to original bug (#740961)](https://bugzilla.gnome.org/show_bug.cgi?id=740961)**
## Description
1.pull mode(PTS written on KF):
gst-launch-1.0 -v filesrc location='/tmp/xvid_packed_AS.avi' !avidemux!fakesink silent=false
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2486 bytes, dts: 0:00:00.000000000, pts: 0:00:00.000000000, duration: 0:00:00.040000000, offset: 0, offset_end: 1, flags: 00000040 discont ) 0x76b02840
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (125 bytes, dts: 0:00:00.040000000, pts: none, duration: 0:00:00.040000000, offset: 1, offset_end: 2, flags: 00002000 delta-unit ) 0x76b02a20
....
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (6576 bytes, dts: 0:00:04.400000000, pts: none, duration: 0:00:00.040000000, offset: 110, offset_end: 111, flags: 00002000 delta-unit ) 0x76b02c00
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (25142 bytes, dts: 0:00:04.440000000, pts: 0:00:04.440000000, duration: 0:00:00.040000000, offset: 111, offset_end: 112, flags: 00000000 ) 0x76b02d40
2.push mode(PTS not written on KF):
gst-launch-1.0 -v souphttpsrc location='https://dl.dropboxusercontent.com/u/38760017/xvid_packed_AS.avi' !queue2!avidemux!fakesink silent=false
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (2486 bytes, dts: 0:00:00.000000000, pts: none, duration: 0:00:00.040000000, offset: 0, offset_end: 1, flags: 00004040 discont tag-memory ) 0x75b02140
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (125 bytes, dts: 0:00:00.040000000, pts: none, duration: 0:00:00.040000000, offset: 1, offset_end: 2, flags: 00004000 tag-memory ) 0x75b02000
....
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (6576 bytes, dts: 0:00:04.400000000, pts: none, duration: 0:00:00.040000000, offset: 110, offset_end: 111, flags: 00000000 ) 0x74933a30
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (25142 bytes, dts: 0:00:04.440000000, pts: none, duration: 0:00:00.040000000, offset: 111, offset_end: 112, flags: 00000000 ) 0x75c02320
Our HW decoder expects PTS to be written on keyframes when dealing with mpeg4 part2 codecs, but when avidemux operates in PUSH mode, there is no PTS available so playback doesn't work.
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/38GESTimelineElement has some collisions between virtual methods and invokers2018-11-05T11:58:23ZBugzilla Migration UserGESTimelineElement has some collisions between virtual methods and invokers## Submitted by Corentin Noël `@tintou`
**[Link to original bug (#796490)](https://bugzilla.gnome.org/show_bug.cgi?id=796490)**
## Description
To make Vala happy, the invoker and virtual functions have to have to same prototype.
H...## Submitted by Corentin Noël `@tintou`
**[Link to original bug (#796490)](https://bugzilla.gnome.org/show_bug.cgi?id=796490)**
## Description
To make Vala happy, the invoker and virtual functions have to have to same prototype.
Here for GESTimelineElement, a possible approach would be to add a `gboolean` as return type of the invokers
The virtual methods:
```
gboolean (*set_start) (GESTimelineElement * self, GstClockTime start);
gboolean (*set_inpoint) (GESTimelineElement * self, GstClockTime inpoint);
gboolean (*set_duration) (GESTimelineElement * self, GstClockTime duration);
gboolean (*set_max_duration) (GESTimelineElement * self, GstClockTime maxduration);
gboolean (*set_priority) (GESTimelineElement * self, guint32 priority);
```
The invokers:
```
GES_API
void ges_timeline_element_set_start (GESTimelineElement *self, GstClockTime start);
GES_API
void ges_timeline_element_set_inpoint (GESTimelineElement *self, GstClockTime inpoint);
GES_API
void ges_timeline_element_set_duration (GESTimelineElement *self, GstClockTime duration);
GES_API
void ges_timeline_element_set_max_duration (GESTimelineElement *self, GstClockTime maxduration);
GES_API
void ges_timeline_element_set_priority (GESTimelineElement *self, guint32 priority);
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/772decklinkvideosrc: Respect pixel format property even if mode is set to auto2018-11-05T14:16:33ZBugzilla Migration Userdecklinkvideosrc: Respect pixel format property even if mode is set to auto## Submitted by Joshua M. Doe
**[Link to original bug (#796979)](https://bugzilla.gnome.org/show_bug.cgi?id=796979)**
## Description
I got hung up for several hours trying to debug why I couldn't get 10-bit YUV (v210) from an SDI so...## Submitted by Joshua M. Doe
**[Link to original bug (#796979)](https://bugzilla.gnome.org/show_bug.cgi?id=796979)**
## Description
I got hung up for several hours trying to debug why I couldn't get 10-bit YUV (v210) from an SDI source via a Decklink Extreme 12G card. Turns out 8-bit YUV will always be used if the mode is set to AUTO. Eventually I noticed a warning about this issued in gstdecklinkvideosrc.cpp:1221, "Warning: mode=auto and format!=auto may not work" (I know, I should have noticed this warning in the debug output sooner).
I created a patch which seems to fix this, and might hopefully save future users some frustrationhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/456gst-libs sdp: Function cast warnings in GCC 82018-11-05T14:44:09ZBugzilla Migration Usergst-libs sdp: Function cast warnings in GCC 8## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#796230)](https://bugzilla.gnome.org/show_bug.cgi?id=796230)**
## Description
/home/fraxinas/gst/master/gst-plugins-base/gst-libs/gst/sdp/gstsdpmessage.h: In functi...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#796230)](https://bugzilla.gnome.org/show_bug.cgi?id=796230)**
## Description
/home/fraxinas/gst/master/gst-plugins-base/gst-libs/gst/sdp/gstsdpmessage.h: In function 'glib_listautoptr_cleanup_GstSDPMessage':
/usr/include/glib-2.0/glib/gmacros.h:462:99: warning: cast between incompatible function types from 'GstSDPResult (*)(GstSDPMessage *)' {aka 'enum `<anonymous>` (*)(struct `<anonymous>` *)'} to 'void (*)(void *)' [-Wcast-function-type]
static inline void _GLIB_AUTOPTR_LIST_FUNC_NAME(TypeName) (GList **_l) { g_list_free_full (*_l, (GDestroyNotify) func); } \
`^`
/home/fraxinas/gst/master/gst-plugins-base/gst-libs/gst/sdp/gstsdpmessage.h:756:1: note: in expansion of macro 'G_DEFINE_AUTOPTR_CLEANUP_FUNC'
G_DEFINE_AUTOPTR_CLEANUP_FUNC(GstSDPMessage, gst_sdp_message_free)
`^`~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/fraxinas/gst/master/gst-plugins-base/gst-libs/gst/sdp/gstsdpmessage.h: In function 'glib_slistautoptr_cleanup_GstSDPMessage':
/usr/include/glib-2.0/glib/gmacros.h:463:102: warning: cast between incompatible function types from 'GstSDPResult (*)(GstSDPMessage *)' {aka 'enum `<anonymous>` (*)(struct `<anonymous>` *)'} to 'void (*)(void *)' [-Wcast-function-type]
static inline void _GLIB_AUTOPTR_SLIST_FUNC_NAME(TypeName) (GSList **_l) { g_slist_free_full (*_l, (GDestroyNotify) func); } \
`^`
/home/fraxinas/gst/master/gst-plugins-base/gst-libs/gst/sdp/gstsdpmessage.h:756:1: note: in expansion of macro 'G_DEFINE_AUTOPTR_CLEANUP_FUNC'
G_DEFINE_AUTOPTR_CLEANUP_FUNC(GstSDPMessage, gst_sdp_message_free)
`^`~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This happens after upgrading from gcc 7.3.1+20180406-1 to 8.1.0-1
From https://gcc.gnu.org/gcc-8/changes.html
-Wcast-function-type warns when a function pointer is cast to an incompatible function pointer. This warning is enabled by -Wextra.
1.4.0, 1.4.1 and master are all affected.
### Depends on
* [Bug 796237](https://bugzilla.gnome.org/show_bug.cgi?id=796237)