search

TypesettingTools / Aegisub-Motion

Lua plugin for Aegisub auto4 that parses motion tracking data and applies it to selected subtitles.
Other
172 stars 23 forks source link

"Theoretically it should be impossible to get this error" #46

Closed ToshY closed 5 years ago

ToshY commented 5 years ago

Trying to trim another file resulted in the following error Aegisub thinks your video 0 frames long. Theoretically it should be impossible to get this error.

aegisub_trim

Video details in Aegisub aegisub_video_details

More video details from MediaInfo aegisub_video.txt

So if it's theoretically impossible, is there even an explanation for it 🤔

CoffeeFlux commented 5 years ago

Can you upload the actual file (or a subset displaying the same issue) somewhere, along with your a-mo config and logs? If there are sensitivity or file size concerns, you can pm me on rizon or freenode, though as mentioned in the previous issue responses will be delayed

ToshY commented 5 years ago

Here's a small section of the file. Well I haven't changed anything to the any of the files (just installed this today with DependencyControl). And if you mean the log that's saved to the temp directory, it's empty.

CoffeeFlux commented 5 years ago

I can't reproduce this with that file on my machine. What platform and Aegisub version are you using? Can you verify it happens to you with just that sample? I'm thinking this might be related to you having an old Aegisub version and the encode using 8x8dct, but it's weird since then I don't think the file should open at all...

ToshY commented 5 years ago

Well I downloaded this version just a few days ago (got the link from dependency control).

I checked some of the files in the batch and noticed that some work and some don't. I can't really seem to find any major differences in the video files, so I assume something went wrong when encoding the files or something. I haven't really had this issue with other files (yet) so I hope it's just this batch (but I'm still confused that you can't reproduce the error, so maybe it's indeed something with the software).

CoffeeFlux commented 5 years ago

Are you on Windows 10? Also, just to confirm again, you're able to produce the error with the exact file you sent me? Can you give me the line you're trying to trim on to test with, or does it occur no matter what portion you try to trim?

ToshY commented 5 years ago

Yes I'm using windows 10; and yes that's correct. It doesn't matter which line I want to trim, it still gives me the same error (here's a short recording as "proof").

CoffeeFlux commented 5 years ago

Ah okay, when I use the included subtitles I'm able to reproduce it! I was just timing a random line when testing. Thanks for the video, let me see what's up.

CoffeeFlux commented 5 years ago

This appears to be a confusing error on a-mo's part and some suboptimal behavior in Aegisub itself. The endpoint a-mo is calling here, aegisub.project_properties(), is undocumented for... some reason. In this case, a-mo is using aegisub.project_properties().video_file, which returns a string to the video file referenced in the ASS file. This means that when its length is zero, Aegisub isn't saying the video has 0 frames, but that it's a string of zero length. This mostly comes up when loading subtitles muxed in with video, since it won't automatically change the property when loading them, so even if that value is set it's likely to be wrong.

There are a couple ways to deal with this. First, the error in a-mo should probably be clarified since this has nothing to do with frame count. Upstream in Aegisub, there are two options: either modify this endpoint/add a new endpoint that returns the location of the loaded video or automatically set the project's video file property to the current video file when loading embedded subtitles. I'm inclined to just go with the latter, but I should probably check to make sure the current behavior isn't intentional for some reason. Finally, the project_properties API should be stabilized and documented since popular scripts are making use of it and I don't see any reason for it to constantly be changing.

As for how to work around this in your case, you can just extract the subtitle track from the MKV to a separate file, load the video there, and the issue won't occur.

I'll file an issue on my Aegisub repo to deal with this upstream, and then close this one once the a-mo error is reflective of the actual problem.

ToshY commented 5 years ago

Hmm. Well the work around works, so I'm satisfied for now. Thanks for the help.

CoffeeFlux commented 5 years ago

Filed the Aegisub issue so I don't forget about it: https://github.com/TypesettingTools/Aegisub/issues/41