Webvtt cue with start_time == end_time not handled gracefully

[jigneshdhruv]

We are using Shaka Packager version: 594d1f0-release

We came across a issue where shaka packager leaks memory while processing a webvtt file for HLS. We do not see this issue when processing the same webvtt with DASH.

Also this does not happen with all webvtt files.

This happened on a ubuntu server that has 64GB memory and shaka packager process took up all 64GB and then crashed.

We are trying to be very careful with our webvtt but we are worried that a bad webvtt can cause a memory leak and crash the process/server.

Here is the package command to reproduce the problem.
packager 'in=/tmp/abc.vtt,stream=text,segment_template=/tmp/output/abc/seg_$Number$.vtt,language=en,playlist_name=abc/stream_vtt.m3u8,hls_group_id=abc_vtt,hls_name=ENGLISH' --clear_lead 0 --segment_duration 6 --hls_master_playlist_output tmp/output/master.m3u8

I have send the bad webvtt file that caused memory leak to @kqyang .

Can you please take a look and let us know what is causing this memory leak?

Let us know if you need more information.

Thanks & Regards,
Jignesh

[vaage]

We have found the problem. In the DEBUG build an assert would have stopped the machine from running out of memory.

The content you have provided had two problems:

1. There are many samples that start and end at the same time. This is not spec compliant as you can read in Section 4.1 of the WebVTT spec.
2. There was a sample that ended at time 00:00:00.000 (which was only possible because of problem 1). This caused an overflow in the segmenting logic which tried to add the cue to all segments from 0 ms to 1.8 * 10 ^ 19 ms.

We have a fix to drop all zero-duration samples when packaging to avoid both these problems. In our fix we have added a test to ensure that this won't be re-introduced.

[jigneshdhruv]

I understand that is a bad webvtt. We get these webvtt files from the publishers over whch we do not have control over that. I am glad you are applying a fix for this issue.

When will this fix be committed n the branch?

Thanks.

[vaage]

The fix is in review right now. We are hoping to get it submitted to master by end of day.

[jigneshdhruv]

Thanks.

[kqyang]

Cherry-picked for v2.0.1.