Support Windows 10

[smacke]

Another user wrote:

Windows 10 / Python 3

Installed ffmpeg with chocolaty.

When I run the following command it outputs the following and does nothing:

subsync 01.mkv -i 01.srt -o 01x.srt
extracting speech segments...
0%| | 0/3575.168 [00:00<?, ?it/s]

I see that ffmpeg is running with the following options but it seems to be doing nothing.

ffmpeg.exe -i 01.mkv -f s16le -ac 1 -acodec pcm_s16le -ar 48000 -

See #4

[postacik]

Thanks for thinking of the Windows users. :))

[rasa]

On a Windows 7 x64 box, using Python 2.7.15 and 3.7.2, I had issues with subsync freezing running ffmpeg. After about 15 seconds, or ~60% the way thru a 1.6GB .mp4, the progress bar would just stop. The CPU didn't peg, but the progress bar just got stuck. I couldn't Ctrl-C, I had to kill the app with Task Manager. I found that if I changed quiet=True to quiet=False at https://github.com/smacke/subsync/blob/master/subsync/subsync.py#L114 , then it would complete without locking up.

[smacke]

For Windows 7, see also #19. @rasa this suggests to me that maybe on Win7 (or maybe just for your video), the stderr pipe is filling up. Probably ffmpeg is getting chatty on stderr (as it sometimes does) about 60% of the way through processing. Since there's nobody reading stderr, maybe that's why it is hanging.

The typical way around this is to use subprocess.communicate, but I want to avoid reading all of stdout and stderr at once since a lot of data can get written to stdout in this case. Another thing we can do is just show the output of stderr, but I'd like to avoid this if possible. Ideally we would send stderr to /dev/null, but ffmpeg-python doesn't expose this very well. My solution is to spawn a separate thread that consumes stderr; see 1ea37d513fafa7a013590798d3154c167848a3b9.

@rasa if you reinstall via pip install git+https://github.com/smacke/subsync I think your problem should go away; if not please let me know.

[smacke]

@postacik I am starting to think that the issue you experienced in #4 might be the same as what @rasa experienced here, especially given the strange behavior re. mkv files. If you have a moment to test on your failing cases after reinstalling (via pip install git+https://github.com/smacke/subsync), I am very keen to hear the result!

[postacik]

I did pip install git+https://github.com/smacke/subsync and then retried with mkv file.

It took some time to start extracting speech segments but voila!

subsync x.mkv -i i.srt -o o.srt
INFO:subsync.subsync:extracting speech segments...
431.35710416666666it [00:02, 163.38it/s]
INFO:subsync.subsync:...done.
INFO:subsync.subsync:computing alignments...
INFO:subsync.subsync:...done.

Thanks...

[rasa]

@smacke After reverting my hack, and upgrading, I am unable to reproduce the lockups, after testing with multiple inputs. Thanks for the quick fix!

[kylege]

For Windows 7, see also #19. @rasa this suggests to me that maybe on Win7 (or maybe just for your video), the stderr pipe is filling up. Probably ffmpeg is getting chatty on stderr (as it sometimes does) about 60% of the way through processing. Since there's nobody reading stderr, maybe that's why it is hanging.

The typical way around this is to use subprocess.communicate, but I want to avoid reading all of stdout and stderr at once since a lot of data can get written to stdout in this case. Another thing we can do is just show the output of stderr, but I'd like to avoid this if possible. Ideally we would send stderr to /dev/null, but ffmpeg-python doesn't expose this very well. My solution is to spawn a separate thread that consumes stderr; see 1ea37d5.

@rasa if you reinstall via pip install git+https://github.com/smacke/subsync I think your problem should go away; if not please let me know.

you don't have to use ffmpeg-python, just do something like this:

    args = [
        'ffmpeg',
        '-loglevel', 'fatal',
        '-nostdin',
        '-i',
        fname,
        '-f', 's16le',
        '-ac', '1',
        '-acodec', 'pcm_s16le',
        '-ar', '48000',
        '-'
    ]
    process = subprocess.Popen(args, stdin=None, stdout=subprocess.PIPE, stderr=None)

[smacke]

@postacik @rasa Thank you both so much for confirming the fix!

@hichenming I think your strategy probably makes more sense; we're not really using much of the functionality of ffmpeg-python, and the extra readability maybe isn't worth the extra dependency...

[calloatti]

I know nothing about Python, but I do use ffmpeg in Windows 10 using createprocess and pipes. ffmpeg windows builds only output to stderr on Windows, you will get nothing on stdout.