Opened 4 years ago

Closed 3 years ago

#1744 closed defect (fixed)

SDL out freezes

Reported by: rogerdpack 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 rogerdpack 4 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 saste 3 years ago.
0002-lavd-sdl-add-event-handler-thread.patch (8.3 KB) - added by saste 3 years ago.

Download all attachments as: .zip

Change History (22)

Changed 4 years ago by rogerdpack

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

comment:1 Changed 4 years ago by cehoyos

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 Changed 4 years ago by cehoyos

  • Keywords sdl added

comment:3 Changed 4 years ago by rogerdpack

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 Changed 4 years ago by rogerdpack

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

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

comment:5 Changed 4 years ago by rogerdpack

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 Changed 3 years ago by richardpl

  • Component changed from undetermined to avdevice

comment:7 Changed 3 years ago by rogerdpack

perhaps it should call SDL_PumpEvents or SDL_PollEvent somehow?

Version 0, edited 3 years ago by rogerdpack (next)

comment:8 Changed 3 years ago by jbvsmo

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

comment:9 Changed 3 years ago by 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.

comment:10 Changed 3 years ago by rogerdpack

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

comment:11 Changed 3 years ago by llogan

  • Keywords bounty added

Bounty set. See comment:10.

comment:12 Changed 3 years ago by 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.

comment:13 Changed 3 years ago by rogerdpack

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

comment:14 Changed 3 years ago by saste

  • Analyzed by developer set
  • Status changed from new to open

Please test attached patch.

comment:15 follow-up: Changed 3 years ago by 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? 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?

comment:16 in reply to: ↑ 15 Changed 3 years ago by saste

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.

comment:17 Changed 3 years ago by rogerdpack

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 Changed 3 years ago by rogerdpack

ok latest patch seems to work on windows, thanks!

comment:19 Changed 3 years ago by saste

  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from open to closed

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.