Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebVTT: END_OF_STREAM error when there is no, or only one, cue #1018

Closed
dvoracek-slub opened this issue Jan 9, 2022 · 5 comments · Fixed by #1061 or #1312
Closed

WebVTT: END_OF_STREAM error when there is no, or only one, cue #1018

dvoracek-slub opened this issue Jan 9, 2022 · 5 comments · Fixed by #1061 or #1312
Labels
status: archived Archived and locked; will not be updated

Comments

@dvoracek-slub
Copy link

System info

Operating System: any
Shaka Packager Version: e1b0c7c (current master)

Issue and steps to reproduce the problem

When processing a WebVTT file that either does not contain a cue, or ends immediately after the first cue, Packager rejects it with an "END_OF_STREAM" error. The sample files are taken from the parser unit tests.

Packager Command:

packager in=sample1.vtt,stream=text,output=sample1_processed.vtt

What is the expected result?
The files should be processed without error, and output files should be generated as appropriate. (When there is no cue, it may be viable to not generate any output. That, at least, seems to be the current behavior when there are only zero-length cues.)

What happens instead?
I receive the following message:

[0109/183224:INFO:demuxer.cc(89)] Demuxer::Run() on file 'sample1.vtt'.
[0109/183224:INFO:demuxer.cc(155)] Initialize Demuxer for file 'sample1.vtt'.
[0109/183224:ERROR:packager_main.cc(554)] Packaging Error: 6 (END_OF_STREAM): 

From what I understood in the code, the issue seems to lie in the interaction between Demuxer and WebVttParser. When the end of the input file is reached before Demuxer::ParserInitEvent has been called (either because there is no cue, or because the parser doesn't know yet that the cue is finished), this is incorrectly treated as an error in Demuxer::Run.

Sample Files

sample1.vtt

WEBVTT

sample2.vtt (NOTE: single newline at end of file)

WEBVTT

00:01:00.000 --> 01:00:00.000
subtitle
@vish91
Copy link
Contributor

vish91 commented May 18, 2022

@kqyang @joeyparrish any thoughts on this ? where in the packager is it exiting out ?
I was able to reproduce this today with another sample.
I had a simple input webvtt like

WEBVTT

00:03:34.882 --> 00:03:37.384 align:center
AMBASSADE et CONSULAT
de l'ÉTAT ARABE du QADIR

And with just this small WEBVTT file it just exits out instead of processing it correctly as a small VTT file with a single cue.

[0518/001023:ERROR:packager_main.cc(554)] Packaging Error: 6 (END_OF_STREAM):

@joeyparrish
Copy link
Member

Good question. I wonder if we have a really basic edge case bug. If you add an empty line or two to the end of the file, does that make a difference?

@dvoracek-slub
Copy link
Author

@joeyparrish Yes, it does make a difference in the case of a single cue (sample2). Processing works when there are two newlines. (It doesn't seem to make a difference in the header-only case.)

@joeyparrish
Copy link
Member

I would bet that our VTT parser is just too strict about the end of the input string. See if you can modify packager/media/formats/webvtt/webvtt_parser.cc and add a new test case to cover this. We would love to have your contribution.

@vish91
Copy link
Contributor

vish91 commented May 23, 2022

Try this PR @joeyparrish @dvoracek-slub
Its difficult to write a test case from the structure where this can be tested, so will need you to tell me that.
webvtt_praser_unittest basically doesn't check the body like we would think so it doesn't check for newlines.
webvtt_muxer probably should but didn't follow what is being asserted there.
I did went ahead and ran all existing tests and ran packager on my sample with single cue and works there.

joeyparrish pushed a commit that referenced this issue Jun 2, 2022
While Parsing cue body check for the block size. 
If it's the last block do not error if it doesn't have a newline.

Fixes #1018
@github-actions github-actions bot added the status: archived Archived and locked; will not be updated label Aug 1, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 1, 2022
sr1990 pushed a commit to sr1990/shaka-packager that referenced this issue Feb 18, 2023
While Parsing cue body check for the block size. 
If it's the last block do not error if it doesn't have a newline.

Fixes shaka-project#1018
sr1990 pushed a commit to sr1990/shaka-packager that referenced this issue Feb 18, 2023
While Parsing cue body check for the block size. 
If it's the last block do not error if it doesn't have a newline.

Fixes shaka-project#1018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated
Projects
None yet
3 participants