gst-plugins-ugly issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues2023-06-27T23:17:23Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/13rmdemux: REAL Media File make system Hang <gst_rmdemux_chain:Bogus looking he...2023-06-27T23:17:23ZBugzilla Migration Userrmdemux: REAL Media File make system Hang <gst_rmdemux_chain:Bogus looking header, unprintable FOURCC>## Submitted by Orange Ashu
**[Link to original bug (#755723)](https://bugzilla.gnome.org/show_bug.cgi?id=755723)**
## Description
Hello,
I were checking the GST-Real media Parser code and found that one clip (Test file) makes...## Submitted by Orange Ashu
**[Link to original bug (#755723)](https://bugzilla.gnome.org/show_bug.cgi?id=755723)**
## Description
Hello,
I were checking the GST-Real media Parser code and found that one clip (Test file) makes my system Hangs (Windows x86, Linux, Win CE etc).
this problem for the video file is present from GST 0.1 to Even in GST 1.6. please help to guide me which part of code can be debugged further for the same.
>1: Test clip run command
gst-launch-1.0 --gst-debug-level=5 playbin uri=file:///D:/11_OnePiece_RV4.rmvb
>2: Test clip source file
Will attach somewhere and share the location in comment later on this bug.
>3: Logs with Debug level 5
Attached.
>4: My Analysis:
a. Test real media clip headers are correct.
I checked each and every information and links (including size and other details for all Types of FOURCC.
b. While decoding, it detects [.RMF, PROP , MDPR , MDPR, MDPR, CONT] correctly next available FOURCC is "DATA", which were never detected.
c. This file i am able to play on lots of other frameworks and plateform (VLC (Win/ Linux), Android devices etc.).
Logs analysis is as below (Line# 97156)
----
0:00:05.198350818 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 858, length 31, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.198403458 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 858 length 31, time 0
0:00:05.198453449 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 005683F0, maxsize:34 offset:0 size:31
0:00:05.198512048 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.198562370 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.198611699 6904 0F7AEA08 DEBUG default rmutils.c:83:gst_rm_utils_read_tags: File Content : (CONT) len = 31
0:00:05.198662022 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: title =
0:00:05.198718965 6904 0F7AEA08 DEBUG default rmutils.c:104:gst_rm_utils_read_tags: converting tag from CP1252 to UTF-8
0:00:05.198790807 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: artist = û¤·¤ÎZHU
0:00:05.198845433 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: copyright = bbs.jumpcn.com
0:00:05.198896418 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: comment =
0:00:05.198949058 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:87:_gst_memory_free: free memory 005683F0
0:00:05.199001698 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.199054999 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.199105653 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC500, maxsize:13 offset:0 size:10
0:00:05.199173191 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.199224506 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.199275822 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199327800 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.199381102 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.199475787 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC4A0, maxsize:13 offset:0 size:10
0:00:05.199536372 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.199586695 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.199635362 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.199684691 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 4, csize 6
0:00:05.199736338 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199784673 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.199833340 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 8, csize 2
0:00:05.199883994 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199931999 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:87:_gst_memory_free: free memory 0F7EC500
0:00:05.199983645 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.200037278 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.200087932 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC440, maxsize:13 offset:0 size:10
0:00:05.200147855 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.200198177 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.200246844 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.200295511 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 2, csize 8
0:00:05.200346827 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
----
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/8mpeg2dec: fix decoding into hardware-mapped buffers2023-06-27T17:53:11ZBugzilla Migration Usermpeg2dec: fix decoding into hardware-mapped buffers## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735391)](https://bugzilla.gnome.org/show_bug.cgi?id=735391)**
## Description
Make sure to commit decoded contents into hardware mapped buffers. In some situations, a...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735391)](https://bugzilla.gnome.org/show_bug.cgi?id=735391)**
## Description
Make sure to commit decoded contents into hardware mapped buffers. In some situations, and for performance reasons actually, we might not be able to directly write into buffers backed by 3rdparty hardware. So, this means that we need to maintain some temporary surface/buffers and those are what are being exposed through GstVideoMeta info. Then, internally, the implementation may decide to efficiently convert that into a native format instead.
More precisely, VA-API exposes a vaDeriveImage() API but it might not always be efficient to directly expose GPU memory buffers. So, a temporary surface suitable for CPU interop is being exposed instead. This same happens for VDPAU where there is no direct rendering API, so a temporary image is being used and exposed.
In practice, we just need to carefully maintain map/unmap chains. On map, a clean writable memory buffer is being exposed. On unmap, the contents written by the SW decoder is to be committed. Then, if the frame is to be used again (as reference for example), then it can be mapped again, but with read-only flags this time.
### Blocking
* https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/21 (was: [Bug 735360](https://bugzilla.gnome.org/show_bug.cgi?id=735360))https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/14mpeg2dec: Flushing during seek breaks libmpeg2 decoding2023-06-27T17:48:52ZBugzilla Migration Usermpeg2dec: Flushing during seek breaks libmpeg2 decoding## Submitted by Andrew Eikum
**[Link to original bug (#759976)](https://bugzilla.gnome.org/show_bug.cgi?id=759976)**
## Description
(Possibly a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=723603 ?)
OS: Arch Linux (u...## Submitted by Andrew Eikum
**[Link to original bug (#759976)](https://bugzilla.gnome.org/show_bug.cgi?id=759976)**
## Description
(Possibly a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=723603 ?)
OS: Arch Linux (up to date as of yesterday)
libmpeg2 package version 0.5.1-5
I have two mpg files that fail to seek in Totem. They are distributed with the Steam version of Grand Theft Auto: Vice City.
[aeikum@aeikum movies]$ file *
GTAtitles.mpg: MPEG sequence, v1, system multiplex
Logo.mpg: MPEG sequence, v1, system multiplex
[aeikum@aeikum movies]$ md5sum *
d469239863d8dd5d27a758ec407d3e5a GTAtitles.mpg
5d5ff3db65ba37a0d5f0474a96ac51ea Logo.mpg
Totem successfully plays the videos. However, if you try to seek any length, Totem will display a dialog saying, "No valid frames decoded before end of stream" and quit playing the video. Seeking is possible with VLC.
A little extra debug printing in gst-plugins-ugly shows the problem occurs after executing gst_mpeg2dec_flush during the seek operation:
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 0
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 7
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 4
mpeg2dec gstmpeg2dec.c:974:handle_picture:`<mpeg2dec1>` stride
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 0
mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:`<mpeg2dec1>` flushing decoder
mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:`<mpeg2dec1>` flushing decoder
mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:`<mpeg2dec1>` flushing decoder
mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:`<mpeg2dec1>` flushing decoder
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 0
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 0
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 0
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 0
mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:`<mpeg2dec1>` parse state 0
States {0,7,4} are normal operation. After flushing, mpeg2_parse always returns STATE_BUFFER(== 0) no matter how much data is fed to mpeg2_buffer. gst_mpeg2dec_flush executes mpeg2_reset and mpeg2_skip.
Attached is a GST_DEBUG=9 log of the Totem session, trimmed to the first 600000 lines (expands to 112 MB).
Version: 1.6.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/5Cannot play UNencrypted iso DVD2023-06-27T17:38:51ZBugzilla Migration UserCannot play UNencrypted iso DVD## Submitted by Paul Praet
**[Link to original bug (#686769)](https://bugzilla.gnome.org/show_bug.cgi?id=686769)**
## Description
This DVD was made in China. Potentially they have used another character set (e.g. BIG) instead of UTF...## Submitted by Paul Praet
**[Link to original bug (#686769)](https://bugzilla.gnome.org/show_bug.cgi?id=686769)**
## Description
This DVD was made in China. Potentially they have used another character set (e.g. BIG) instead of UTF ?
spetsnaz@seefhoek:~/wedding/VIDEO_TS$ gst-launch dvdreadsrc device=~/wedding.iso ! fakesink
Setting pipeline to PAUSED ...
libdvdread: Encrypted DVD support unavailable.
************************************************
** **
** No css library available. See **
** /usr/share/doc/libdvdread4/README.css **
** for more information. **
** **
************************************************
*** Zero check failed in /build/buildd/libdvdread-4.2.0/src/ifo_read.c:571
for vmgi_mat->zero_3 = 0x00000000010000000000000000000000000000
(gst-launch-0.10:4198): GStreamer-WARNING **: Trying to set string on structure field 'audio-0-language', but string is not valid UTF-8. Please file a bug.
ERROR: Pipeline doesn't want to pause.
Setting pipeline to NULL ...
Freeing pipeline ...
Version: 1.2.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/18dvdreadsrc: add "stop-after-chapter" property2023-06-27T17:24:18ZBugzilla Migration Userdvdreadsrc: add "stop-after-chapter" property## Submitted by gnu..@..og.com
**[Link to original bug (#792479)](https://bugzilla.gnome.org/show_bug.cgi?id=792479)**
## Description
I wanted the ability to specify a range of chapters to the dvdreadsrc plugin. Since it appeared to...## Submitted by gnu..@..og.com
**[Link to original bug (#792479)](https://bugzilla.gnome.org/show_bug.cgi?id=792479)**
## Description
I wanted the ability to specify a range of chapters to the dvdreadsrc plugin. Since it appeared to lack the properties and the logic necessary, I tried to code it myself.
It seems to work in my limited testing.
I would appreciate if this could be incorporated into the official source so I don't have to run a custom plugin for my applications.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/19x264enc: Make sure sinkpad caps are never renegotiated2023-06-27T11:23:22ZBugzilla Migration Userx264enc: Make sure sinkpad caps are never renegotiated## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#795416)](https://bugzilla.gnome.org/show_bug.cgi?id=795416)**
## Description
See commit message
### Blocking
* [Bug 795420](https://bugzilla.gnome.org/show...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#795416)](https://bugzilla.gnome.org/show_bug.cgi?id=795416)**
## Description
See commit message
### Blocking
* [Bug 795420](https://bugzilla.gnome.org/show_bug.cgi?id=795420)https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/11asfdemux: add support for trick play in push mode2023-06-20T17:07:29ZBugzilla Migration Userasfdemux: add support for trick play in push mode## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Fo...## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Forward(1/2X, 2X, 4X) and Rewind (-1/2X, -2X, -4X).
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/7[asfdemux] Confused when receiving segment updates from upstream2023-06-20T16:35:04ZBugzilla Migration User[asfdemux] Confused when receiving segment updates from upstream## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#734034)](https://bugzilla.gnome.org/show_bug.cgi?id=734034)**
## Description
I'm working on implementing DLNA time based fast forward. The idea is to
implem...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#734034)](https://bugzilla.gnome.org/show_bug.cgi?id=734034)**
## Description
I'm working on implementing DLNA time based fast forward. The idea is to
implement fast forward in dlnasrc by requesting smaller parts of the file to
the HTTP server. Dlnasrc then sends segment updates for each fragment of the
file to play (for example, if rate=2 and we use chunk of 1 second we could have
something like [00:00, 00:01] then [00:02, 00:03] then [00:04; 00:05]).
This works fine with mpegpsdemux but not so much with asfdemux. With 1.4, the first segment is played but then playback is stuck.https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/17asfdemux: Seeking close to duration not working2023-06-20T16:33:56ZBugzilla Migration Userasfdemux: Seeking close to duration not working## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playba...## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playback is not continuing from the seek position.
Attached stream duration is 50 sec. When seek is issued between 42 to 46 sec, playback ends immediately. Ideally playback should continue from 42 to 46 sec after seek operation.
Version: 1.12.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/12asfdemux: skip a frame with an abnormal time stamp.2023-06-20T15:59:36ZBugzilla Migration Userasfdemux: skip a frame with an abnormal time stamp.## Submitted by Rajesh Singh
**[Link to original bug (#753907)](https://bugzilla.gnome.org/show_bug.cgi?id=753907)**
## Description
Created attachment 309786
patch to resolve the issue
Although a demuxer succeeded to parse a ...## Submitted by Rajesh Singh
**[Link to original bug (#753907)](https://bugzilla.gnome.org/show_bug.cgi?id=753907)**
## Description
Created attachment 309786
patch to resolve the issue
Although a demuxer succeeded to parse a frame, the frame can be defective.
So I added some codes for the asf demuxer to skip frames with an normal timestamp.
I regarded the timestamp is abnormal in case the timestamp is out of the segment duration.
Issue can be observed with the attached test stream and can be resolved with the attached patch.
Kindly share your views/concerns on this.
**Patch 309786**, "patch to resolve the issue":
[skip_abnormal_ts.patch](/uploads/ea17dcf7502fe038f744419e3e27a3f7/skip_abnormal_ts.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/1dvdlpcmdec? mpegpsdemux? some vob files with lpcm audio don't preroll2023-06-04T10:42:05ZBugzilla Migration Userdvdlpcmdec? mpegpsdemux? some vob files with lpcm audio don't preroll## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#603528)](https://bugzilla.gnome.org/show_bug.cgi?id=603528)**
## Description
i have a vob file with an lpcm audio track only and it doesn't start playing with play...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#603528)](https://bugzilla.gnome.org/show_bug.cgi?id=603528)**
## Description
i have a vob file with an lpcm audio track only and it doesn't start playing with playbin2 or decodebin2
what works fine is plugging the pipeline manually like this:
gst-launch-0.10 filesrc location=VTS_01_1.VOB ! dvddemux ! dvdlpcmdec ! multiqueue ! audioconvert ! audioresample ! alsasinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/3asfdemux: "This is not an ASF file" error with europarliament RTSP broadcast2023-06-04T10:41:35ZBugzilla Migration Userasfdemux: "This is not an ASF file" error with europarliament RTSP broadcast## Submitted by Tim Müller `@tpm`
**[Link to original bug (#665233)](https://bugzilla.gnome.org/show_bug.cgi?id=665233)**
## Description
Created attachment 202473
gdp payloaded capture of RTSP ASF stream
First few bytes of th...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#665233)](https://bugzilla.gnome.org/show_bug.cgi?id=665233)**
## Description
Created attachment 202473
gdp payloaded capture of RTSP ASF stream
First few bytes of the stream attached as gdp-payloaded capture, reproduce with:
GST_DEBUG=asf*:5 gst-launch-0.10 filesrc location=livwms-europarl-europa-asf-rtsp-head.gdp ! gdpdepay ! decodebin2 ! fakesink -v
**Attachment 202473**, "gdp payloaded capture of RTSP ASF stream":
[livewms-europarl-europa-asf-rtsp-head.gdp](/uploads/9b8c279ff023f8350e716d65af6100b3/livewms-europarl-europa-asf-rtsp-head.gdp)https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/4asfdemux: scan files saved from broadcast to report duration and support seeking2023-06-04T10:37:49ZBugzilla Migration Userasfdemux: scan files saved from broadcast to report duration and support seeking## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#678531)](https://bugzilla.gnome.org/show_bug.cgi?id=678531)**
## Description
But MPlayer could seek in it.## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#678531)](https://bugzilla.gnome.org/show_bug.cgi?id=678531)**
## Description
But MPlayer could seek in it.https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/20x264enc: High resolution with default settings (cbr and 2Mb/s) produces broke...2023-05-30T10:23:12ZBugzilla Migration Userx264enc: High resolution with default settings (cbr and 2Mb/s) produces broken stream## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797161)](https://bugzilla.gnome.org/show_bug.cgi?id=797161)**
## Description
See below
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,width=1800,heig...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797161)](https://bugzilla.gnome.org/show_bug.cgi?id=797161)**
## Description
See below
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,width=1800,height=1600 ! x264enc ! rtph264pay ! rtph264depay ! queue ! decodebin ! videoconvert ! autovideosink
Lower resolution or not going through RTP makes it work fine.https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/16[PLUGIN-MOVE] Move dvdlpcmdec to -good2023-05-30T10:14:47ZBugzilla Migration User[PLUGIN-MOVE] Move dvdlpcmdec to -good## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#774577)](https://bugzilla.gnome.org/show_bug.cgi?id=774577)**
## Description
There's no point in having it in -ugly.## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#774577)](https://bugzilla.gnome.org/show_bug.cgi?id=774577)**
## Description
There's no point in having it in -ugly.https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/9mpeg2dec: Failed "uncleanly" upon resolution change (e.g. video track change)2023-05-16T17:45:12ZBugzilla Migration Usermpeg2dec: Failed "uncleanly" upon resolution change (e.g. video track change)## Submitted by Fabien Vallée
**[Link to original bug (#740368)](https://bugzilla.gnome.org/show_bug.cgi?id=740368)**
## Description
If a media has different video tracks, set the playbin "current-video" property allow to select the...## Submitted by Fabien Vallée
**[Link to original bug (#740368)](https://bugzilla.gnome.org/show_bug.cgi?id=740368)**
## Description
If a media has different video tracks, set the playbin "current-video" property allow to select the current track displayed
g_object_set (playbin, "current-video", index, NULL);
This is working perfectly fine if the different tracks have the same width/height.
However, if the width/height change, gstreamer will fail with the following error
setting current video stream to 1
ERROR default video-frame.c:152:gst_video_frame_map_id: invalid buffer size 540000 < 556800
ERROR mpeg2dec gstmpeg2dec.c:563:gst_mpeg2dec_alloc_buffer:`<mpeg2dec0>` Failed to map frame
WARN multiqueue gstmultiqueue.c:1571:gst_multi_queue_loop:`<multiqueue0>` error: Internal data stream error.
WARN multiqueue gstmultiqueue.c:1571:gst_multi_queue_loop:`<multiqueue0>` error: streaming stopped, reason error
Error received from element multiqueue0: Internal data stream error.
( as reported using GST_DEBUG=*:3)
Please find attached a test application that can be used to reproduce the bug, based on http://docs.gstreamer.com/plugins/viewsource/viewpagesrc.action?pageId=327794
I've made the following changes:
1) update to be compatible with gst 1.0 (playbin2 -> playbin)
2) uri of media comes from command line
3) console prompt is used to select video (instead of text)
Hopefully the attached code can be compiled directly using cmake (cmake file includes).
Steps to reproduce the issue:
1) test with a video containing 2 video tracks (same width / height):
./multitrack http://trac.webkit.org/export/176315/trunk/LayoutTests/media/content/two-audio-and-video-tracks.mkv
--> press 0 or 1 in console allow to select the video track, it works perfectly fine.
2) test with a video containing 3 video tracks with different w/h:
GST_DEBUG=*:3 ./multitrack file://$PWD/multivideo.mp4
gstreamer will fail when changing the video track.
multivideo.mp4 is included in attached code and has been generated using ffmpeg:
ffmpeg -loop 1 -i image000.png -c:v libx264 -t 30 -pix_fmt yuv420p blue.mp4
ffmpeg -loop 1 -i image002.png -c:v libx264 -t 30 -pix_fmt yuv420p purple.mp4
ffmpeg -loop 1 -i image001.png -c:v libx264 -t 30 -pix_fmt yuv420p green.mp4
ffmpeg -i green.mp4 -i blue.mp4 -i purple.mp4 -map 0:0 -map 1:0 -map 2:0 -metadata:s:v:0 language=eng -metadata:s:v:1 language=fre -metadata:s:v:1 language=deu -c copy -c:v mpeg2video multivideo.mp4
(mplayer and SMPlayer are able to select multivideo.mp4 video tracks).
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/21x264enc: Print full option-string applied to x264_encoder in debug log ...2021-11-08T13:23:00ZBugzilla Migration Userx264enc: Print full option-string applied to x264_encoder in debug log ...## Submitted by Yeongjin Jeong
**[Link to original bug (#797299)](https://bugzilla.gnome.org/show_bug.cgi?id=797299)**
## Description
Created attachment 373952
x264enc: Print full option-string applied to x264_encoder in debug log...## Submitted by Yeongjin Jeong
**[Link to original bug (#797299)](https://bugzilla.gnome.org/show_bug.cgi?id=797299)**
## Description
Created attachment 373952
x264enc: Print full option-string applied to x264_encoder in debug log ...
... and use x264 nal_unit_type enum instead of constant value.
This debug log shows the following information :
0:00:00.227263644 12159 0xe722d0 INFO x264enc gstx264enc.c:1951:gst_x264_enc_set_profile_and_level:`<x264enc0>` Using x264_encoder info: 264 - core 144 r2533 c8a773e - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http://www.videolan.org/x264.html - options: cabac=1 ref=2 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=4 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offs et=0 threads=11 lookahead_threads=11 sliced_threads=1 slices=11 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=1 keyint=30 keyint_min=16 scenecut=0 intra_refresh=0 rc_lookahead=0 rc=cbr mbtree=0 bi trate=2048 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=2048 vbv_bufsize=1228 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00
~~**Patch 373952**~~, "x264enc: Print full option-string applied to x264_encoder in debug log ...":
[0001-x264enc-Print-full-option-string-applied-to-x264_enc.patch](/uploads/eee6d33cbbf80203e9e8859f6263f9c5/0001-x264enc-Print-full-option-string-applied-to-x264_enc.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/2asfdemux: add support for MS-WMSP (application/x-mms-framed)2021-10-20T19:12:19ZBugzilla Migration Userasfdemux: add support for MS-WMSP (application/x-mms-framed)## Submitted by awyoung@hispeed.ch
**[Link to original bug (#652946)](https://bugzilla.gnome.org/show_bug.cgi?id=652946)**
## Description
Created attachment 190207
Core patch
Add support for MS-WMSP (Windows Media HTTP Stream...## Submitted by awyoung@hispeed.ch
**[Link to original bug (#652946)](https://bugzilla.gnome.org/show_bug.cgi?id=652946)**
## Description
Created attachment 190207
Core patch
Add support for MS-WMSP (Windows Media HTTP Streaming Protocol: http://msdn.microsoft.com/en-us/library/cc251059%28v=PROT.10%29.aspx) framed ASF. This protocol wraps the ASF packets in an additional framing protocol (application/x-mms-framed). In addition to removing this wrapping, the ASF demuxer needs to be aware of the frame boundaries provided by this protocol, so it seems appropriate to enhance the existing asfdemux plugin rather than supply a new one.
The attached patch includes the core of the technical changes and hardcodes the use of application/x-mms-framed instead of video/x-ms-asf, so clearly it is not yet complete. I guess what is needed is a declaration of the additional application/x-mms-framed capability for the sink pad and code to detect if the incoming data stream is in fact application/x-mms-framed and set the (new) framed flag in the demux structure when that is the case. I am unsure how to do that.
The patch only does anything useful with type H (header) type D (data) packet types (see http://msdn.microsoft.com/en-us/library/cc251224%28v=PROT.10%29.aspx). It might make make sense to detect two consecutive E (end-of-stream) packets as these are sometimes used to signal end of stream without disconnecting the input stream. Otherwise, the existing logic deals sufficiently with consecutive streams, without explicit handling of the E, C and M packets.
~~**Patch 190207**~~, "Core patch":
[asfdemux.patch](/uploads/3b3ec26555fb04e15761ef2ddc2ea1f5/asfdemux.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/10x264enc: user of uninitialized reported by valgrind2021-09-30T16:29:56ZBugzilla Migration Userx264enc: user of uninitialized reported by valgrind## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#749232)](https://bugzilla.gnome.org/show_bug.cgi?id=749232)**
## Description
Running gst-validate transcoding scenarios such as validate.file.transcode.to_mp3...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#749232)](https://bugzilla.gnome.org/show_bug.cgi?id=749232)**
## Description
Running gst-validate transcoding scenarios such as validate.file.transcode.to_mp3_and_h264_in_mp4.raw_h264_0_mp4 with valgrind reports loads of invalid read memory bugs. It's not clear if those are actual gst bugs, x264 issues or just false positives but it would be good to investigate those at some point.
Some examples:
==21695== Use of uninitialised value of size 8
==21695== at 0xFAD98E5: x264_log2 (common.h:343)
==21695== by 0xFAD98E5: x264_adaptive_quant_frame (ratecontrol.c:394)
==21695== by 0xFB31FF5: ??? (in /tmp/264/lib/libx264.so.146)
==21695== by 0xFAFEFF2: x264_encoder_encode (encoder.c:3291)
==21695== by 0xF873CC3: gst_x264_enc_encode_frame (gstx264enc.c:2048)
==21695== by 0xF876809: gst_x264_enc_handle_frame (gstx264enc.c:1988)
==21695== by 0x5570186: gst_video_encoder_chain (gstvideoencoder.c:1380)
==21695== by 0x4C2B468: gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2009)
==21695== by 0x5A69503: gst_pad_chain_data_unchecked (gstpad.c:4038)
==21695== by 0x5A69503: gst_pad_push_data (gstpad.c:4271)
==21695== by 0x57D6CD4: gst_base_transform_chain (gstbasetransform.c:2281)
==21695== by 0x4C2B468: gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2009)
==21695== by 0x5A69503: gst_pad_chain_data_unchecked (gstpad.c:4038)
==21695== by 0x5A69503: gst_pad_push_data (gstpad.c:4271)
==21695== by 0x101FBF0A: gst_video_rate_transform_ip (gstvideorate.c:1211)
==21695== by 0x57D632A: gst_base_transform_handle_buffer (gstbasetransform.c:2133)
==21695== by 0x57D6B14: gst_base_transform_chain (gstbasetransform.c:2245)
==21695== by 0x4C2B468: gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2009)
==21695== by 0x5A69503: gst_pad_chain_data_unchecked (gstpad.c:4038)
==21695== by 0x5A69503: gst_pad_push_data (gstpad.c:4271)
==21695== by 0x57D6CD4: gst_base_transform_chain (gstbasetransform.c:2281)
==21695== by 0x4C2B468: gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2009)
==21695== by 0x5A69503: gst_pad_chain_data_unchecked (gstpad.c:4038)
==21695== by 0x5A69503: gst_pad_push_data (gstpad.c:4271)
==21695== by 0x57D6CD4: gst_base_transform_chain (gstbasetransform.c:2281)
```
==21695== Conditional jump or move depends on uninitialised value(s)
==21695== at 0xFACCEA6: x264_weights_analyse (slicetype.c:306)
==21695== by 0xFAD0381: x264_slicetype_decide (slicetype.c:1830)
==21695== by 0xFB31FF5: ??? (in /tmp/264/lib/libx264.so.146)
==21695== by 0xFB032A9: x264_lookahead_slicetype_decide (lookahead.c:70)
==21695== by 0xFB03491: x264_lookahead_thread (lookahead.c:108)
==21695== by 0x3EB8807529: start_thread (pthread_create.c:310)
==21695== by 0x3EB850022C: clone (clone.S:109)
==21695== Thread 19:
==21695== Conditional jump or move depends on uninitialised value(s)
==21695== at 0xFAD0F9A: refine_subpel (me.c:928)
==21695== by 0xFAD62E5: x264_me_search_ref (me.c:796)
==21695== by 0xFAC5D42: x264_mb_analyse_inter_p16x16 (analyse.c:1400)
==21695== by 0xFAC847B: x264_macroblock_analyse (analyse.c:3153)
==21695== by 0xFAFB92F: x264_slice_write (encoder.c:2743)
==21695== by 0xFB31FF5: ??? (in /tmp/264/lib/libx264.so.146)
==21695== by 0xFAF8F76: x264_slices_write (encoder.c:3084)
==21695== by 0xFB31FF5: ??? (in /tmp/264/lib/libx264.so.146)
==21695== by 0xFB03B10: x264_threadpool_thread (threadpool.c:69)
==21695== by 0x3EB8807529: start_thread (pthread_create.c:310)
==21695== by 0x3EB850022C: clone (clone.S:109)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/issues/6dvdread: Add device probe support2021-09-30T16:28:05ZBugzilla Migration Userdvdread: Add device probe support## Submitted by an unknown user
**[Link to original bug (#692553)](https://bugzilla.gnome.org/show_bug.cgi?id=692553)**
## Description
One Fedora the DVD player is not mounted as /dev/dvd. So when you call dvdread through uridecodeb...## Submitted by an unknown user
**[Link to original bug (#692553)](https://bugzilla.gnome.org/show_bug.cgi?id=692553)**
## Description
One Fedora the DVD player is not mounted as /dev/dvd. So when you call dvdread through uridecodebin for instance it is a pain to get dvdread to use the right device node. Once Oliviers GstDevice stuff is implemented the dvdread element should be made to use it.
### Depends on
* [Bug 678402](https://bugzilla.gnome.org/show_bug.cgi?id=678402)
### Blocking
* [Bug 687617](https://bugzilla.gnome.org/show_bug.cgi?id=687617)