-
-
Notifications
You must be signed in to change notification settings - Fork 142
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
Add patch fixing up segment muxer #9
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a link to the request to add this upstream. We shouldn't be maintaining/requiring a fork of ffmpeg.
I have already sent this patch to ffmpeg-devel list: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/250920.html This wasn't processed yet, though, and I don't think it would become a part of ffmpeg release in a few weeks, so still makes sense for us to patch our ffmpeg instance faster. |
This seems to work very nicely on Windows too. my seek to 300.5 seems to get rounded or truncated to 300.3. But that feels close enough. startInfo.Arguments = string.Format("-report -loglevel warning -hide_banner -progress pipe:2 -vsync passthrough -noaccurate_seek -copyts -ss 300.5 -i \"{0}\" -c:v libx264 -preset veryfast -b:v 80M -segment_time 10 -map 0 -segment_list pipe:1 -segment_list_type csv -f ssegment \"{1}\"", _sourceFile, _outputFilenameFormat); ChunkServer project output:
|
@JustAMan awesome. Please add that link to the commit message and I'll approve. You might as well just combine both commits while you're doing that. |
@nvllsvm PR description updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving as-is. That said:
Based on our Matrix discussions, I don't think we're going to try to port this fix to every possible Linux, Windows, or OSX. This would involve a lot of packaging overhead that I don't think we have time for.
So, that means that this issue will be fixed with our debian-ffmpeg
.deb
packages, and in the Docker build (I believe this is simple to port in right @nvllsvm?). But other distros will either need to extract the ffmpeg from here, or deal with the bug until our patch is merged upstream.
Given that we're not moving to static builds, I might also want to move the patch into the proper Debian location and have dpkg-buildpackage
handle it, instead of this current docker-build.sh
-level patching. That depends on how we're going to integrate this with the Docker build though.
I'm going to obsolete this PR by implement this as a Debian patch and then having the Dockerfile for Docker builds import the patch. |
Re-implemented in #10 |
This should close jellyfin/jellyfin#1694.
Also it provides us the means to add more patches in the future if we wanted to.
This patch was sent to upstream (so we won't have to maintain our custom
ffmpeg
forever), initial thread is here: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/250920.html