GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:31:24Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/230matroskademux: Support SEEK handling by upstream2021-09-24T13:31:24ZBugzilla Migration Usermatroskademux: Support SEEK handling by upstream## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#756809)](https://bugzilla.gnome.org/show_bug.cgi?id=756809)**
## Description
This is needed by HLS with WebM, or the DASH WebM profile. After the attached
patches,...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#756809)](https://bugzilla.gnome.org/show_bug.cgi?id=756809)**
## Description
This is needed by HLS with WebM, or the DASH WebM profile. After the attached
patches, we will need to figure out why seeking still does not work. It seems
like matroskademux does not like what adaptivedemux is doing there.
### Blocking
* [Bug 786142](https://bugzilla.gnome.org/show_bug.cgi?id=786142)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/229avidemux: Fix assertion error while combining flows2021-09-24T13:31:24ZBugzilla Migration Useravidemux: Fix assertion error while combining flows## Submitted by Vineeth
**[Link to original bug (#756413)](https://bugzilla.gnome.org/show_bug.cgi?id=756413)**
## Description
In case of stream without pads, it is being skipped and advance() is being called. But when advance reach...## Submitted by Vineeth
**[Link to original bug (#756413)](https://bugzilla.gnome.org/show_bug.cgi?id=756413)**
## Description
In case of stream without pads, it is being skipped and advance() is being called. But when advance reaches eos, then the stream is not advanced and the present stream will still not have pads, and the same is being passed on while combining flows, resulting in assertion errors.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/228qmlglsink: add a QML extension plugin2021-09-24T13:31:24ZBugzilla Migration Userqmlglsink: add a QML extension plugin## Submitted by Alexandre Moreno
**[Link to original bug (#756082)](https://bugzilla.gnome.org/show_bug.cgi?id=756082)**
## Description
Currently in order to make the video item (GstGLVideoItem) available to the QML engine, a sink m...## Submitted by Alexandre Moreno
**[Link to original bug (#756082)](https://bugzilla.gnome.org/show_bug.cgi?id=756082)**
## Description
Currently in order to make the video item (GstGLVideoItem) available to the QML engine, a sink must be created before loading the app.
This dependency could be removed by implementing a QML extension plugin (QQmlExtensionPlugin), that would install the library plugin somewhere, and the user would just need to add the path into QML2_IMPORT_PATH variable.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/227rtpbin with do-lost=True2021-09-24T13:31:23ZBugzilla Migration Userrtpbin with do-lost=True## Submitted by Ben
**[Link to original bug (#755666)](https://bugzilla.gnome.org/show_bug.cgi?id=755666)**
## Description
The test.py python script streams RTP/RTCP packets from rtpdump file to a pipeline with appsrc.
The streams...## Submitted by Ben
**[Link to original bug (#755666)](https://bugzilla.gnome.org/show_bug.cgi?id=755666)**
## Description
The test.py python script streams RTP/RTCP packets from rtpdump file to a pipeline with appsrc.
The streams are mixed using audiomixer and encoded to mp4 file.
When rtpbin has do-lost=True, The mp4 doesn't contain the whole recording. It stops possibly because of packet loss and large skew.
Python script - set DO_LOST = False to test without do-lost
https://drive.google.com/file/d/0B12AhxvnYHrAWTBDaUFnU2I4VkU/view?usp=sharing
rtpdump file
https://drive.google.com/file/d/0B12AhxvnYHrATVROa01sdS11Z0U/view?usp=sharing
Log (do-lost=True)
https://drive.google.com/file/d/0B12AhxvnYHrAMGFmVXdON2s3WVE/view?usp=sharinghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/226gtk: Add property to create a window and only dispatch to main thread if that...2021-09-24T13:31:23ZBugzilla Migration Usergtk: Add property to create a window and only dispatch to main thread if that is set## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#755612)](https://bugzilla.gnome.org/show_bug.cgi?id=755612)**
## Description
See summary. Dispatching to the main thread and blocking, especially during state change...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#755612)](https://bugzilla.gnome.org/show_bug.cgi?id=755612)**
## Description
See summary. Dispatching to the main thread and blocking, especially during state changes, can easily cause deadlocks. Currently we only do that because of the window that is created by the sinks if the user did not embed the widget anywhere. No normal application needs this but all applications now have to live in fear of deadlocks.
Version: 1.5.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/225speex: handle streamheaders in caps/buffers better2021-09-24T13:31:22ZBugzilla Migration Userspeex: handle streamheaders in caps/buffers better## Submitted by Håvard Graff (hgr)
**[Link to original bug (#755481)](https://bugzilla.gnome.org/show_bug.cgi?id=755481)**
## Description
Created attachment 311961
tests and fix
The tests describe this better then I can :)
...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#755481)](https://bugzilla.gnome.org/show_bug.cgi?id=755481)**
## Description
Created attachment 311961
tests and fix
The tests describe this better then I can :)
**Patch 311961**, "tests and fix":
[speex-headers.patch](/uploads/bfef01eed7e7d101b8484e74b1ac8c1c/speex-headers.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/224splitmuxsink: deadlocks when inserted into running pipeline2021-09-24T13:31:22ZBugzilla Migration Usersplitmuxsink: deadlocks when inserted into running pipeline## Submitted by Jesper Larsen
**[Link to original bug (#755400)](https://bugzilla.gnome.org/show_bug.cgi?id=755400)**
## Description
Created attachment 311839
test case
Inserting splitmuxsink into a running pipeline causes a ...## Submitted by Jesper Larsen
**[Link to original bug (#755400)](https://bugzilla.gnome.org/show_bug.cgi?id=755400)**
## Description
Created attachment 311839
test case
Inserting splitmuxsink into a running pipeline causes a deadlock for the configuration described here.
The use case is to have a live source of video+audio running continuously, with the possibility of starting a recording using splitmuxsink.
A test case is provided as an attachment.
The initial pipeline is as follows:
audiotestsrc is-live=true ! faac ! aacparse ! audio/mpeg,stream-format=raw ! queue ! fakesink
videotestsrc is-live=true ! x264enc key-int-max=10 ! h264parse ! video/x-h264,alignment=au,stream-format=avc ! queue ! fakesink
After 10s blocking pad probes are installed on the src pads of the two queues. The fakesinks are removed from the pipeline, and a new splitmuxsink is created and inserted.
The state of the splitmuxsink is set to PLAYING, and the block probes are removed.
A few buffers are received on the sinkpad of the multiqueue inside the splitmuxsink, but then dataflow stops.
Using GDB, I can see that the streaming thread of the audio queue srcpad is waiting in gstsplitmuxsink.c:1071
GST_LOG_OBJECT (pad, "Sleeping for GOP start");
------> GST_SPLITMUX_WAIT (splitmux);
GST_LOG_OBJECT (pad, "Done sleeping for GOP start state now %d",
splitmux->state);
The thread for the video src pad is waiting in gstmultiqueue.c:1938 with an allocation type query.
1925 GST_DEBUG_OBJECT (mq,
1926 "SingleQueue %d : Enqueuing query %p of type %s with id %d",
1927 sq->id, query, GST_QUERY_TYPE_NAME (query), curid);
1928 GST_MULTI_QUEUE_MUTEX_UNLOCK (mq);
1929 res = gst_data_queue_push (sq->queue, (GstDataQueueItem *) item);
1930 GST_MULTI_QUEUE_MUTEX_LOCK (mq);
1931 /* it might be that the query has been taken out of the queue
1932 * while we were unlocked. So, we need to check if the last
1933 * handled query is the same one than the one we just
1934 * pushed. If it is, we don't need to wait for the condition
1935 * variable, otherwise we wait for the condition variable to
1936 * be signaled. */
1937 if (sq->last_handled_query != query)
1938 g_cond_wait (&sq->query_handled, &mq->qlock);
For debugging purposes, I tried dropping any allocation queries on the srcpads of the queues. This changes the behaviour a bit. A few more buffers reaches the multiqueue, but dataflow still stalls.
The audio streaming thread still stalls waiting for GOP complete. The video thread is waiting in gstdataqueue.c:520, which seems to indicate that the queue is full. Several GOPs are queued, but the output file is still empty.
The tests have been done using 1.5.91. Pipeline works just fine if the splitmuxsink is used from the beginning instead of the fakesinks.
**Attachment 311839**, "test case":
[splitmux-test.c](/uploads/6001e483a6d6f1f9d22ffcd31503fa3e/splitmux-test.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/223pulsesrc/sink report incorrect latency when in non-tsched mode2021-09-24T13:31:22ZBugzilla Migration Userpulsesrc/sink report incorrect latency when in non-tsched mode## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#755396)](https://bugzilla.gnome.org/show_bug.cgi?id=755396)**
## Description
When a hardware source used by pulseaudio is not running in tsched mode, there is an...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#755396)](https://bugzilla.gnome.org/show_bug.cgi?id=755396)**
## Description
When a hardware source used by pulseaudio is not running in tsched mode, there is an additional latency represented by the "fixed latency" value shown in `pacmd list-sources`.
This additional minimum latency is not reported by pulsesrc, but should be.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/222qtdemux: Add support for trick play in push mode2021-09-24T13:31:21ZBugzilla Migration Userqtdemux: Add support for trick play in push mode## Submitted by man..@..ge.com
**[Link to original bug (#755381)](https://bugzilla.gnome.org/show_bug.cgi?id=755381)**
## Description
Summary:
qtdemux: Add support for trick play in push mode.
Description:
Overview: Curr...## Submitted by man..@..ge.com
**[Link to original bug (#755381)](https://bugzilla.gnome.org/show_bug.cgi?id=755381)**
## Description
Summary:
qtdemux: Add support for trick play in push mode.
Description:
Overview: Currently, qtdemux doesn't support trick play in push mode i.e. Fast Forward(+4X), Fast Backward (-2x,-4x), Slow Forward(+1/2X) and Slow Rewind
(-1/2x).
1.Patch 1 adds support to trick play.
2.Patch 2 is to enable fast rewind in souphttpsrc since its disabled now.
Steps to Reproduce:
1) Play the attached MP4 file.
Actual Results:
Fast Forward(+4X), Fast Backward (-2x,-4x), Slow Forward(+1/2X) and Slow Rewind
(-1/2x) doesn't work in push mode.
Expected Results:
Fast Forward(+4X), Fast Backward (-2x,-4x), Slow Forward(+1/2X) and Slow Rewind
(-1/2x) should work in push mode.
Build Date & Hardware:
Build 2014-12-18 on Ubuntu 12.04
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/221osxaudosink: missing mute property2021-09-24T13:31:21ZBugzilla Migration Userosxaudosink: missing mute property## Submitted by Thomas Löwe
**[Link to original bug (#755107)](https://bugzilla.gnome.org/show_bug.cgi?id=755107)**
## Description
Audiosinks for Windows and Linux offers beside the "volume" property also a "mute" property.
Thi...## Submitted by Thomas Löwe
**[Link to original bug (#755107)](https://bugzilla.gnome.org/show_bug.cgi?id=755107)**
## Description
Audiosinks for Windows and Linux offers beside the "volume" property also a "mute" property.
This is missing for MacOS and so here an additional "volume" element is required to get the option for toggling the mute state.
Would be nice if this could be unified on all operating systems.
Thanks, Thomas
Version: 1.5.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/219pulsesink: no sound heard very shortly at starting of resuming playback.2021-09-24T13:31:20ZBugzilla Migration Userpulsesink: no sound heard very shortly at starting of resuming playback.## Submitted by KimJeongYeon
**[Link to original bug (#755050)](https://bugzilla.gnome.org/show_bug.cgi?id=755050)**
## Description
Dear all,
When I use pulsesink based playback, I found no sound heard very shortly(around 100ms...## Submitted by KimJeongYeon
**[Link to original bug (#755050)](https://bugzilla.gnome.org/show_bug.cgi?id=755050)**
## Description
Dear all,
When I use pulsesink based playback, I found no sound heard very shortly(around 100ms) when resume paused playback.
The reproduce step is:
- play 1 second (44100Hz, mono, 16bit signed short) of wav file via pulsesink,
- pause playback around EOS (1sec),
- seek to 0, resume.
- pcm was dropped(no sound) around 100ms at starting of resume.
// pa_stream_write() at the end of playback
0:00:47.458404541 pulse pulsesink.c:783:gst_pulsering_stream_request_cb:`<pulsesink3>` got request for length 6856
0:00:47.459289550 pulse pulsesink.c:1824:gst_pulseringbuffer_commit:`<pulsesink3>` requesting 2276 bytes of shared memory
0:00:47.459381103 pulse pulsesink.c:1833:gst_pulseringbuffer_commit:`<pulsesink3>` got 2276 bytes of shared memory
0:00:47.459411621 pulse pulsesink.c:1842:gst_pulseringbuffer_commit:`<pulsesink3>` writing 1138 samples at offset 342180
0:00:47.459472656 pulse pulsesink.c:1895:gst_pulseringbuffer_commit:`<pulsesink3>` flushing 1138 samples at offset 342180
0:00:47.459564209 pulse pulsesink.c:1939:gst_pulseringbuffer_commit:`<pulsesink3>` wrote 1138 samples
// end of buffer, pulsesink got eos event.
0:00:47.459777832 basesink gstbasesink.c:3191:gst_base_sink_event:`<pulsesink3>` received event 0xaf8be130 eos event: 0xaf8be130, time 99:99:99.999999999, seq-num 1241, (NULL)
0:00:47.459869384 pulse pulsesink.c:1998:gst_pulsering_flush:`<pulsesink3>` entering flush
0:00:47.459991455 basesink gstbasesink.c:1854:gst_base_sink_get_sync_times:`<pulsesink3>` sync times for EOS 99:99:99.999999999
0:00:47.460052490 basesink gstbasesink.c:2308:gst_base_sink_wait:`<pulsesink3>` checking preroll 0
// try to wait until 3.905 sec
0:00:47.460083007 basesink gstbasesink.c:2319:gst_base_sink_wait:`<pulsesink3>` possibly waiting for clock to reach 0:00:01.001043084
0:00:47.460113525 basesink gstbasesink.c:2073:gst_base_sink_wait_clock:`<pulsesink3>` time 0:00:01.001043084, base_time 0:00:02.903992000
0:00:47.460205078 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.739977000
0:00:47.519287109 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.802569000
0:00:47.519683838 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.802989000
0:00:47.519927978 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.803247000
0:00:47.520233154 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.803602000
// waiting was broken due to application tried to pause.
0:00:47.520477295 pulse pulsesink.c:1490:gst_pulseringbuffer_pause:`<pulsesink3>` pausing and corking
0:00:47.520507812 pulse pulsesink.c:1355:gst_pulsering_set_corked:`<pulsesink3>` setting corked state to 1
0:00:47.525177002 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905315028000, 0:344456, 0:345094, 90252, 90000
0:00:47.525390625 pulse pulsesink.c:783:gst_pulsering_stream_request_cb:`<pulsesink3>` got request for length 10340
0:00:47.525543213 pulse pulsesink.c:801:gst_pulsering_stream_underflow_cb:`<pulsesink3>` Got underflow
0:00:47.526428222 pulse pulsesink.c:550:gst_pulsering_context_subscribe_cb:`<pulsesink6>` type 0012, idx 347
0:00:47.526489257 pulse pulsesink.c:550:gst_pulsering_context_subscribe_cb:`<pulsesink5>` type 0012, idx 347
0:00:47.526550293 pulse pulsesink.c:550:gst_pulsering_context_subscribe_cb:`<pulsesink4>` type 0012, idx 347
0:00:47.526580810 pulse pulsesink.c:550:gst_pulsering_context_subscribe_cb:`<pulsesink3>` type 0012, idx 347
0:00:47.526611328 pulse pulsesink.c:550:gst_pulsering_context_subscribe_cb:`<pulsesink2>` type 0012, idx 347
0:00:47.526672363 pulse pulsesink.c:550:gst_pulsering_context_subscribe_cb:`<pulsesink1>` type 0012, idx 347
0:00:47.526702881 pulse pulsesink.c:550:gst_pulsering_context_subscribe_cb:`<pulsesink0>` type 0012, idx 347
// read_index & write_index became 344456 (3.905 sec) after pause, it seems ok.
0:00:47.526824951 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905317561000, 0:344456, 0:344456, 80791, 90000
0:00:47.526977539 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905318721000, 0:344456, 0:344456, 79297, 90000
0:00:47.527343750 basesink gstbasesink.c:2328:gst_base_sink_wait:`<pulsesink3>` clock returned 2
0:00:47.527404785 basesink gstbasesink.c:2308:gst_base_sink_wait:`<pulsesink3>` checking preroll 1
0:00:47.528472900 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.805343000
0:00:47.537872314 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905330501000, 0:344456, 0:344456, 67521, 90000
0:00:47.559356689 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905351955000, 0:344456, 0:344456, 89655, 90000
// application try to seek & flush using pa_stream_flush()
0:00:47.592529297 basesink gstbasesink.c:4366:gst_base_sink_send_event:`<pulsesink3>` handling event 0xaf8be010 seek event: 0xaf8be010, time 99:99:99.999999999, seq-num 1287, GstEventSeek, rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, flags=(GstSeekFlags)GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_ACCURATE, cur-type=(GstSeekType)GST_SEEK_TYPE_SET, cur=(gint64)0, stop-type=(GstSeekType)GST_SEEK_TYPE_NONE, stop=(gint64)-1;
0:00:47.593109131 basesink gstbasesink.c:3191:gst_base_sink_event:`<pulsesink3>` received event 0xb85b3170 flush-start event: 0xb85b3170, time 99:99:99.999999999, seq-num 1288, (NULL)
0:00:47.593475341 basesink gstbasesink.c:3000:gst_base_sink_default_event:`<pulsesink3>` flush-start 0xb85b3170
0:00:47.593719482 basesink gstbasesink.c:2349:gst_base_sink_wait:`<pulsesink3>` we are flushing
0:00:47.594177246 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.805343000
0:00:47.594818115 basesink gstbasesink.c:3191:gst_base_sink_event:`<pulsesink3>` received event 0xb85b30e0 flush-stop event: 0xb85b30e0, time 99:99:99.999999999, seq-num 1296, GstEventFlushStop, reset-time=(boolean)true;
0:00:47.595062256 pulse pulsesink.c:1404:gst_pulseringbuffer_clear:`<pulsesink3>` clearing
0:00:47.597290039 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905389064000, 1:344456, 0:344456, 88854, 90000
0:00:47.597503662 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905389735000, 0:344456, 0:344456, 88153, 90000
0:00:47.597747802 basesink gstbasesink.c:3010:gst_base_sink_default_event:`<pulsesink3>` flush-stop 0xb85b30e0, reset_time: 1
0:00:47.600616455 basesink gstbasesink.c:3191:gst_base_sink_event:`<pulsesink3>` received event 0xaf8be178 segment event: 0xaf8be178, time 99:99:99.999999999, seq-num 1298, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_RESET, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)1001043084;";
0:00:47.601135254 basesink gstbasesink.c:1902:gst_base_sink_get_sync_times:`<pulsesink3>` got times start: 0:00:00.000000000, stop: 0:00:00.046439910, do_sync 0
0:00:47.601226806 basesink gstbasesink.c:1455:gst_base_sink_commit_state:`<pulsesink3>` commiting state to PAUSED
0:00:47.601257324 basesink gstbasesink.c:1480:gst_base_sink_commit_state:`<pulsesink3>` posting PAUSED state change message
0:00:47.601318359 basesink gstbasesink.c:1486:gst_base_sink_commit_state:`<pulsesink3>` posting async-done message
0:00:47.602111816 basesink gstbasesink.c:4413:gst_base_sink_send_event:`<pulsesink3>` handled event 0xaf8be010 seek event: 0xaf8be010, time 99:99:99.999999999, seq-num 1287, GstEventSeek, rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, flags=(GstSeekFlags)GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_ACCURATE, cur-type=(GstSeekType)GST_SEEK_TYPE_SET, cur=(gint64)0, stop-type=(GstSeekType)GST_SEEK_TYPE_NONE, stop=(gint64)-1;: 1
0:00:47.606475830 pulse pulsesink.c:856:gst_pulsering_stream_latency_cb:`<pulsesink3>` latency_update, 1441797905399135000, 0:344456, 0:344456, 78731, 90000
0:00:47.609008789 pulse pulsesink.c:2414:gst_pulsesink_get_time:`<pulsesink3>` current time is 0:00:03.805343000
0:00:47.609649658 basesink gstbasesink.c:4366:gst_base_sink_send_event:`<pulsesink3>` handling event 0xb85b3050 latency event: 0xb85b3050, time 99:99:99.999999999, seq-num 1310, GstEventLatency, latency=(guint64)0;
0:00:47.609985351 basesink gstbasesink.c:4413:gst_base_sink_send_event:`<pulsesink3>` handled event 0xb85b3050 latency event: 0xb85b3050, time 99:99:99.999999999, seq-num 1310, GstEventLatency, latency=(guint64)0;: 1
// application try to resume,
// pa_stream_write()
0:00:47.610321045 basesink gstbasesink.c:4975:gst_base_sink_change_state:`<pulsesink3>` PAUSED to PLAYING, don't need preroll
0:00:47.610534668 pulse pulsesink.c:1707:gst_pulseringbuffer_commit:`<pulseringbuffer3>` start!
0:00:47.610565185 pulse pulsesink.c:1450:gst_pulseringbuffer_start:`<pulsesink3>` starting
0:00:47.610595703 pulse pulsesink.c:1714:gst_pulseringbuffer_commit:`<pulsesink3>` entering commit
0:00:47.610626220 pulse pulsesink.c:1732:gst_pulseringbuffer_commit:`<pulsesink3>` in 2047, out 2047
// I expect that offset should be around "344456", but pa_stream_get_time() returns "335630".
// around 100ms of pcm couldn't heard due to discontinuity.
0:00:47.610748291 pulse pulsesink.c:1755:gst_pulseringbuffer_commit:`<pulsesink3>` need to write 2048 samples at offset 335630
0:00:47.610778808 pulse pulsesink.c:1759:gst_pulseringbuffer_commit:`<pulsesink3>` discontinuity, offset is 335630, last offset was 344456
0:00:47.610809326 pulse pulsesink.c:1824:gst_pulseringbuffer_commit:`<pulsesink3>` requesting 4096 bytes of shared memory
0:00:47.610870361 pulse pulsesink.c:1833:gst_pulseringbuffer_commit:`<pulsesink3>` got 4096 bytes of shared memory
0:00:47.610900879 pulse pulsesink.c:1842:gst_pulseringbuffer_commit:`<pulsesink3>` writing 2048 samples at offset 335630
0:00:47.610931396 pulse pulsesink.c:1895:gst_pulseringbuffer_commit:`<pulsesink3>` flushing 2048 samples at offset 335630
0:00:47.611022949 pulse pulsesink.c:1916:gst_pulseringbuffer_commit:`<pulsesink3>` read_index at 344456, offset 339726
0:00:47.611053466 pulse pulsesink.c:1939:gst_pulseringbuffer_commit:`<pulsesink3>` wrote 2048 samples
0:00:47.611206054 basesink gstbasesink.c:1902:gst_base_sink_get_sync_times:`<pulsesink3>` got times start: 0:00:00.046439910, stop: 0:00:00.092879819, do_sync 0
When I tried to disable interpolation timing(PA_STREAM_INTERPOLATE_TIMING) flag in pulsesink.c, the
offset move expectedly and sound heard well without this kind of drop. Please refer below test patch.
-------------------------------------------------------------------------------
diff --git a/ext/pulse/pulsesink.c b/ext/pulse/pulsesink.c
index e580afc..a10da7e 100755
--- a/ext/pulse/pulsesink.c
+++ b/ext/pulse/pulsesink.c
@@ -961,8 +961,8 @@ gst_pulseringbuffer_acquire (GstAudioRingBuffer * buf,
}
/* construct the flags */
- flags = PA_STREAM_INTERPOLATE_TIMING | PA_STREAM_AUTO_TIMING_UPDATE |
- PA_STREAM_ADJUST_LATENCY | PA_STREAM_START_CORKED;
+ flags = PA_STREAM_AUTO_TIMING_UPDATE | PA_STREAM_ADJUST_LATENCY |
+ PA_STREAM_START_CORKED;
if (psink->mute_set) {
if (psink->mute)
-------------------------------------------------------------------------------
I guess interpolation timing isn't correct in some special cases than index based timing, but I have no idea why.
Can you give us any feedback about this issue? Is it proper disabling "PA_STREAM_INTERPOLATE_TIMING" flag than use it?
Regards,
KimJeongYeon
Version: 1.4.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/218Can't link tsdemux to aacparse and rtpmp4gpay2021-09-24T13:31:20ZBugzilla Migration UserCan't link tsdemux to aacparse and rtpmp4gpay## Submitted by dav..@..il.com
**[Link to original bug (#754664)](https://bugzilla.gnome.org/show_bug.cgi?id=754664)**
## Description
I'm trying to extract AAC audio from an mpeg2 ts stream and post it off in it's own rtp stream. ...## Submitted by dav..@..il.com
**[Link to original bug (#754664)](https://bugzilla.gnome.org/show_bug.cgi?id=754664)**
## Description
I'm trying to extract AAC audio from an mpeg2 ts stream and post it off in it's own rtp stream.
This the the command line:
gst-launch-1.0.exe udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,payload=(int)96" port=41010 address=229.10.10.10 ! rtpmp2tdepay ! queue ! tsdemux ! "audio/mpeg" ! aacparse ! "audio/mpeg,stream-format=(string)raw" ! rtpmp4gpay ! fakesink -v
It gets as far as this graph before failing:
http://postimg.org/image/guvorbizt/full/
However, if I remove rtpmp4gpay and hook aacparse direct to fakesink it creates this working graph:
http://postimg.org/image/rm1lqqxrx/full/
As a test the following command line using audiotestsrc appears to produce the same issue:
gst-launch-1.0.exe audiotestsrc ! voaacenc ! mpegtsmux ! tsdemux ! "audio/mpeg" ! aacparse ! rtpmp4gpay ! fakesink
Version: 1.5.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/217multipartdemux: Better parsing of Content-Type multipart header2021-09-24T13:31:20ZBugzilla Migration Usermultipartdemux: Better parsing of Content-Type multipart header## Submitted by Jose Aladro
**[Link to original bug (#754483)](https://bugzilla.gnome.org/show_bug.cgi?id=754483)**
## Description
Dear maintainer:
The parsing of the "Content-Type:" multipart header in multipartdemux assumes *...## Submitted by Jose Aladro
**[Link to original bug (#754483)](https://bugzilla.gnome.org/show_bug.cgi?id=754483)**
## Description
Dear maintainer:
The parsing of the "Content-Type:" multipart header in multipartdemux assumes ***1*** space must follow the colon in every chunk's header or it will parse the type incorrectly.
I used an Approx APPIP01P2P IP camera (http://approx.es/APPIP01P2P).
HTTP Request
------------
GET /videostream.cgi?user=XXX&pwd=XXX HTTP/1.1
HTTP Response
-------------
HTTP/1.1 200 OK
Date: Wed Sep 2 16:27:08 2015
Server: GoAhead-Webs
Accept-Ranges: bytes
Connection: close
Content-Type: multipart/x-mixed-replace;boundary=object-ipcamera <-- this is parsed OK
--object-ipcamera
Content-Type:image/jpeg <-- this is not parsed properly
Content-Length:54264
......JFIF...
...
--object-ipcamera
Content-Type:image/jpeg
Content-Length:54150
......JFIF...
... and so on
What happens
------------
The chunks are identified by multipartdemux as "mage/jpeg" (missing the "i"), assuming a space must follow the colon in the header. For that reason, any capsfilter for 'image/jpeg' or any jpegparse or jpegdec element further in the pipeline will not link.
Note: Some buggy IP cameras may not format this header properly, as in this casse, but i.e. VLC 2.2.0 and Firefox 31.8.0 don't have any trouble playing that multipart content.
How to reproduce (useless, see the caps = mage/jpeg)
----------------------------------------------------
$ gst-launch-1.0 -e -v --gst-debug=*:1 souphttpsrc location="http://192.168.4.37/videostream.cgi?user=asus&pwd=asus" do-timestamp=true ! multipartdemux ! identity silent=false ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: caps (12814), GstEventCaps, caps=(GstCaps)mage/jpeg;) 0xe3a180
/GstPipeline:pipeline0/GstIdentity:identity0.GstPad:src: caps = mage/jpeg
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = mage/jpeg
/GstPipeline:pipeline0/GstIdentity:identity0.GstPad:sink: caps = mage/jpeg
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";) 0xe3a240
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: tag (20510), GstTagList-global, taglist=(taglist)"taglist\,\ container-format\=\(string\)Multipart\;";) 0xe3a300
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (52276 bytes, dts: none, pts:none, duration: none, offset: -1, offset_end: -1, flags: 00000040 discont ) 0xf35b30
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (52776 bytes, dts: none, pts:none, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0xe41070
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (53112 bytes, dts: none, pts:0:00:00.580902326, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0xe414b0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (53160 bytes, dts: none, pts:0:00:01.642750430, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0xf35c40
`^`Chandling interrupt.
How to reproduce (added jpegparse, not-linked error)
----------------------------------------------------
$ gst-launch-1.0 -e -v --gst-debug=*:1 souphttpsrc location="http://192.168.xxx.xxx/videostream.cgi?user=xxx&pwd=xxx" do-timestamp=true ! multipartdemux ! jpegparse ! identity silent=false ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstSoupHTTPSrc:souphttpsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2865): gst_base_src_loop (): /GstPipeline:pipeline0/GstSoupHTTPSrc:souphttpsrc0:
streaming task paused, reason not-linked (-1)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstMultipartDemux:multipartdemux0.GstPad:src_0: caps = NULL
Freeing pipeline ...
GStreamer version
-----------------
I've tested it with gst-launch-1.0 (GStreamer 1.2.4) but the relevant code is similar/the same in the master trunk (1.4?) at:
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/multipart/multipartdemux.c
Relevant code
-------------
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/multipart/multipartdemux.c:477
---cut---
if (len >= 14 && !g_ascii_strncasecmp ("content-type:", (gchar *) pos, 13)) {
guint mime_len;
/* only take the mime type up to the first ; if any. After ; there can be
* properties that we don't handle yet. */
mime_len = get_mime_len (pos + 14, len - 14);
g_free (multipart->mime_type);
multipart->mime_type = g_ascii_strdown ((gchar *) pos + 14, mime_len);
} else if (len >= 15 &&
---cut---
This piece checks for header length >= 14 chars, compares the first 13 and assumes the actual type starts at char 14, which is not always true.
Possible solutions
------------------
Allow zero or more whitespace after the colon.
Solution that works for me
--------------------------
Consider both cases: 1 and zero spaces after the colon. For 14-char pattern, read after char` #14`. For 13-char pattern, read after char` #13`.
(code recompiled with "apt-get build-dep ...", "apt-get source ..." and "fakeroot debian/rules binary" stuff)
---cut---
if (len >= 14 && !g_ascii_strncasecmp ("content-type: ", (gchar *) pos, 14)) {
guint mime_len;
/* only take the mime type up to the first ; if any. After ; there can be
* properties that we don't handle yet. */
mime_len = get_mime_len (pos + 14, len - 14);
g_free (multipart->mime_type);
multipart->mime_type = g_ascii_strdown ((gchar *) pos + 14, mime_len);
} else if (len >= 13 && !g_ascii_strncasecmp ("content-type:", (gchar *) pos, 13)) {
guint mime_len;
/* only take the mime type up to the first ; if any. After ; there can be
* properties that we don't handle yet. */
mime_len = get_mime_len (pos + 13, len - 13);
g_free (multipart->mime_type);
multipart->mime_type = g_ascii_strdown ((gchar *) pos + 13, mime_len);
} else if (len >= 15 &&
---cut---
Result with patch applied
-------------------------
$ gst-launch-1.0 -e -v --gst-debug=*:1 souphttpsrc location="http://192.168.xxx.xxx/videostream.cgi?user=xxx&pwd=xxx" do-timestamp=true ! multipartdemux ! jpegparse ! identity silent=false ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstJpegParse:jpegparse0.GstPad:sink: caps = image/jpeg
/GstPipeline:pipeline0/GstJpegParse:jpegparse0.GstPad:src: caps = image/jpeg, parsed=(boolean)true, format=(string)UYVY, interlaced=(boolean)false, width=(int)640, height=(int)480, framerate=(fraction)1/1
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: caps (12814), GstEventCaps, caps=(GstCaps)image/jpeg, parsed=(boolean)true, format=(string)UYVY, interlaced=(boolean)false, width=(int)640, height=(int)480, framerate=(fraction)1/1;) 0x21f5300
/GstPipeline:pipeline0/GstIdentity:identity0.GstPad:src: caps = image/jpeg, parsed=(boolean)true, format=(string)UYVY, interlaced=(boolean)false, width=(int)640, height=(int)480, framerate=(fraction)1/1
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = image/jpeg, parsed=(boolean)true, format=(string)UYVY, interlaced=(boolean)false, width=(int)640, height=(int)480, framerate=(fraction)1/1
/GstPipeline:pipeline0/GstIdentity:identity0.GstPad:sink: caps = image/jpeg, parsed=(boolean)true, format=(string)UYVY, interlaced=(boolean)false, width=(int)640, height=(int)480, framerate=(fraction)1/1
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";) 0x21f5400
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: tag (20510), GstTagList-stream, taglist=(taglist)"taglist\,\ container-format\=\(string\)Multipart\;";) 0x21f5460
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (51172 bytes, dts: none, pts:none, duration: none, offset: -1, offset_end: -1, flags: 00000040 discont ) 0x23b2ac0
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (50988 bytes, dts: none, pts:none, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0x21fa000
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (50944 bytes, dts: none, pts:0:00:01.007713812, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0x21fa330
`^`Chandling interrupt.
Could someone add this patch (or a more elegant one) to the development trunk?
Thanks. Sorry for the long post.
Jose
Version: 1.2.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/215qtdemux: Cannot play .MOV files from "Polaroid Cube" camera, adpcm pushed out...2021-09-24T13:31:19ZBugzilla Migration Userqtdemux: Cannot play .MOV files from "Polaroid Cube" camera, adpcm pushed out wrongly framed## Submitted by dom..@..hxy.io
**[Link to original bug (#754260)](https://bugzilla.gnome.org/show_bug.cgi?id=754260)**
## Description
I cannot play the .MOV files produced from the Polaroid Cube camera.
The files will not work ...## Submitted by dom..@..hxy.io
**[Link to original bug (#754260)](https://bugzilla.gnome.org/show_bug.cgi?id=754260)**
## Description
I cannot play the .MOV files produced from the Polaroid Cube camera.
The files will not work in Pitivi nor totem/nautilus/sushi.
A sample file from this camera can be found at http://hxy.io/FILE0003.MOV (13.2MB)
Please let me know if I can provide any other information.
Thankshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/214speexenc: don't set lookahead2021-09-24T13:31:19ZBugzilla Migration Userspeexenc: don't set lookahead## Submitted by Håvard Graff (hgr)
**[Link to original bug (#754226)](https://bugzilla.gnome.org/show_bug.cgi?id=754226)**
## Description
Created attachment 310167
patch
Also introducing a test-suite for speex.
**Patch...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#754226)](https://bugzilla.gnome.org/show_bug.cgi?id=754226)**
## Description
Created attachment 310167
patch
Also introducing a test-suite for speex.
**Patch 310167**, "patch":
[speex.patch](/uploads/02ad72c41107e9b5298685d85a543811/speex.patch)
### Depends on
* [Bug 754224](https://bugzilla.gnome.org/show_bug.cgi?id=754224)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/213rtspsrc: issue to play rtsp stream of arecont IP camera (freeze after 10 - 15...2021-09-24T13:31:19ZBugzilla Migration Userrtspsrc: issue to play rtsp stream of arecont IP camera (freeze after 10 - 15 min)## Submitted by e.j..@..ngs.ch
**[Link to original bug (#753884)](https://bugzilla.gnome.org/show_bug.cgi?id=753884)**
## Description
Created attachment 309731
output
I have an issue playing a rtsp stream from an IP camera (a...## Submitted by e.j..@..ngs.ch
**[Link to original bug (#753884)](https://bugzilla.gnome.org/show_bug.cgi?id=753884)**
## Description
Created attachment 309731
output
I have an issue playing a rtsp stream from an IP camera (arecont AV2105DN). I have no issue with other camera (axis ones for instance).
I can see the video during few minutes but then it freezes.
I have created this publically accessible stream for reproducing
this problem rtsp://84.253.5.178:554/h264.sdp .
The issue is :
0:17:02.170552131 10146 0xd25450 WARN rtspsrc gstrtspsrc.c:4716:gst_rtspsrc_send_keep_alive:`<rtspsrc0>` warning: Could not send keep-alive. (System error)
0:17:02.170597194 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1837:gst_element_message_full:`<rtspsrc0>` posting message: Could not write to resource.
0:17:02.170631162 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1860:gst_element_message_full:`<rtspsrc0>` posted warning message: Could not write to resource.
0:17:02.170669829 10146 0xd25450 WARN rtspsrc gstrtspsrc.c:5088:gst_rtspsrc_loop_udp:`<rtspsrc0>` warning: The server closed the connection.
WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not write to resource.
0:17:02.170697169 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1837:gst_element_message_full:`<rtspsrc0>` posting message: Could not read from resource.
Additional debug info:
gstrtspsrc.c(4716): gst_rtspsrc_send_keep_alive (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Could not send keep-alive. (System error)
0:17:02.170724238 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1860:gst_element_message_full:`<rtspsrc0>` posted warning message: Could not read from resource.
WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
Additional debug info:
gstrtspsrc.c(5088): gst_rtspsrc_loop_udp (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
The server closed the connection.
0:17:19.377075230 10146 0xd25450 WARN rtspsrc gstrtspsrc.c:5101:gst_rtspsrc_loop_udp:`<rtspsrc0>` warning: Unhandled return value -7.
0:17:19.377128949 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1837:gst_element_message_full:`<rtspsrc0>` posting message: Could not read from resource.
0:17:19.377165327 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1860:gst_element_message_full:`<rtspsrc0>` posted warning message: Could not read from resource.
0:17:19.377188457 10146 0xd25450 WARN rtspsrc gstrtspsrc.c:5172:gst_rtspsrc_loop_udp:`<rtspsrc0>` error: Could not receive message. (System error)
WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
0:17:19.377210946 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1837:gst_element_message_full:`<rtspsrc0>` posting message: Could not read from resource.
Additional debug info:
gstrtspsrc.c(5101): gst_rtspsrc_loop_udp (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Unhandled return value -7.
0:17:19.377242764 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1860:gst_element_message_full:`<rtspsrc0>` posted error message: Could not read from resource.
0:17:19.377265970 10146 0xd25450 WARN rtspsrc gstrtspsrc.c:5460:gst_rtspsrc_loop:`<rtspsrc0>` error: Internal data flow error.
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
0:17:19.377282011 10146 0xd25450 WARN rtspsrc gstrtspsrc.c:5460:gst_rtspsrc_loop:`<rtspsrc0>` error: streaming task paused, reason error (-5)
Additional debug info:
gstrtspsrc.c(5172): gst_rtspsrc_loop_udp (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Could not receive message. (System error)
0:17:19.377324712 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1837:gst_element_message_full:`<rtspsrc0>` posting message: Internal data flow error.
Execution ended after 0:17:19.140707049
Setting pipeline to PAUSED ...
0:17:19.377367883 10146 0xd25450 INFO GST_ERROR_SYSTEM gstelement.c:1860:gst_element_message_full:`<rtspsrc0>` posted error message: Internal data flow error.
The full output is attached.
The command line that I use is :
$ GST_DEBUG=4 ./gst-launch-1.0 rtspsrc latency=10000 location=rtsp://84.253.5.178:554/h264.sdp ! decodebin ! autovideosink
I am using ubuntu 15.04 (64bits)
I am using the GIT master version of gstreamer that I have compiled.
I have the same issue with the package version of gstreamer from ubuntu.
**Attachment 309731**, "output":
[output](/uploads/77affc723a74541fe0c29c96f1c40998/output)
Version: 1.5.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/212qtdemux: Read iTunes m4a/mp4 music tags2021-09-24T13:31:19ZBugzilla Migration Userqtdemux: Read iTunes m4a/mp4 music tags## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#753631)](https://bugzilla.gnome.org/show_bug.cgi?id=753631)**
## Description
We need to read the proprietary iTunes tags to get gapless playback support for m4a ...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#753631)](https://bugzilla.gnome.org/show_bug.cgi?id=753631)**
## Description
We need to read the proprietary iTunes tags to get gapless playback support for m4a files with fixed frame sizes.
$ GST_DEBUG=qtdemux:2 gst-discoverer-1.0 -v test.m4a
Analyzing file:///[path]/test.m4a
[snip]
0:00:00.070971448 30899 0x7f767805c230 WARN qtdemux qtdemux.c:10436:qtdemux_tag_add_revdns:`<qtdemux0>` This tag com.apple.iTunes:iTunSMPB type:1 is not mapped, file a bug at bugzilla.gnome.org
0:00:00.071004339 30899 0x7f767805c230 WARN qtdemux qtdemux.c:10436:qtdemux_tag_add_revdns:`<qtdemux0>` This tag com.apple.iTunes:iTunNORM type:1 is not mapped, file a bug at bugzilla.gnome.org
0:00:00.071016068 30899 0x7f767805c230 WARN qtdemux qtdemux.c:10436:qtdemux_tag_add_revdns:`<qtdemux0>` This tag com.apple.iTunes:iTunMOVI type:1 is not mapped, file a bug at bugzilla.gnome.org
[snip]
The iTunSMPB tag contains information about how to do gapless playback. This is needed for [bug 746109](https://bugzilla.gnome.org/show_bug.cgi?id=746109). See: http://yabb.jriver.com/interact/index.php?topic=65076
iTunNORM contains volume normalization information (perhaps this is useful for music/video players?)
iTunMOVI is an XML file with various metadata about the file. See: https://bitbucket.org/wez/atomicparsley/issues/1/itunes-atom-itunmovi
We should expose all this information.
Besides this, there's some QuickTime nodes that we don't know about and emit a warn for:
0:00:00.069971524 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type cnID
0:00:00.070032099 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type rtng
0:00:00.070046083 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type atID
0:00:00.070056063 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type cmID
0:00:00.070067572 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type plID
0:00:00.070081820 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type geID
0:00:00.070097419 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type akID
0:00:00.070112155 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type stik
0:00:00.070126745 30899 0x7f767805c230 WARN qtdemux qtdemux_types.c:209:qtdemux_type_get: unknown QuickTime node type xid
Some of these are useful (rtng = content rating). Some are not. We should know about these and discard/use as appropriate. See: https://code.google.com/p/mp4v2/wiki/iTunesMetadata
### Blocking
* [Bug 746109](https://bugzilla.gnome.org/show_bug.cgi?id=746109)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/211v4l2: implement TimeCode meta2021-09-24T13:31:18ZBugzilla Migration Userv4l2: implement TimeCode meta## Submitted by Aurélien Zanelli
**[Link to original bug (#753592)](https://bugzilla.gnome.org/show_bug.cgi?id=753592)**
## Description
Currently, we have no way to retrieve the original timestamp of the v4l2buffer in downstream ele...## Submitted by Aurélien Zanelli
**[Link to original bug (#753592)](https://bugzilla.gnome.org/show_bug.cgi?id=753592)**
## Description
Currently, we have no way to retrieve the original timestamp of the v4l2buffer in downstream element due to the addition of the delay between the time at which buffer has been timestamped and the processing by v4l2src element.
The original v4l2 timestamp could be useful for application or elements which needs the exact acquisition timestamp to perform some processing which involve external timestamped values.
For instance here is my current use case:
I have an element which takes raw frames, normally from a v4l2src, and perform video stabilization using data from an IMU (inertial measurement unit). These data are timestamped during acquisition, and are queried with timestamp. To perform accurate video stabilization, I shall use the frame acquisition timestamp.
So I propose to add V4L2 metadata to buffer pushed by v4l2src containing the v4l2buffer timestamp. These metadata could be extended as well to contains other v4l2 specific fields.
This changes is very specific to V4L2 and maybe overkill, I mean adding a meta just for a timestamp (currently). It may also be very specific to my use case.
However, I didn't find an other way to retrieve this info, nor generic metadata which can handle this.
Don't hesitate to comment
P.S.: Could be linked with https://bugzilla.gnome.org/show_bug.cgi?id=753562https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/210matroskademux: text/x-raw subtitle tracks ouputs are escaped2021-09-24T13:31:18ZBugzilla Migration Usermatroskademux: text/x-raw subtitle tracks ouputs are escaped## Submitted by Pierre Lamot
**[Link to original bug (#753480)](https://bugzilla.gnome.org/show_bug.cgi?id=753480)**
## Description
Hi
when demuxing from a matroska a track encoded as S_TEXT/UTF8, the stream comes as xml escape...## Submitted by Pierre Lamot
**[Link to original bug (#753480)](https://bugzilla.gnome.org/show_bug.cgi?id=753480)**
## Description
Hi
when demuxing from a matroska a track encoded as S_TEXT/UTF8, the stream comes as xml escaped (< becomes < etc.)
below are sample pipeline which allow to reproduce the problem.
% gst-launch-1.0 videotestsrc is-live=true do-timestamp=true ! buffertotstxt ! text/x-raw ! identity dump=true ! matroskamux streamable=true ! filesink location=lol.mkv
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
00000000 (0x1cb66f0): 3c 30 3a 30 30 3a 30 30 2e 30 30 35 37 38 37 35 <0:00:00.0057875
00000010 (0x1cb6700): 33 39 3e 39>
00000000 (0x7f4aa00322c0): 3c 30 3a 30 30 3a 30 30 2e 30 33 39 31 32 30 38 <0:00:00.0391208
00000010 (0x7f4aa00322d0): 37 32 3e 72>
00000000 (0x1cb66f0): 3c 30 3a 30 30 3a 30 30 2e 30 37 32 34 35 34 32 <0:00:00.0724542
00000010 (0x1cb6700): 30 35 3e 05>
% gst-launch-1.0 filesrc location=lol.mkv ! matroskaparse ! matroskademux ! text/x-raw ! fakesink dump=true
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
00000000 (0x7f6fac008510): 26 6c 74 3b 30 3a 30 30 3a 30 30 2e 30 30 35 37 <0:00:00.0057
New clock: GstSystemClock
00000010 (0x7f6fac008520): 38 37 35 33 39 26 67 74 3b 87539>
00000000 (0x7f6fac005fd0): 26 6c 74 3b 30 3a 30 30 3a 30 30 2e 30 33 39 31 <0:00:00.0391
00000010 (0x7f6fac005fe0): 32 30 38 37 32 26 67 74 3b 20872>
00000000 (0x7f6fac008510): 26 6c 74 3b 30 3a 30 30 3a 30 30 2e 30 37 32 34 <0:00:00.0724
00000010 (0x7f6fac008520): 35 34 32 30 35 26 67 74 3b 54205>
extracting the tracks with mkvextract gives the correct encoding, so I think this is rather on the demux side
% tracks lol.mkv 0:lol.srt
Extracting track 0 with the CodecID 'S_TEXT/UTF8' to the file 'lol.srt'. Container format: SRT text subtitles
Progress: 100%
% cat lol.srt
1
00:00:00,005 --> 00:00:00,038
<0:00:00.005787539>
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/208AVI/JPEG reverse playback: buffer sent before segment event after seek2021-09-24T13:31:17ZBugzilla Migration UserAVI/JPEG reverse playback: buffer sent before segment event after seek## Submitted by Myoungsun Lee
**[Link to original bug (#753090)](https://bugzilla.gnome.org/show_bug.cgi?id=753090)**
## Description
Created attachment 308514
add condition about segment format check
videobalance: add conditi...## Submitted by Myoungsun Lee
**[Link to original bug (#753090)](https://bugzilla.gnome.org/show_bug.cgi?id=753090)**
## Description
Created attachment 308514
add condition about segment format check
videobalance: add condition about segment format check
This element transformed buffer timestamp for synchronizing.
But it tried to transform timestamp before the new segment comes up.
It has to transform after segment values are set.
Otherwise, gstreamer occur critical issue by segment translation logic.
Issue is reproduced mjpeg codec by running gst-validate-1.0
GST_VALIDATE_SCENARIO=reverse_playback GST_GL_XINITTHREADS=1 playbin uri=file:///home/gst-validate/gst-integration-testsuites/medias/defaults/avi/bowlerhatdancer.sleepytom.SGP.mjpeg.avi audio-sink='fakesink sync=true' video-sink='fakesink sync=true' --set-media-info /home/gst-validate/gst-integration-testsuites/medias/defaults/avi/bowlerhatdancer.sleepytom.SGP.mjpeg.avi.media_info
~~**Attachment 308514**~~, "add condition about segment format check":
[0001-videobalance-add-condition-about-segment-format-chec.patch](/uploads/6aeea5f1f6bbc133ef42e5116afabc72/0001-videobalance-add-condition-about-segment-format-chec.patch)