GNOME Bugzilla – Bug 705090
Bink playback doesn't work
Last modified: 2016-04-25 14:36:04 UTC
I think it may just be that typefind doesn't have the correct mapping: $ GST_DEBUG=3 gst-launch-1.0 playbin uri=file:///home/frank/gst/a.bik Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Could not determine type of stream. Additional debug info: gsttypefindelement.c(1044): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... 0:00:00.054275675 25094 0x1ea6540 WARN typefind gsttypefindelement.c:1128:gst_type_find_element_loop:<typefind> error: stream stopped, reason error Freeing pipeline ...
00:00.230255317 29494 0x2130140 LOG libav gstavdemux.c:1888:gst_ffmpegdemux_register: Attempting to handle libav demuxer plugin bink [Bink] 0:00:00.230261359 29494 0x2130140 DEBUG libav gstavdemux.c:1996:gst_ffmpegdemux_register: ignoring bink
Created attachment 250391 [details] [review] Fixes the typefind, but now there's more hurdles.
Created attachment 250396 [details] [review] fix naming, still incomplete
Review of attachment 250391 [details] [review]: So this is a container format, video codec and audio codec? Each of them should get different caps ::: gst-libav-1.0.6/ext/libav/gstavcodecmap.c @@ +923,3 @@ + case CODEC_ID_BINKVIDEO: + caps = + gst_ff_vid_caps_new (context, codec_id, encode, "video/binkvideo", Should be video/x-bink @@ +924,3 @@ + caps = + gst_ff_vid_caps_new (context, codec_id, encode, "video/binkvideo", + "format", G_TYPE_STRING, "I420", NULL); Is the format really relevant here?
Can you also provide a sample file?
I'll fix the format and mime type. I'm not sure what I'm doing-- looking at the code base for the first time. Samples here: http://samples.mplayerhq.hu/game-formats/bink/
This is what it says now, with these changes.. Pipeline is PREROLLING ... 0:00:00.046730172 29089 0x24afb70 ERROR libav :0:: invalid header: more than 1000000 frames 0:00:00.046797382 29089 0x24afb70 WARN libav gstavdemux.c:1240:gst_ffmpegdemux_open:<avdemux_bink1> error: Input/output error 0:00:00.046888033 29089 0x24afb70 WARN libav gstavdemux.c:1502:gst_ffmpegdemux_loop:<avdemux_bink1> error: Internal data stream error. 0:00:00.046910960 29089 0x24afb70 WARN libav gstavdemux.c:1502:gst_ffmpegdemux_loop:<avdemux_bink1> error: streaming stopped, reason error ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/avdemux_bink:avdemux_bink1: GStreamer encountered a general supporting library error. Additional debug info: gstavdemux.c(1240): gst_ffmpegdemux_open (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/avdemux_bink:avdemux_bink1: Input/output error ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... 0:00:00.047128288 29089 0x24a5f70 WARN libav gstavdemux.c:1453:gst_ffmpegdemux_loop:<avdemux_bink0> stream_movi flow: flushing / flushing
It looks like it's trying to read the header twice. 0:00:00.298405258 5704 0xb7e770 DEBUG libav gstavdemux.c:1146:gst_ffmpegdemux_open:<avdemux_bink0> av_open_input returned 0 Can someone enlighten me on what avdemux_bink1 is ? My understanding is that it's another instance of the demuxer, and that may be the cause?
Created attachment 250656 [details] [review] Simpler diff to add the codec mapping Here's a diff, that adds the bink mapping, and adds bink, like "smk" (smacker) to the demuxer marginal list. It looks like there's multiple bink versions, and different decoder code that switches on codec_tag, that is correctly set by the bink demuxer, but it's 0 when the decoder looks at it (or a different context?) If it fudge the codec_tag in libavcodec/bink.c, and I can get correct playback.
Created attachment 250745 [details] [review] Pass bink version in extradata, instead of codec_tag It looks like when streams are copied, the codec_tag isn't always copied, so I changed the demuxer's read_header to pass the version info in extradata instead of codec_tag. This is a (bug?) in libav, I believe.
Using those two patches works great for me!
Comment on attachment 250745 [details] [review] Pass bink version in extradata, instead of codec_tag This would have to be changed in libav upstream. We don't change libav ourselves and also want to be able to run with a system version of it installed.
Review of attachment 250656 [details] [review]: You should use a proper caps type for bink and smack, like video/x-bink, audio/x-bink,variant=(string)dct, etc.
Anybody planning to continue to work on this, either by getting patches into libav or using whatever libav now provides?
No interest for three years, let's close this. If anyone feels like updating the patches, please re-open, thanks!