GNOME Bugzilla – Bug 794722
flvmux: In live mode, starts output before all caps set
Last modified: 2018-05-04 12:02:18 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.
Makes a lot of sense, we should indeed wait until all the caps are there, especially that they are request pads.
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.
Created attachment 371142 [details] [review] flvmux: Wait for caps to start writing Wait for caps on all pads to start writing data.
Review of attachment 371142 [details] [review]: Havard's test fails with this patch, let's try harder
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.
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
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.
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.
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.
Included unref as recommended by Havard. Attachment 371282 [details] pushed as 168fae8 - flvmux: Wait for caps from both srcs before writing header
This should also go into 1.14 as it's a regression
Also pushed to 1.14 branch.