ffmpeg 在 Java ProcessBuilder 中运行 HLS - 首先是好的，然后停在一个空的 output 文件上

Question

I am operating ffmpeg in live HLS broadcasting mode, executed by a ProcessBuilder under Java 16. We send PCM audio data via a pipe to the process's stdin. Everything seems to run perfectly at first— I can open the resulting.m3u8 file locally in VLC, and the playback sounds perfect.

Here's my StreamEncoder.java comprising said functionality.

However, after about 10 seconds, the stream stops. There is no visible failure message from ffmpeg or Java. However, I see that the latest file ffmpeg created has 0 bytes.

Here's the full log output from my program. At first, ffmpeg seems to be healthy. Here are some highlights of what's being sent back from the inner ffmpeg process:

ffmpeg version 4.2.4-1ubuntu0.1 Copyright (c) 2000-2020 the FFmpeg developers
Output #0, hls, to '/tmp/livemusic.m3u8':
  Metadata:
    encoder         : Lavf58.29.100
    Stream #0:0: Audio: mp2, 48000 Hz, stereo, s16, delay 481, 128 kb/s

...

[hls @ 0x55c9ac4bb300] Opening '/tmp/livemusic-163910309.ts' for writing
[mpegts @ 0x55c9ac475d40] muxrate VBR, pcr every 4 pkts, sdt every 2147483647, pat/pmt every 2147483647 pkts
Output #0, hls, to '/tmp/livemusic.m3u8':
  Metadata:
    encoder         : Lavf58.29.100
    Stream #0:0: Audio: mp2, 48000 Hz, stereo, s16, delay 481, 128 kb/s
    Metadata:
      encoder         : Lavc58.54.100 mp2
[AVIOContext @ 0x55c9ac4e5b00] Statistics: 0 seeks, 1 writeouts
[hls @ 0x55c9ac4bb300] Opening '/tmp/livemusic.m3u8.tmp' for writing
EXT-X-MEDIA-SEQUENCE:163910309

...

EXT-X-MEDIA-SEQUENCE:163910309
[AVIOContext @ 0x55c9ac4a9a00] Statistics: 0 seeks, 1 writeouts
[hls @ 0x55c9ac4bb300] Opening '/tmp/livemusic-163910316.ts' for writing

After successfully writing the first .ts files, there appears an empty file:

ls /tmp/*.m3u8 /tmp/*.ts -l

-rw-rw-r-- 1 charney charney 168636 Dec  9 18:25 /tmp/livemusic-163910309.ts
-rw-rw-r-- 1 charney charney 168636 Dec  9 18:25 /tmp/livemusic-163910310.ts
-rw-rw-r-- 1 charney charney 168260 Dec  9 18:25 /tmp/livemusic-163910311.ts
-rw-rw-r-- 1 charney charney 168636 Dec  9 18:25 /tmp/livemusic-163910312.ts
-rw-rw-r-- 1 charney charney 168636 Dec  9 18:25 /tmp/livemusic-163910313.ts
-rw-rw-r-- 1 charney charney 168260 Dec  9 18:25 /tmp/livemusic-163910314.ts
-rw-rw-r-- 1 charney charney 168636 Dec  9 18:25 /tmp/livemusic-163910315.ts
-rw-rw-r-- 1 charney charney      0 Dec  9 18:25 /tmp/livemusic-163910316.ts
-rw-rw-r-- 1 charney charney    387 Dec  9 18:25 /tmp/livemusic.m3u8

The ffmpeg process is still running:

ps -aef | grep ffmpeg

charney    22819   22621  0 18:25 ?        00:00:00 ffmpeg -v verbose -i pipe:0 -f hls -ac 2 -c:a mp2 -b:a 128k -minrate 128k -maxrate 128k -hls_playlist_type event -hls_segment_filename /tmp/livemusic-%d.ts -hls_time 10 -initial_offset 163910309 -start_number 163910309 /tmp/livemusic.m3u8

And, ffmpeg appears to be holding on to a filehandle for that empty file:

lsof -p 22819

COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME                                            
ffmpeg  22819 charney  cwd    DIR  253,1     4096 30412671 /home/charney/livemusicproject
ffmpeg  22819 charney  rtd    DIR  253,1     4096        2 /                                                                   
ffmpeg  22819 charney  txt    REG  253,1   280880 24916709 /usr/bin/ffmpeg                                     
(...skipping items like /usr/lib/x86_64-linux-gnu/ ...)
ffmpeg  22819 charney    0r  FIFO   0,12      0t0   319126 pipe                                                        
ffmpeg  22819 charney    1w  FIFO   0,12      0t0   319127 pipe                                                
ffmpeg  22819 charney    2w  FIFO   0,12      0t0   319128 pipe                                                  
ffmpeg  22819 charney    3w   REG  253,1        0 19146562 /tmp/livemusic-163910316.ts                           

When I close my program, which sends a.destroy() to the process, then suddenly and without fanfare, that last file appears at the correct size:

ls /tmp/*.m3u8 /tmp/*.ts -l

(...skipping same same files...)
-rw-rw-r-- 1 charney charney 168636 Dec  9 18:33 /tmp/livemusic-163910316.ts

Answer 1

This is not a proper answer but a rather long comment. The loop looks a bit suspicious as it would be possible for bytes = queue.poll() to be set when .ffmpeg.isAlive() so discarding some input:

while (active) {
    var bytes = queue.poll();
    if (Objects.isNull(bytes)) continue;
    if (!ffmpeg.isAlive()) {
        LOG.error("Exited with code {}", ffmpeg.exitValue());
        active = false;
        continue;
    }

It's hard to help without seeing more of the code including the code feeding queue and what determines end of stream. You need another way to signal end of processing (such as a pre-defined EOF value in the queue - if (bytes == MYEOF) break; . When you determine that no more data is being sent to ffmpeg queue , you could try signalling the end of ffmpeg STD input stream by calling ffmpeg.getOutputStream().close() .

Also you don't call ffmpeg.waitFor() to confirm that the ffmpeg sub-process has ended.