Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Splitting up some of #141 into this PR in order to make the changes a touch less overwhelming.
Updates FFmpeg to use the Livepeer forked branch at https://github.com/livepeer/ffmpeg
Updates joy4 to fix some breakage resulting from the ffmpeg update. Specifically, this change modified the general libav code to not treat general IO errors as EOF. This broke some tests with the segmenter. Drilling down on the problem revealed that ffmpeg has a stricter view of what constitutes a proper EOF for RTMP : the playback stream needs to be torn down completely. Turns out that joy4 was simply terminating the connection, rather than tearing down the stream following the RTMP protocol. The teardown is added to joy4 here: livepeer/joy4@b2fea45
Fix some other test breakage induced by the ffmpeg update. In particular:
ADTS to ASC bitstream filters are now automatically inserted for the FLV muxer, so going from mpegts to FLV doesn't break anymore. Couldn't find another case which exhibits the same type of breakage, so just removed the test. (Almost everything else that holds AAC metadata in "Audio Specific Config" ASC format is a MP4 variant, and more exotic formats like nut can take basically anything.)
Some encoded file sizes got slightly larger. Haven't looked into precisely what / why but doesn't seem like an issue.
Tightened up the testing around draining GPU filter graphs. Something about the underlying implementation changed and is giving us 2 extra frames now. Sanity checked this against the results produced by the ffmpeg CLI itself: they match.
We have better test for RTMP stream disconnect. The old test broke since the stream is terminated cleanly now, even if no media packets are sent. We work around this by setting up a "server" with
nc
and sending a bogus RTMP handshake to which throws an IO error from ffmpeg. This isn't strictly a network disconnect, but is close enough.