Unable to autoplug video/x-h264 decoder

[Sebastian Dröge]

On Fr, 2013-09-13 at 16:07 +0800, Bruce Tsai wrote:
> 
>         
>         Message: 2
>         Date: Thu, 12 Sep 2013 13:26:17 +0200
>         From: Sebastian Dr?ge <slomo at circular-chaos.org>
>         To: Discussions about GStreamer on Android
>                 <gstreamer-android at lists.freedesktop.org>
>         Subject: Re: Unable to autoplug video/x-h264 decoder
>         Message-ID: <1378985177.13310.29.camel at thor.lan>
>         Content-Type: text/plain; charset="utf-8"
>         
>         On Do, 2013-09-12 at 18:17 +0800, Bruce Tsai wrote:
>         > Hi all,
>         >
>         >
>         > I modify Android Tutorial 5 to play mp4 files on Nexus 7
>         (2013 ver.).
>         > Playing sintel_trailer-480p.mp4 and sintel_trailer-720p.mp4
>         is fine.
>         > But playing sintel_trailer-1080p.mp4 shows blank screen.
>         > It seems the video decoder is not available from dumped
>         info.
>         >
>         >
>         > From the log [1], it says No decoder available for type
>         > 'video/x-h264, stream-format=(string)byte-stream,
>         > alignment=(string)au, level=(string)5, profile=(string)high,
>         > width=(int)1920, height=(int)1080, framerate=(fraction)24/1,
>         > pixel-aspect-ratio=(fraction)1/1, parsed=(boolean)true'.
>         >
>         >
>         > I also dumped caps info in sintel_trailer-480p.mp4 and
>         compared these
>         > two caps info.
>         > The only differences are:
>         > level: 5(1080p) vs. 3(480p)
>         > width: 1920(1080p) vs 854(480p)
>         > height: 1080(1080p) vs 480(480p)
>         
>         That happens because the level is different and your hardware
>         claims to
>         not support that level. It probably does, most of the time
>         this
>         information is just inaccurate. This commit should fix it,
>         will be in
>         versions 1.0.11 and 1.1.5.
>         
>         commit 2b94641a421f1aba8c451e718854402b404fe617
>         Author: Sebastian Dr?ge <slomo at circular-chaos.org>
>         Date:   Thu Sep 12 13:21:37 2013 +0200
>         
>             amcvideodec: Don't put the level restrictions on the
>         sinkpad caps
>         
>             They tend to be inaccurate and having them in the sinkpad
>         caps
>             prevents playback of files that would otherwise play fine.
>         
>         
> Many thanks for this fix, this really helps me.
>  
> BTW
> Either in gst_amc_video_dec_handle_frame of gstamcvideodec.c or
> gst_amc_audio_dec_handle_frame of gstamcaudiodec.c, there are two
> checks of "if (self->downstream_flow_ret != GST_FLOW_OK)".
> (gstreamer-1.0-sdk)
> Before the check, there is also a check of "if (self->flushing)".
> Sometimes I got "self->downstream_flow_ret == GST_FLOW_FLUSHING" but
> "self->flushing == FALSE".
> This seems incompatible and causes downstream error.
> Now I reset "self->flushing = TRUE" if "self->downstream_flow_ret ==
> GST_FLOW_FLUSHING" before above checks.
> But do we really need use two flags to indicate the flushing state of
> buffer?
> Or eliminate the flag "self->flushing" to avoid incompatibility?

self->flushing is used to unblock the srcpad thread when we have to
(after having received flush-start event or when shutting down the
pipeline). If downstream returns GST_FLOW_FLUSHING is independent of
that, and we should always propagate that upstream.

It should not cause errors, unless something with the handling of the
flow returns is wrong elsewhere.


What is the exact problem you're seeing, when does it happen and what
happens?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-android/attachments/20130913/9cba1d4a/attachment.pgp>