Closed TheMadog24 closed 4 months ago
Just want to add to this, I fixed the issue with ffmpeg
ffmpeg -i "input.mp4" -itsoffset -0.933 -i "input.mp4" -map 0:v -map 1:a -c copy "output.mp4"
Where "input.mp4"
(both of them) are the input file, and -0.933
is the offset, for this one, it moves the audio forward by -0.933
seconds, delaying the video.
That re-synced the audio with the video properly. So, the issue is definitely with the downloaded file, and not just VLC.
Multiple Cropped videos have the same 0.933
second offset, but some have different offsets, one has 0.5
second offset, one has 1.383
second offset
A reminder that nearly half of the videos I downloaded, that are cropped, do not have any audio sync/delay issues. It seems inconsistent.
EDIT: Probably my last addition, but I can consistently get the audio delay from VOD 1922726622 cropped from 8:04:19 to 9:45:32
Just wanted to know if anyone was able to replicate my findings. Seems to happen to 2/3rds of my cropped files now.
the VOD 1922726622 is no longer online, can you tell another want where it happens to test?
the VOD 1922726622 is no longer online, can you tell another want where it happens to test?
from what I've found, it happens on almost any VOD, just need a cropped VOD, and works better when cropping the start and end. but it doesn't always happen, I would say 2/3 times?
@TheMadog24 thanks for the quick response, let me check with recent streams to see if it still happens. It's a thing that needs to be checked before fixing other issues.
@TheMadog24 thanks for the quick response, let me check with recent streams to see if it still happens. It's a thing that needs to be checked before fixing other issues.
no problem, and thanks! I have been dealing with this since I posted it, but haven't done any cropped VODs recently.
This issue happens because TwitchDownloader
splits the compressed video outside of I-frames (in copy mode), and doesn't recode the affected GOPs, for the sake of speed and simplicity. Until it's fixed, users can do 3 things:
-b 960
do -b 958
, and the same for -e
but increasing, as long as you need. Output files will have some corrupt frames at the beginning, but most video players will automatically skip them alongside with the audio which will not be corrupt.C# doesn't have libraries to do these things natively, so even if it's implemented in TwitchDownloader you will require some ffmpeg libraries or binaries anyway.
I CTRL-F'd the video downloader cs and shoddily fixed this by changing "FromSeconds" to "FromMilliseconds" in block shown below. Its only a work-around, only possible to crop start time, if you try to crop end it will only download a second of it then finish, posting here for folks that don't care about cropping end. :p Only familiar with Python so would likely not be able to find a better solution lol.
private static Range GetStreamListCrop(IList<M3U8.Stream> streamList, VideoDownloadOptions downloadOptions)
{
var startCrop = TimeSpan.FromMilliseconds(downloadOptions.CropBeginningTime);
var endCrop = TimeSpan.FromMilliseconds(downloadOptions.CropEndingTime); // Don't crop end time, it breaks
@Kats-www now sure what you want to do but that doesn't fix anything.
@Kats-www now sure what you want to do but that doesn't fix anything.
Not really wanting to do anything, but doing that fixed the audio desync issue for me (while breaking other things that don't matter to me personally lol).
I CTRL-F'd the video downloader cs and shoddily fixed this by changing "FromSeconds" to "FromMilliseconds" in block shown below. Its only a work-around, only possible to crop start time, if you try to crop end it will only download a second of it then finish, posting here for folks that don't care about cropping end. :p Only familiar with Python so would likely not be able to find a better solution lol.
private static Range GetStreamListCrop(IList<M3U8.Stream> streamList, VideoDownloadOptions downloadOptions) { var startCrop = TimeSpan.FromMilliseconds(downloadOptions.CropBeginningTime); var endCrop = TimeSpan.FromMilliseconds(downloadOptions.CropEndingTime); // Don't crop end time, it breaks
You basically just changed the trim unit from seconds to milliseconds.
This issue happens because
TwitchDownloader
splits the compressed video outside of I-frames (in copy mode), and doesn't recode the affected GOPs
My proposed solution is two-fold:
I have no clue how well it would work, but its the best idea I've had for about a year now. I just haven't gotten around to it because it was relatively low priority.
- Have an option to round the trim times to whole ts files
- When trimming in precise mode, use FFmpeg to re-encode the first/last ts files, then perform the copy finalization.
I did exactly this, however it turns out that re-encoding the first ts file corrupts the rest of video. Not sure why, but it does.
Checklist
Edition
Windows GUI Application
Describe your issue here
When downloading a cropped VOD, the audio is significantly out of sync with the video.
I saw this posted a few times already, #706 , #556 , and #733
in #706 it in mentioned that the problem is VLC, but I can confirm that is not true, all of my VODs are out of sync in every video player, HTML5 player, VLC, inside the timeline of Sony Vegas, After Effects, and Adobe Premiere. the only video player that does not have this issue is Windows Media Player Legacy.
Re-encoding with Handbrake does not change this at all. The video and audio are still out of Sync. When using the "live preview" in HandBrake, it is fixed, but when actually encoding the file, the delay persists.
This happens on
EVERYmost cropped videos that do not start at 0:00:00.This is one of the downloaded files in question: This is not edited, this is exactly how it is, as it was downloaded.
To Re-sync the audio, this specific video needed a
0.933
s offsetI double checked, and not every video has this issue, it seems inconsistent I have 18 videos that I downloaded cropped, only 10 of them have this audio delay issue.
EDIT: Some video Files need a different amount of time offset to re-align the video files
Add any related files or extra information here
No response