Opened 9 years ago

Closed 8 years ago

#1744 closed defect (fixed)

SDL out freezes

Reported by: Roger Pack Owned by:
Priority: normal Component: avdevice
Version: unspecified Keywords: sdl bounty
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: yes

Description

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.

Attachments (3)

sdl_out_window_shifts.mp4 (1.4 MB ) - added by Roger Pack 9 years ago.
you can see the window location "shifting" at the end, and after that the updates stop
0001-lavd-sdl-add-event-handler-thread.patch (7.6 KB ) - added by Stefano Sabatini 8 years ago.
0002-lavd-sdl-add-event-handler-thread.patch (8.3 KB ) - added by Stefano Sabatini 8 years ago.

Download all attachments as: .zip

Change History (22)

by Roger Pack, 9 years ago

Attachment: sdl_out_window_shifts.mp4 added

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

comment:1 by Carl Eugen Hoyos, 9 years ago

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.

comment:2 by Carl Eugen Hoyos, 9 years ago

Keywords: sdl added

comment:3 by Roger Pack, 9 years ago

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.

comment:4 by Roger Pack, 9 years ago

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

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

comment:5 by Roger Pack, 9 years ago

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).

comment:6 by Elon Musk, 9 years ago

Component: undeterminedavdevice

comment:7 by Roger Pack, 8 years ago

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

Last edited 8 years ago by Roger Pack (previous) (diff)

comment:8 by Bernardo, 8 years ago

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

comment:9 by Acc72, 8 years ago

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.

comment:10 by Roger Pack, 8 years ago

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

comment:11 by llogan, 8 years ago

Keywords: bounty added

Bounty set. See comment:10.

comment:12 by elioxia, 8 years ago

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.

comment:13 by Roger Pack, 8 years ago

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

comment:14 by Stefano Sabatini, 8 years ago

Analyzed by developer: set
Status: newopen

Please test attached patch.

by Stefano Sabatini, 8 years ago

comment:15 by Roger Pack, 8 years ago

@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?

in reply to:  15 comment:16 by Stefano Sabatini, 8 years ago

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.

by Stefano Sabatini, 8 years ago

comment:17 by Roger Pack, 8 years ago

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.

comment:18 by Roger Pack, 8 years ago

ok latest patch seems to work on windows, thanks!

comment:19 by Stefano Sabatini, 8 years ago

Reproduced by developer: set
Resolution: fixed
Status: openclosed

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!

Note: See TracTickets for help on using tickets.