SDL out freezes

[Roger Pack]

Summary of the bug:

Basically, no matter what you play with SDL out in windows, it plays for a few seconds, then output window stops updating. Console continues playing on though.

How to reproduce:

% ffmpeg version N-44123-g5d55830 Copyright (c) 2000-2012 the FFmpeg developers
  built on Sep  2 2012 20:23:29 with gcc 4.7.1 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      51. 70.100 / 51. 70.100
  libavcodec     54. 55.100 / 54. 55.100
  libavformat    54. 25.104 / 54. 25.104
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3. 15.102 /  3. 15.102
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[mpeg2video @ 003ccde0] ac-tex damaged at 40 7
[mpeg2video @ 003ccde0] Warning MVs not available
[mpeg2video @ 003ccde0] concealing 1035 DC, 1035 AC, 1035 MV errors in I frame
[mpeg @ 003cc420] max_analyze_duration 5000000 reached at 5024000
Input #0, mpeg, from '\vids\sintel.mpg':
  Duration: 00:14:47.58, start: 0.233367, bitrate: 4132 kb/s
    Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x480 [SAR 32:27 DAR 16:9], 7000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x80]: Audio: ac3, 48000 Hz, 5.1(side), s16, 448 kb/s
[sdl @ 040812c0] w:720 h:480 fmt:yuv420p sar:32/27 -> w:720 h:405
Output #0, sdl, to 'yo':
  Metadata:
    encoder         : Lavf54.25.104
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR 32:27 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 29.97 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> rawvideo)
Press [q] to stop, [?] for help
[mpeg2video @ 003ccde0] ac-tex damaged at 40 7
[mpeg2video @ 003ccde0] Warning MVs not available
[mpeg2video @ 003ccde0] concealing 1035 DC, 1035 AC, 1035 MV errors in I frame
frame= 1059 fps= 56 q=0.0 Lsize=       0kB time=00:00:38.77 bitrate=   0.0kbits/s
video:536119kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000000%

I think the window is "moving" for some reason, and it's not responding to that. I wonder if the fix is to just integrate with "real" ffplay, but anyway this one reproduces quite easily in windows, just drag the window anywhere and output freezes, basically.

[Roger Pack]

you can see the window location "shifting" at the end, and after that the updates stop

[Carl Eugen Hoyos]

I may not understand the issue, but I cannot reproduce anything similar to "plays for a few seconds, then output window stops updating". ffmpeg -f sdl plays as fast as hardware allows here, no freezes.

[Roger Pack]

seems to reproduce quite readily here (windows 7).
​http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20120914-git-8bdba0b-win32-static.7z

ffmpeg-20120914-git-8bdba0b-win32-static\bin\ffmpeg.exe -i sintel.mpg

-f sdl "title"

I wasn't able to reproduce the failure in Linux however...

To encourage the failure moving the window around while it's playing can sometimes cause the problem to appear more quickly, but it usually only takes about 10 seconds without any help.

[Roger Pack]

some how I missed the original command line. It was basically

$ ffmpeg -i sintel.mpg -f sdl "title"

[Roger Pack]

Current work around is to pipe from ffmpeg to stdout, to ffplay ​http://superuser.com/questions/322216/how-can-i-pipe-output-of-ffmpeg-to-ffplay

Though you might be able to use lavfi with dshow as an input to ffplay (I haven't quite got that one going though).

[Roger Pack]

perhaps it should call SDL_PumpEvents or SDL_PollEvent somehow? See also #1743

[Bernardo]

ping.
Same issue here with latest Zeranoe builds on Windows 8 x64.

[Acc72]

Another ping...
Same issue exists on Windows 7 x64 with lastest Zeranoe build.
Pipe to FFplay is the alternative. However, there are significant latency issues with pipe. SDL output is clean and efficient. Please, can someone look into solving this issue? It's a very handy feature of ffmpeg.

[Roger Pack]

ok $150 bounty for this if anybody wants it...

[llogan]

Bounty set. See comment:10.

[elioxia]

I can confirm ffmpeg does not freeze when calling SDL_PumpEvents() at the end of sdl_write_packet.
Since sdl_write_packet may be called from any thread but windows uses per thread message queue, a proper fix will need a dedicated thread for sdl initialization and messaging.

[Roger Pack]

ok Stefano said he'd be interested in working on this, wish him luck!

[Stefano Sabatini]

Please test attached patch.

[Roger Pack]

@elioxia I'm kind of debating which way to go for this at the moment...if we have a dedicated thread for an SDL device then it prohibits us from (for instance) calling SDL_Init in another thread if we want 2 devices present at the same time, doesn't it? I guess we could live with "at most 1" device (and don't use SDL for anything else in your app!) or is there another way? I suppose we could start with 1, and then later add smarts so that it has one "gui thread" that processes output for multiple windows or something like that...i.e. add support for more than one later whenever anybody actually needs it? Thoughts?

[Stefano Sabatini]

Replying to rogerdpack:

@elioxia I'm kind of debating which way to go for this at the moment...if we have a dedicated thread for an SDL device then it prohibits us from (for instance) calling SDL_Init in another thread if we want 2 devices present at the same time, doesn't it? I guess we could live with "at most 1" device (and don't use SDL for anything else in your app!) or is there another way?

sdl1.2 requires the presence of a single window per application. So there is no way to create different SDL devices (I guess you could have video and audio in different devices, but that would be quite pointless, and complicated...).

I suppose we could start with 1, and then later add smarts so that it has one "gui thread" that
processes output for multiple windows or something like that...i.e. add support for more than
one later whenever anybody actually needs it? Thoughts?

Or use sdl2 which should support that (well at least different windows per application). Anyway this seems unrelated to this ticket.

[Roger Pack]

Sounds from that that with SDL 1.2 we may as well just have a single dedicated event_thread, since "there can be only one." which is basically what the current patch does.

I guess when we move to sdl 2 then we'd either have to do it all in "main" or (probably better) refactor the single dedicated event_thread to handle multiple windows somehow. Thank you.

[Roger Pack]

ok latest patch seems to work on windows, thanks!

[Stefano Sabatini]

Should be fixed in:

commit 7de3b1394b71118279e8f997be490633bc3f5d46
Author: Stefano Sabatini <stefasab@gmail.com>
Date:   Sun Nov 24 19:32:59 2013 +0100

    lavd/sdl: add event handler thread
    
    SDL_Init() is called on the event handler thread, as required by SDL in
    Windows to avoid deadlocks as discovered by Roger Pack.
    
    Fix trac ticket #1743 and #1744.

Thanks for testing!