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

[Marton Balint]

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.

Regards,
Marton