After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794722 - flvmux: In live mode, starts output before all caps set
flvmux: In live mode, starts output before all caps set
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.14.0
Other All
: Normal blocker
: 1.14.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-03-27 13:22 UTC by Jan Alexander Steffens (heftig)
Modified: 2018-05-04 12:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test to reproduce the issue (10.58 KB, patch)
2018-04-17 13:31 UTC, Håvard Graff (hgr)
none Details | Review
flvmux: Wait for caps to start writing (1.14 KB, patch)
2018-04-19 21:56 UTC, Olivier Crête
none Details | Review
flvmux: Wait for caps from both srcs before writing header (11.38 KB, patch)
2018-04-19 22:20 UTC, Olivier Crête
none Details | Review
flvmux: Wait for caps from both srcs before writing header (11.96 KB, patch)
2018-04-23 15:56 UTC, Olivier Crête
committed Details | Review

Description Jan Alexander Steffens (heftig) 2018-03-27 13:22:26 UTC
flvmux will only write FLV headers at the very start of the output. 

When handling live sources, flvmux will start the output as soon as any buffer arrives on any pad. If, at this point, caps are missing from any pad, the headers produced will be incomplete.

Working around this problem using pad probes is possible but messy. Increasing the aggregator latency is possible but unwelcome because it also delays the output.

IMO flvmux should not attempt to start aggregation until it has caps for all pads. Once it has caps, it can write the headers and afterwards the live-mode behavior of not waiting for buffers on all pads is fine.
Comment 1 Olivier Crête 2018-03-27 13:45:33 UTC
Makes a lot of sense, we should indeed wait until all the caps are there, especially that they are request pads.
Comment 2 Håvard Graff (hgr) 2018-04-17 13:31:06 UTC
Created attachment 371047 [details] [review]
Test to reproduce the issue

I wrote a test that clearly demonstrates the problem. The flvmuxer will not
put the video-metadata in the flvheaders when the video-caps arrives a bit later,
and hence the flvdemuxer will not be able to produce any video data.
Comment 3 Olivier Crête 2018-04-19 21:56:09 UTC
Created attachment 371142 [details] [review]
flvmux: Wait for caps to start writing

Wait for caps on all pads to start writing data.
Comment 4 Olivier Crête 2018-04-19 21:59:21 UTC
Review of attachment 371142 [details] [review]:

Havard's test fails with this patch, let's try harder
Comment 5 Olivier Crête 2018-04-19 22:20:02 UTC
Created attachment 371144 [details] [review]
flvmux: Wait for caps from both srcs before writing header

Wait for caps on all pads to start writing data even when source is live.

Includes unit test by Havard Graff that simulates it.
Comment 6 Olivier Crête 2018-04-19 22:36:36 UTC
I slightly modified the test to account for the fact that it doesn't wait on the clock until there is caps on all pads.. But after this change, I can't make a test that fails without the patch but succeeds with it because it means I have to remove the crank that is before the setcaps, but I think the testing difficulties are related to bug #795332
Comment 7 Olivier Crête 2018-04-23 15:56:53 UTC
Created attachment 371282 [details] [review]
flvmux: Wait for caps from both srcs before writing header

Wait for caps on all pads to start writing data even when source is live.

Includes unit test by Havard Graff that simulates it.
Comment 8 Olivier Crête 2018-04-23 16:00:29 UTC
Updated the patch a little to fix the unit test to make it actually test what we want to test.

Also, I moved the code back into the other function as the thing the get_segment_next function is generic and could be moved into the core aggregator.
Comment 9 Håvard Graff (hgr) 2018-04-25 09:18:49 UTC
Review of attachment 371282 [details] [review]:

::: tests/check/elements/flvmux.c
@@ +507,3 @@
+   * before the caps are set */
+  g_usleep (40 * 1000);
+      gst_harness_new_with_element (demux->element, NULL, NULL);

Just remember to gst_object_unref the tclock in the end to not leak it.
Comment 10 Olivier Crête 2018-04-26 19:44:45 UTC
Included unref as recommended by Havard.

Attachment 371282 [details] pushed as 168fae8 - flvmux: Wait for caps from both srcs before writing header
Comment 11 Sebastian Dröge (slomo) 2018-04-27 05:59:08 UTC
This should also go into 1.14 as it's a regression
Comment 12 Olivier Crête 2018-05-04 12:02:18 UTC
Also pushed to 1.14 branch.