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

Video/Audio Desync Issue (2.4.0) #463

Open
Mah0uPh0x opened this Issue Jul 27, 2018 · 10 comments

Comments

Projects
None yet
5 participants
@Mah0uPh0x
Copy link

Mah0uPh0x commented Jul 27, 2018

While using the newest version of Attract-Mode for about a week, I started to realize that my video snaps would desync with its audio as it plays.

https://www.youtube.com/watch?v=Cw1mGMmrGdU

As you can see from the video I posted, when Ryu shoots his hadouken, the sound effect and voice do not match up with his action around halfway through the video snap. After this, I replay the video snap in VLC, and its perfectly in sync.

I've also been having problems with certain video snaps stuttering and skipping as well. I've been using the software decoder since the other video decoders (d3d11 and dxva2) do not work.

https://www.youtube.com/watch?v=js1HZSQ4EDA

And this video shows the problems with the hardware video decoders. Some video snaps work, but most of them do not.

FFmpeg: get_buffer() failed FFmpeg: thread_get_buffer() failed FFmpeg: decode_slice_header error FFmpeg: no frame! Error decoding video Error initializing video thread

This is what showed up in my last_run.log file from when I used the hardware decoders.

@Mah0uPh0x Mah0uPh0x changed the title Video Desync Issue (2.4.0) Video/Audio Desync Issue (2.4.0) Jul 27, 2018

@mickelson

This comment has been minimized.

Copy link
Owner

mickelson commented Aug 5, 2018

Do you know if the audio and video were synced before in earlier versions? (2.3)? I'm wondering if something has broken or if this has always been a problem...

@Mah0uPh0x

This comment has been minimized.

Copy link
Author

Mah0uPh0x commented Aug 5, 2018

I do not know. I started with version 2.4. Its the first version I've ever used. Maybe if the hardware video encoder issue gets fixed, it might fix the rest of these desync issues.

@va-lemon

This comment has been minimized.

Copy link

va-lemon commented Sep 18, 2018

I have the same issue with snap videos losing sync with audio in version 2.4 running a Pi 3B+. I can confirm that these videos worked fine under version 2.3. I still have it running on an older Pi 3B. Hardware decoding is enabled with the MMAL option selected. The videos appears to be running slower than the 30fps at which they're encoded. Audio ends but video keeps playing until the end is reached.
As far as I can tell, videos encoded in H264 (640x480 or lower) exhibit this issue. Some system snap videos encoded in XVID seem to play fine.

@eulogy37

This comment has been minimized.

Copy link

eulogy37 commented Mar 7, 2019

I created an account just for this comment. I had this issue in 2.4.0 and all versions beyond on my Pi 3B+. I checked out commit 23264ee and the issue was gone. Working my way forward in commits, the last commit which everything was fine was 793c2f8. Hope this helps.

@Mah0uPh0x

This comment has been minimized.

Copy link
Author

Mah0uPh0x commented Mar 8, 2019

I've tried the latest nightly build of AttractMode, the stuttering and skipping problems are gone, but the videos still desync on my end.

@eulogy37

This comment has been minimized.

Copy link

eulogy37 commented Mar 8, 2019

Try an earlier build as outlined here
http://forum.attractmode.org/index.php?topic=2786.0

@Mah0uPh0x

This comment has been minimized.

Copy link
Author

Mah0uPh0x commented Mar 9, 2019

I'm using Windows, not a raspberry pi or linux, I can't get this to work.

@oomek

This comment has been minimized.

Copy link
Collaborator

oomek commented Mar 16, 2019

I finally found the sourceof the a/v sync issues. It's caused by insufficient resolution of the sf::Time type. The video you posted has a time base of 1/60000 which is 16.666667 microseconds. By converting it to sf::Time we get 16 microseconds, so each frame is rendered 0.66667 microseconds ahead.

Fix in on the way.

@oomek oomek added the bug label Mar 16, 2019

@Mah0uPh0x

This comment has been minimized.

Copy link
Author

Mah0uPh0x commented Mar 16, 2019

Thank you so much! I'm looking forward to testing out the fix.

@oomek

This comment has been minimized.

Copy link
Collaborator

oomek commented Mar 16, 2019

Fix for a/v sync issues #549

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.