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

Fix artifacts caused by delayed release of MppPacket data #498

Merged
merged 4 commits into from
Nov 11, 2024

Conversation

nyanmisaka
Copy link
Member

@nyanmisaka nyanmisaka commented Nov 10, 2024

Changes

  • Fix artifacts caused by delayed release of MppPacket data
  • Update dependencies
  • Disable lto on win64 gcc portable build for now
  • Bump version to 7.0.2-6

Issues

  • In RKMPP video encoders, the encoded bitstream data is also located in dma-buf. When the video encoder is fast enough but the audio encoder cannot keep up, more video packets will be queued in the muxer waiting for audio packets for A/V synchronization. The MppPacket data it contains cannot be released in time through buffer callbacks. This causes the kernel driver to not have enough slots to store the new bitstream data and fail some tasks, resulting in encoding artifacts. Async encoding and multi-threaded CLI in FFmpeg 7.0 make this problem even more significant in certain files.

@nyanmisaka nyanmisaka requested a review from a team November 10, 2024 18:12
Copy link
Member

@gnattu gnattu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this approach but does this extra copy hits performance?

@nyanmisaka
Copy link
Member Author

I'm fine with this approach but does this extra copy hits performance?

I observed no significant performance difference. But this may change at extremely high bitrates.

AMF encoders do the same thing, so this should be fine.

@nyanmisaka
Copy link
Member Author

2024-11-10T18:46:02.2160397Z during RTL pass: pro_and_epilogue
2024-11-10T18:46:02.2166835Z libavcodec/aacdec_template.c: In function 'decode_ics.constprop':
2024-11-10T18:46:02.2179816Z libavcodec/aacdec_template.c:2091:1: internal compiler error: in choose_baseaddr, at config/i386/i386.cc:7119
2024-11-10T18:46:02.2180947Z  2091 | }
2024-11-10T18:46:02.2181287Z       | ^
2024-11-10T18:46:02.2406394Z 0x19fc84b internal_error(char const*, ...)
2024-11-10T18:46:02.2407009Z 	???:0
2024-11-10T18:46:02.2419085Z 0x676ac6 fancy_abort(char const*, int, char const*)
2024-11-10T18:46:02.2419702Z 	???:0
2024-11-10T18:46:02.2428457Z 0xe6c010 ix86_expand_prologue()
2024-11-10T18:46:02.2428963Z 	???:0
2024-11-10T18:46:02.2437509Z 0x137774e gen_prologue()
2024-11-10T18:46:02.2438138Z 	???:0
2024-11-10T18:46:02.2446493Z 0x861217 thread_prologue_and_epilogue_insns()
2024-11-10T18:46:02.2447069Z 	???:0
2024-11-10T18:46:02.2452572Z Please submit a full bug report, with preprocessed source (by using -freport-bug).
2024-11-10T18:46:02.2458146Z Please include the complete backtrace with any bug report.
2024-11-10T18:46:02.2463491Z See <https://gcc.gnu.org/bugs/> for instructions.
2024-11-10T18:46:02.2598289Z make[1]: *** [/tmp/ccORMjlI.mk:374: /tmp/ccbccMw9.ltrans124.ltrans.o] Error 1
2024-11-10T18:46:02.2604336Z make[1]: *** Waiting for unfinished jobs....
2024-11-10T18:46:05.5709218Z lto-wrapper: fatal error: make returned 2 exit status
2024-11-10T18:46:05.5709700Z compilation terminated.
2024-11-10T18:46:05.5953024Z /usr/bin/x86_64-w64-mingw32-ld: error: lto-wrapper failed
2024-11-10T18:46:05.6251003Z collect2: error: ld returned 1 exit status
2024-11-10T18:46:05.6261982Z make: *** [ffbuild/library.mak:119: libavcodec/avcodec-61.dll] Error 1

@gnattu
Copy link
Member

gnattu commented Nov 10, 2024

How could aacdec being affected by this? it does not make sense...

@nyanmisaka
Copy link
Member Author

How could aacdec being affected by this? it does not make sense...

Usually just run it again. Otherwise, Ubuntu may have upgraded mingw and broken it.

@Bond-009
Copy link
Member

Disable lto on win64 gcc portable build for now

Is there a specific reason for this? Documenting why it's disabled specifically for this platform seems like a good idea.

@gnattu
Copy link
Member

gnattu commented Nov 11, 2024

Disable lto on win64 gcc portable build for now

Is there a specific reason for this? Documenting why it's disabled specifically for this platform seems like a good idea.

Ubuntu’s recently update breaks GCC LTO in mingw. Our Windows release is using the clang build now so most users won’t be affected, only users specifically choose to use the gcc build will be affected.

@nyanmisaka
Copy link
Member Author

Disable lto on win64 gcc portable build for now

Is there a specific reason for this? Documenting why it's disabled specifically for this platform seems like a good idea.

Because of the compiler error mentioned above...

We currently have no platforms using this build, and enabling LTO in FFmpeg itself does not magically improve performance like assembly and intrinsics.

@nyanmisaka nyanmisaka merged commit af68c43 into jellyfin:jellyfin Nov 11, 2024
27 checks passed
@nyanmisaka nyanmisaka deleted the fix-rkmpp-enc-pkt-free branch November 11, 2024 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants