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

Large Subtitle offsets cause hard crash. #2161

Open
nicjohnson6790 opened this issue Jun 23, 2019 · 7 comments

Comments

3 participants
@nicjohnson6790
Copy link

commented Jun 23, 2019

While transcoding episodes of a TV show where 4 episodes were in 1 file, I had the chapters set to 19-24 for the fourth episode on the disk.

In order to get the subtitles to line up in the preview encode (going back, even the episodes I got to line up in preview didn't encode lined up correctly, maybe another bug?), I was having to set the offset to -581000ms. When I tried to start the normal encode, Handbrake would allocate memory until it was using all my system's free RAM (~45GB) then would have an allocation error and Windows would force close Handbrake.

Tried using different subtitle files for the specific episode and eventually found that if I set the offset to 0 there weren't any problems, so I assume the large offset is what caused the crash.

My workaround was to encode the episodes to their own files first and then do a second encode to get the subtitles in without an offset.

Handbrake Version:
1.2.2 (2019022300)

OS:
Windows 10 1809

Activity Log:
activity_log12072.txt

@sr55 sr55 added the Bug label Jun 24, 2019

@jstebbins

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

I can't reproduce this, and don't see how the offset could have any affect on memory usage. It simply reads from the file till the offset is reached, discarding what it doesn't need as it goes.

@sr55 sr55 removed the Bug label Jun 26, 2019

@sr55

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2019

@jstebbins try with x264 Blu-ray.iso

Seems to be reproducible when I Import a nearly empty SSA file. Memory spikes 16+ GB

@sr55 sr55 added the Bug label Jul 7, 2019

@sr55 sr55 added this to the 1.3.0 milestone Jul 7, 2019

@jstebbins

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

I still can't reproduce using x264 demo iso. I see no memory usage spike on linux and valgrind shows nothing unusual :-\

Log activity.txt

My srt file is a short sample:

1
00:00:03.500 --> 00:00:07.585
- 356, is there oil?
- Yes, oil.

2
00:00:15.400 --> 00:00:19.409
- 357, oil?
- Yes, oil.

3
00:00:19.520 --> 00:00:23.889
- And 358 also.
- 358 also.

4
00:00:24.000 --> 00:00:27.322
Everything is on the ranch of Little P.
@sr55

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

image
log.txt

Real SSA.txt
(Renamed from .ssa)

Doesn't appear to happen with SRT above.

@jstebbins

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

Still no memory spike for me on linux

activity.txt

@sr55

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

[19:05:19] [ass] Using font provider directwrite

Wonder if the leaks in the front provider, not HandBrake.
Thus why it's not showing up on linux.

@sr55

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

Actually, that would explain why I was seeing other processes crash before all the system ram was fully utilised. Something broken in DirectWrite would impact other windows apps.

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.