Some streams are being closed without a reason in latest ffmpeg

[BlackDream]

Hello,

I noticed that some streams are being closed in the last branch of ffmpeg 2.5.x. THE SAME DIDN'T HAPPEN in 2.4.x and probably in the previous versions as well.

I don't know the real reason of it since ffmpeg does not output any error, it just closes without a reason.

It's not a stream problem 10000%, since exactly THE SAME TIME i tried with FFmpeg 2.4.5 and it works perfect. I also started the streams multiple times to ensure that it is a bug.

I tried it with the latest git version, and same happens so i will just use the FFmpeg 2.5.3 in this bug report.

ffmpeg -re -y -fflags +genpts -probesize 10000000 -analyzeduration 15000000  -i "STREAM_URL"  -strict -2 -dn -c copy  -hls_time 12 -hls_list_size 5 -hls_wrap 15 "/tmp/20_.m3u8"


ffmpeg version 2.5.3 Copyright (c) 2000-2015 the FFmpeg developers
  built on Jan 10 2015 08:04:28 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --prefix=/root/ffmpeg/target --extra-cflags='-I/root/ffmpeg/target/include -static' --extra-ldflags='-L/root/ffmpeg/target/lib -lm -static' --disable-debug --disable-shared --enable-static --extra-cflags=--static --disable-ffplay --disable-ffserver --disable-doc --enable-openssl --enable-gpl --enable-pthreads --enable-postproc --enable-libass --enable-gray --enable-runtime-cpudetect --enable-libfaac --enable-gnutls --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-bzlib --enable-zlib --enable-nonfree --enable-version3 --enable-libvpx --enable-libxavs --disable-devices --enable-librtmp --extra-libs='-lrtmp -lnettle -lhogweed -lgmp -lssl -lcrypto -lz -lc -ldl'
  libavutil      54. 15.100 / 54. 15.100
  libavcodec     56. 13.100 / 56. 13.100
  libavformat    56. 15.102 / 56. 15.102
  libavdevice    56.  3.100 / 56.  3.100
  libavfilter     5.  2.103 /  5.  2.103
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mpegts, from 'STREAM_URL':
  Duration: N/A, start: 45431.824311, bitrate: 129 kb/s
  Program 1
    Stream #0:0[0x44](eng): Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
    Stream #0:1[0x45](fra): Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 129 kb/s
Output #0, hls, to '/tmp/20_.m3u8':
  Metadata:
    encoder         : Lavf56.15.102
    Stream #0:0(eng): Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 90k tbn, 23.98 tbc
    Stream #0:1(fra): Audio: aac ([15][0][0][0] / 0x000F), 44100 Hz, stereo, 129 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[mpegts @ 0x32b1e20] PES packet size mismatch0:16.14 bitrate=N/A
frame=  390 fps= 24 q=-1.0 Lsize=N/A time=00:00:16.28 bitrate=N/A
video:5660kB audio:259kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

It just says PES packet size mismatch (in yellow colors) and closes without any other error.

The same happens if i output the same stream into mpegts.

IMPORTANT NOTE 1

I noticed that without -probesize 10000000 -analyzeduration 15000000 IT WORKS but even in this case, it is a bug, it shouldn't happen. In FFmpeg v2.4.x that works even with these arguments in the command.

IMPORTANT NOTE 2

I also noticed that by applying +nobuffer in the -fflags it works and the stream doesn't close, however still seems to be a bug in me.

IMPORTANT NOTE 3

+genpts doesn't affect anything.

[BlackDream]

IMPORTANT NOTE 4

If i don't use the -re argument (native frames) the stream doesn't close! With it, it closes with the error above (PES packet size mismatch).

Hope you can reproduce it with all these information. And remember in v2.4.x that was fine no matter the arguments i will use.

[Michael Niedermayer]

please provide the input stream and a minimal testcase
if as you say it happens with mpegts instead of hls use mpegts, if it happens without -re then dont use -re.
Also if it worked before please use git bisect and find the revission which broke it

Ive tried it locally but i dont see a problem but then iam also not completely sure what you mean by
"Some streams are being closed"

[BlackDream]

I have no idea how to use bitsect currently so i have to find someone else to do that for me.

MPEGS/HLS the same happens it's not muxer related.

Yes i can make it work without -re it's not a problem for me. But since in the ffmpeg v2.4.x that wasn't exists i guess it could be a bug so i posted here to be fixed.

The problem is i can't provide sample because with a "static file" that doesn't happen. It only happens remotely.

For example if i take the TESTED stream above using wget (since it comes from HTTP protocol) and save it into a file, then if i use ffmpeg to remuxing into mpegts i don't get any error.

So the problem should be when using the -re and when the host is remote. But still that doesn't happen in all streams.... It's quite complicated and strange.

I also tried using FFmpeg 2.5.0 and same happens, so i guess it must be something that changed regarding this v2.4.5 and v2.5.0.

I will try to find someone to bitsect it for me

Thank you

[Michael Niedermayer]

Please reopen when a (minimal) testcase has been provided. This can of course involve a http server or other if as you say it doesnt reproduce locally