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

[wallak at free.fr]

----- Mail original -----
De: "wm4" <nfxjfg at googlemail.com>
À: ffmpeg-devel at ffmpeg.org
Envoyé: Lundi 20 Mars 2017 04:23:43
Objet: Re: [FFmpeg-devel] [PATCH 2/3] ffplay: convert to new decode API

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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



-----
On my side, I've checked with a crystalhd BCM970015 (I've a 12 stored somewhere). The issue is likely not related to the h264 stream itself.

Wallak.