Rebase Livepeer changes to ffmpeg v7.0.1 #32
Conversation
In intra-only mode, frameIntervalP is 0, which means the frame data array is smaller than the number of surfaces. This causes a crash when closing the encoder. Fix this by making sure the frame data array is at least as big as the number of surfaces.
…n MPEG-7 signature filter (FFmpeg#8)
…livepeer issue #2654) (FFmpeg#30)
|
@j0sh where is the signature_cuda filter used? |
No idea, all I know is the signature filter is still used (not sure by whom) ... unsure if that also means signature_cuda If we can remove signature_cuda then that would simplify a lot of the conflicts here |
|
@thomshutt do you happen to know re: signature_cuda? |
|
From the changelog:
So it looks like it's part of "fast verification", which never made it to Production. The filter is still referenced in LPMS, but I'm happy for you to drop it from there. |
|
Added a new fix in 49b9f4b that should make segmenting more resilient; hopefully it will be incorporated upstream soon. re: signature_cuda, sounds good we can remove it in the next round of updates - probably not worth trying to untangle that right now |
Encoders may emit a buffering period SEI without a corresponding SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. During Annex B conversion, this may result in the SPS/PPS being inserted *after* the buffering period SEI but before the IDR NAL. Since the buffering period SEI references the SPS, the SPS/PPS needs to come first.
DO NOT SQUASH MERGE
Please preserve this list of commits for the next time we have to rebase to a newer ffmpeg. Do a rebase and merge, or merge commit instead
Description
Cherry picked the commits from the livepeer branch to ffmpeg v7.0.1
Post-Merge
n7.0.1-livepeerinstall_ffmpegto avoid the current circular dependencyMerge Conflicts
Most merge conflicts were from us applying a patch to code that had also been changed upstream. This was usually relatively straightforward to resolve, but in the signature filter, we are moving big chunks of code around while that same code was being changed upstream. This meant carefully reviewing all upstream changes and ensuring that those were also reflected in our own (relocated) chunks of code. We need a better way to maintain these changes going forward (including maybe upstreaming the signature_cuda filter), because doing this for each ffmpeg update would be slow, tedious and very error-prone.
This was involved enough that I ended up writing a little script to help verify the changes by comparing a diff of the diffs of both sets of commits against each respective base branch. The tool is a little rough but it did catch a few issues so I am more comfortable with these changes.
Github display of commits
The way Github displays commits is completely wrong; they are listed in commit-date order [1] but this does not reflect the actual ordering of commits in-tree, nor the authorship date. Pull the branch via cli and
git logto see the actual commit ordering and authorship dates.[1] cherry picking overwrites the commit date by default, but I can fix this up to preserve the original commit timestamp if preferred. Author timestamps are already correct, but github does not show this.
git logdoes the correct thing and shows author timestamps.