mpv
mpv copied to clipboard
mpv-player
loop-file: add seamless-looping option to ensure that there are no delayed frames at beginning of each loop
With these changes :
- lavf demuxer performs seek to 0 when encountering EOF and does not signal EOF to rest of library
- with these changes, there is a single frame at beginning of each loop with invalid frame time (equal to zero). When this frame is encountered, frame time is set to inverse of container fps
- tested with 30fps and 60 fps content - no delays detected at beginning of each loop
It can be difficult to detect the artifact this PR is designed to fix. The attached file, an MOV of moving text at 30fps, should reveal the problem.
To enable seamless looping, use --loop and --seamless-looping command line args.
https://user-images.githubusercontent.com/95393/195938081-e76a6126-be6a-454e-9e4a-c25e9f9dfedf.mov
@Dudemanguy what are your thoughts on this PR ? small optional changes that fix a real problem with --loop functionality.
Conceptually it seems fine, but I (or someone else) would still need to actually verify the demux internals and all that.
Why would we not do this all the time and not bother adding a new option?
Good question - as the current looping functionality is sub-optimal, we could do this. As long as there are no other ramifications for this change.
any updates on this PR? pretty excited about this one, hopefully it will get passed!
Edit: I have not tested this tho
I've simplified this PR, and it seems to work quite well. The key change is to suppress EOF and pretend that packet PTS and DTS increase indefinitely.
@Dudemanguy @philipl
Any interest in getting this merged ? It does solve a real problem with mpv loop mode....
@Dudemanguy @philipl
@boxerab I agree that the visual effect is what you want, but the management of timing leads to the report length of the clip to increase continuously, faster than the current time counter. This would be very confusing. Is there anything that can be done about that?
@boxerab I agree that the visual effect is what you want, but the management of timing leads to the report length of the clip to increase continuously, faster than the current time counter. This would be very confusing. Is there anything that can be done about that?
Not that I'm aware of.
Another thing to note is that we have other demuxers - most particularly demux_mkv.
It seems like we seek to EOF a bunch of times as part of getting ready to play the clip - at least for an mp4 file - might be due to looking for atoms at the end of the file, so this pushes up the offset multiple times right off the bat. If that could be avoided, it would make the behaviour more intuitive.
Yes, only pushing offset when stream is playing would be a good move. I'm afraid I won't have time in foreseeable future to work on this PR, so let's just keep it on the back burner until someone steps up .
I tried this and still get a black flash between loop iterations, though it seems to sometimes work :slightly_frowning_face:
The black frame is reproducible by pressing . when on the last frame: the player freezes on the black screen.
Also, I can confirm the reporting playback position increases forever, and that is not just a cosmetic issue, it breaks all timing related functionality (seek, etc.), which might've been obvious to those familiar with mpv internals.
Experimenting a bit more, I managed to get the desired effect by manually setting an A/B loop on the first and last frame. I guess this might be doable on the CLI if you figure out the right values for your media.
So I started looking at the code (first time looking at mpv, and even anything video related) to see if I can do that programmatically but didn't manage so yet.
I found the seek_to_last_frame function so IIUC it's not possible to get the PTS (Wikipedia, for noobs like me) of the last frame without actually reading the file up to there, which means it's not possible to do setup an A/B loop in advance.
The current roadblock I'm at is that the handle_loop_file function (which also handles A/B loops) knows the file has ended only after the player has gone past the last frame. Hence the black frame is already displayed. Once I understood that I understood why this PR is implemented directly in the demuxer.
I guess next step is I'll have to read and understand some of the code in video.c to see if the "seek on loop end" logic can be moved there, where it could preemptively ask for another frame.
I'm glad to report back with a patch, see #13296 :)
It works at a higher level than this PR, so it doesn't have the timeline related issues. I'd appreciate feedback and testing from anyone that's interested!
Sorry anyone can help me?
- How can i use this PR in media kit lib for flutter
I'm using:
media_kit: ^1.1.10 # Primary package. media_kit_video: ^1.2.4 # For video rendering. media_kit_libs_video: ^1.0.4
