Aegisub
Aegisub copied to clipboard
wangqr
A/V Sync Problem in 9039 Build
As you can see it the screenshot, 9039 (right) has the audio out of sync with the video compared to 3.2.2 (left). I just loaded the same subtitle and video file and selected the same line. 9039 is about 3 seconds too late, if you time it to where the audio is.
Does r8942 has this issue? I remember either there is a change in the audio sync parameter given to ffms2 between 3.2.2 and r8942, or there is a ffms2 version update.
I've also upgraded ffms2 in 3c2414c0df34648be86aa41ac3cc9c8066815aa3 (9036). Can you give 9031 and 9036 a try, and see if it first happens in 9036?
And, it would be nice if you can provide a sample video. If not, can you check if there is 3s silent at the beginning of the audio (offset error) or the audio is stretched (speed error). And, if your video player supports showing MediaInfo, look for the audio offset value there and see if it matches the offset you are seeing
9031 works; 9036 doesn't.
I don't know how to provide a video sample. However, the video is "synced" at the beginning and gets worse as the file goes on as if there's a set rate/sec that it's going out of sync.
I don't see an audio offset value in it's media info. Also, the audio starts playing the OP right away.
You may want to open an issue at FFMS/ffms2 and/or ffmpeg. Or if you don't want to, I can do that once I have time.
| dependency | r8942 | r9036 | diff |
|---|---|---|---|
| ffms2 | FFMS/ffms2@f3c6b008b53719dcac032293e3a42a3164c8d7ec | FFMS/ffms2@aaf4cc0802aef7ca45cb063794e95693d27f69d5 | https://github.com/FFMS/ffms2/compare/f3c6b008b53719dcac032293e3a42a3164c8d7ec...aaf4cc0802aef7ca45cb063794e95693d27f69d5 |
| ffmpeg | FFmpeg/FFmpeg@d290bb0c540425e937d11ed88e22c68ab97c57eb | FFmpeg/FFmpeg@1529dfb73a5157dcb8762051ec4c8d8341762478 | https://github.com/FFmpeg/FFmpeg/compare/d290bb0c540425e937d11ed88e22c68ab97c57eb...1529dfb73a5157dcb8762051ec4c8d8341762478 |
I don't know how to provide a video sample.
Just upload the video that has this issue somewhere and paste a link here, if that is OK.
I would prefer that you open the issue. I'm not really that computer savvy; I just use Aegisub a lot on many different files.
The video is over 2GB and is at a private tracker, unfortunately.
In the meantime you may try to re-encode the video. This may fix some issue with the video itself.
I don't know how to do that either, unfortunately. The video does play fine in MPC-HC.
Since you have ffmpeg, you may try remuxing using
ffmpeg -i Input.mkv -c copy Out.mkv
or re-encoding
ffmpeg -i Input.mkv Out.mkv
and see if the result video has the issue.
Yes, the audio is synced at the beginning and gets worse throughout the episode. The initial screenshot I posted is from near the end of the episode It's as if it de-syncs at a set rate through out the episode. r9045 does the same thing.
I actually don't know how to use FFmpeg; someone wrote the command line for me. I can try the ones you just posted, but I can't guarantee I'll be successful.
The first command line resulted in the out of sync issue as before.
The second command line resulted in a correctly synced video/audio/subtitle.
Both on r9045.
@MadokaAyukawa
cut video using ffmpeg without reencoding:
ffmpeg -i input.mkv -ss 00:01:00 -to 00:01:00 -c copy output.mkv
-ss - start time
-to - duration
time format is HH:MM:SS
The second command line resulted in a correctly synced video/subtitle.
If you still have the re-encoded result, can you verify if the audio track matches the original file when loaded into Aegisub?
And, what's the version of your ffmpeg? (Can be checked using ffmpeg -version)
Thank you, both of you, for helping me with FFmpeg.
The second command line produced a video that is synced video/audio/subs, like in 3.2.2 and r9031.
The original video has this mediainfo:
General
Unique ID : 209094129594269384170167347152895005396 (0x9D4E108591F5E6B5AACF953F27E2D2D4)
Format : Matroska
Format version : Version 2
File size : 2.00 GiB
Duration : 1 h 10 min
Overall bit rate : 4 058 kb/s
Encoded date : UTC 2012-01-21 08:44:53
Writing application : mkvmerge v2.9.7 ('Tenderness') built on Jul 1 2009 18:43:35
Writing library : libebml v0.7.7 + libmatroska v0.8.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings : CABAC / 6 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 6 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 10 min
Nominal bit rate : 3 736 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.135
Writing library : x264 core 68 r1183M f21daff
Encoding settings : cabac=1 / ref=6 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=12 / nr=0 / decimate=1 / mbaff=0 / bframes=6 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=3736 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=50000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : A_AAC-2
Duration : 1 h 10 min
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Language : Chinese
Default : Yes
Forced : No
The re-encoded video has the following mediainfo:
General
Unique ID : 176191399937282928888931389796930615911 (0x848D3AB3F2692CCB2BEED6C9D258FA67)
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.01 GiB
Duration : 1 h 10 min
Overall bit rate : 2 055 kb/s
Writing application : Lavf57.71.100
Writing library : Lavf57.71.100
ErrorDetectionType : Per level 1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 10 min
Bit rate : 1 822 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Stream size : 920 MiB (89%)
Writing library : x264 core 152 r2851 ba24899
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 1 h 10 min
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 97.0 MiB (9%)
Writing library : Lavc57.89.100 ac3
Language : Chinese
Service kind : Complete Main
Default : Yes
Forced : No
I'm using FFmpeg 3.3.4. Newer versions of FFmpeg have a bug(?) where it does not render the blur tags from Aegisub correctly. Instead of applying them just to the border, the entire border and body of the text will be blurred, many times rendering it unreadable. I have tried all stable releases after 3.3.4.
Since you are using a old version of ffmpeg, matching the old behavior is a reasonable result. If you have time, you can try the re-encoding with ffmpeg 4.2.1 (official windows build at https://ffmpeg.zeranoe.com/builds/win64/shared/?C=M , and this is the version used by r9036) and see if the output matches the new version. And if you have more time you can bisect all the ffmpeg versions there and find the first bad version.
Newer versions of FFmpeg have a bug(?) where it does not render the blur tags from Aegisub correctly.
I think that is another issue since we are not using ffmpeg to embed ass here, we are just re-encoding the video. ffmpeg internally use libass to load ass subtitles, and should match the behavior if you use libass as the subtitle provider when using Aegisub (Preferences -> Advanced -> Video -> Subtitle Provider).
I have always gotten the static releases. Should I be getting the shared? And I don't know what the difference between the 2 are.
I just changed the subtitle provider to libass, and r9031 blurred the text just as I had described. Now I'm confused. Which setting should I use to make subtitles so that the viewers have the correct visual experience? There is a very good subber who uses a lot of blur tags, and their subs do not render correctly in any FFmpeg > 3.3.4. Also, then this is a libass issue rather than an FFmpeg issue?
I have always gotten the static releases. Should I be getting the shared? And I don't know what the difference between the 2 are.
Static release doesn't have those dlls and the exe itself is bigger. As for function there is no difference.
I just changed the subtitle provider to libass, and r9031 blurred the text just as I had described.
This maybe means that libass has always implemented that way, which differs from VSFilter. If you are going to hardsub the video, just make sure using the same subtitle renderer as when encoding. However if you distribute the ass file directly, then it depends on the subtitle renderer of the video player. libass is widely used in non-Windows systems.
I've done a quick test and libass seems ignoring bord < 0.25.
The
\blurtag blurs the edges of the text, not everything. This means that if the text has a border (set with\bord) the border will be blurred, but if there is no border, the main text will be blurred instead.
Which means that if you are using a \bord < 0.25 together with \blur, the text will be blurred on libass, but not on VSFilter.
Yes, that is what I have noticed as well, that thin borders seem to be ignored or the blur on thin borders extended to the body of the text. I am assuming this is a bug in libass?
I am currently encoding that video file with 4.2.1.
Actually VSFilter also ignores small border < 0.0625. If you want you can open a issue at libass. I think they tries to match VSFilter's behavior when reasonable. Meanwhile you can use some thicker border to make sure it is rendered properly across devices / players.
The encoded file from 4.2.1 syncs correctly across video/audio/subs in r9045, just like 3.2.2.
The encoded file from 4.2.1 syncs correctly across video/audio/subs in r9045, just like 3.2.2.
Looks like some issue with the video itself (metadata, timestamp, etc.) since re-encoding can fix the problem. However it is still strange if the ffmpeg executable can read the video with A/V syncs correctly while ffms2 with same version of ffmpeg does not.