On Mon, 20 Mar 2017 21:49:14 +0100 (CET) Marton Balint <c...@passwd.hu> wrote:
> On Mon, 20 Mar 2017, wm4 wrote: > > > On Sun, 19 Mar 2017 11:51:28 -0700 > > Philip Langdale <phil...@overt.org> wrote: > > > >> On Fri, 17 Mar 2017 19:42:07 -0700 > >> Philip Langdale <phil...@overt.org> wrote: > >> > >> > On Sat, 18 Mar 2017 01:51:39 +0100 (CET) > >> > Marton Balint <c...@passwd.hu> wrote: > >> > > >> > > On Sat, 18 Mar 2017, wal...@free.fr wrote: > >> > > > >> > > > The logs: http://pastebin.com/1duYR0Ui > >> > > > > >> > > > >> > > Log with video only (run ffplay with -an -sn) might show it more > >> > > clearly, but even from the logs above it looks like the CrystalHD > >> > > codec is returning EAGAINs at the same time for both receive_frame > >> > > and send_packet. If it indeed does work in ffmpeg, then I suspect a > >> > > lot of busy waiting there. Philip, you mind taking a look? :) > >> > > >> > My first reply got HTML-ised by my client. Weird. > >> > > >> > Wallak, > >> > > >> > Can I get a sample from you to ensure I can repro. Also: are you using > >> > a 12 or a 15? I only have a 15 and have never tested the code with a > >> > 12. Also, it would be great if you can test playback with mpv. As I > >> > said, that's what I've used for testing. > >> > >> I did take a brief look, and I confirmed that mpv works fine but ffplay > >> is hitting this deadlock between send and receive. My hardware is > >> getting flaky, and my actually be dying, so it's hard for me to do any > >> kind of systematic testing. > >> > >> So right now my only useful advice is to look at how mpv is running the > >> loop and see if there's a significant difference. > > > > Currently, mpv pretty strictly does essentially: > > > > while (1) [ > > if (!packet) > > packet = read_new_packet(); > > if (send_packet(packet) == ok) > > packet = NULL; > > receive_frame(); > > } > > > > which I guess is a bit unusual for API usage. > > > > The API should be able to deal with any of that, though. > > ffplay is: > > while (1) { > while (receive_frame() != EAGAIN) { > } > send_packet(read_new_packet()) > } > > I can change it to buffer the packet if send_packet() returns EAGAIN, even > if it is should not be neede, but let's see if it makes a difference or > not. Yes, that should indeed not be needed according to the API. ffmpeg.c doesn't do that either. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel