[FFmpeg-devel] [PATCH 2/3] ffplay: convert to new decode API

wm4 nfxjfg at googlemail.com
Tue Mar 21 05:31:42 EET 2017


On Mon, 20 Mar 2017 21:49:14 +0100 (CET)
Marton Balint <cus at passwd.hu> wrote:

> On Mon, 20 Mar 2017, wm4 wrote:
> 
> > On Sun, 19 Mar 2017 11:51:28 -0700
> > Philip Langdale <philipl at overt.org> wrote:
> >  
> >> On Fri, 17 Mar 2017 19:42:07 -0700
> >> Philip Langdale <philipl at overt.org> wrote:
> >>   
> >> > On Sat, 18 Mar 2017 01:51:39 +0100 (CET)
> >> > Marton Balint <cus at passwd.hu> wrote:
> >> >   
> >> > > On Sat, 18 Mar 2017, wallak at 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.


More information about the ffmpeg-devel mailing list