[FFmpeg-devel] The Crystalhd video decoder is broken - last ffmpeg good commit: 6d160afab2fa8d3bfb216fee96d3537ffc9e86e8

wm4 nfxjfg at googlemail.com
Wed Mar 15 00:35:13 EET 2017


On Tue, 14 Mar 2017 22:44:10 +0100 (CET)
Marton Balint <cus at passwd.hu> wrote:

> On Mon, 13 Mar 2017, Philip Langdale wrote:
> 
> > On Mon, 13 Mar 2017 19:39:35 -0700
> > Philip Langdale <philipl at overt.org> wrote:
> >  
> >> On Tue, 14 Mar 2017 02:49:27 +0100 (CET)
> >> wallak at free.fr wrote:
> >>   
> >> > Indeed 7447ec91b5a692121b81a04c6501a5811d867775 is working; But I
> >> > have the following errors with the last ffmpeg git state:
> >> > [h264_crystalhd @ 0x7fda3c060500] This decoder requires using the
> >> > avcodec_send_packet() API. Last message repeated 456 times ...
> >> > 
> >> > I've 'bisected' this last issue; The last good commit (with ffplay
> >> > -vcodec h264_crystalhd <file> working without error) is the
> >> > following one: 234d3cbf469e9feef255e229202d4b029e66e9fe
> >> > 
> >> > Is there a configuration flag to fix this issue? A software update
> >> > is required?   
> >> 
> >> Heh - I switched the crystalhd decoder to the new send_packet API in
> >> the next change, so that's entirely expected. CrystalHD basically
> >> requires the new API as it allows for flexibility in how often frames
> >> are returned vs submitted to the decoder; I only ever got it barely
> >> working with the old API using vicious hacks that failed in many edge
> >> cases.
> >> 
> >> As it uses the new API, the application using the decoder must also
> >> support the new API. 'ffmpeg' does, but I guess ffplay does not. My
> >> first reaction is to ask why you're using ffplay. I'd recommend using
> >> mpv - which is much more capable, and does support the new API; it's
> >> what I use for all my testing.
> >>   
> >
> > Marton,
> >
> > Would you be interested in updating ffplay to use the new decode API?
> >  
> 
> I think I have something working already, yet I did not post it to the 
> list, because I hoped the new API will support subtitles as well, so I 
> wouldn't have to handle them differently...
> 
> I will try to dig up my old patch and submit it.

Subtitles are a whole different complication, so I wouldn't hold my
breath.


More information about the ffmpeg-devel mailing list