Re: [crystalhd-development] The time for decoding the first frame is about 0.3 seconds in crystal

[Naren (Narendra) Sankar]

Can you also instrument the time between two successive inputs?

For the first frame output the time could be high because the decoder hunts for a RAP to start decoding without errors. Also there is some pipelining.

However once the decoder starts decoding successive frames should be produced very quickly - less than a frame time. But this assumes the input is being fed at faster than frame time.
Naren Sankar
Broadcom Corporation
+1 408 218 6327

----- Original Message -----
From: crystalhd-...@googlegroups.com <crystalhd-...@googlegroups.com>
To: crystalhd-development <crystalhd-...@googlegroups.com>
Sent: Tue Apr 05 23:11:52 2011
Subject: [crystalhd-development] The time for decoding the first frame is about 0.3 seconds in crystal

Hi,

I add some code to check the time between first video date input and
first frame output.

It takes crystalhd processor about 0.3 seconds to decode the first
frame. The second frame is decoded using about 0.3s too.

Is it normal?

Jerry

--
To post to this group, send email to
crystalhd-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/crystalhd-development?hl=en

[Taylor Ralph]

Naren,

Enormous decoder stalls are nothing new and have been reported by
multiple people including myself and Philip Langdale. I tried the
latest mplayer/ffmpeg code a couple days ago and experienced the
"exact" same decoder stall symptoms that we experience under MythTV as
well as your gstreamer plugin. I've instrumented code to monitor the
input buffer and output delays and when the input buffer is completely
full I observe output delays in excess of 800ms. This same material
that the linux driver chokes on plays perfectly smooth under windows
with crystalhd and windows media player. The sample I've been using as
my test source is Planet Earth which is H.264 interlaced. I sent this
to you a while back.

At any rate, this is a wonderful piece of hardware but if we can't
play the more challenging H.264 content then it's not of much use.

Regards,
--
Taylor

[Philip Langdale]

It's strange. I have blu-ray content that plays back perfectly, and then I see
a sample that's nominally 6Mbps High@4.0 progressive and the hardware
completely falls over. It's clearly more subtle than just bitrate.
I've been able
to work-around by turning on the down-scaling - but I assume that this is
saving time on the copy-out rather than fixing any decoding slowdown.

--phil

[Taylor Ralph]

On Sun, Apr 17, 2011 at 1:26 PM, Philip Langdale <langd...@gmail.com> wrote:
> It's strange. I have blu-ray content that plays back perfectly, and then I see
> a sample that's nominally 6Mbps High@4.0 progressive and the hardware
> completely falls over. It's clearly more subtle than just bitrate.
> I've been able
> to work-around by turning on the down-scaling - but I assume that this is
> saving time on the copy-out rather than fixing any decoding slowdown.
>
> --phil

It's odd that down-scaling can eliminate the problem. If it was simply
a bandwidth issue then you wouldn't expect 800ms type delays. I can
understand the first frame taking some time but after the first frame
is output all subsequent frames should be quite constant with
reasonable delay. This is clearly not the case. It would be nice if
someone would help us out.

I appreciate the work you've done for the ffmpeg/mplayer. It goes well
beyond our attempts to handle all types of video. We will probably
remove our own CrystalHD support and begin using yours when we get a
newer ffmpeg sync.

Regards.
--
Taylor

[Philip Langdale]

Thanks for the kind words. The failure cases I'm seeing are not 800ms situations
but more like 30ms to decode when you only have 40ms to get the frame all the
way out (24fps, etc). When it's that close, reducing the copy-out time
can get the
total time to fit.

--phil