Updated mplayer diff

[Philip Langdale]

Hi all,

Here's my updated mplayer diff with improved interlaced support (at
least for PAFF) and a few minor other cleanups.

--phil

[Philip Langdale]

I've updated the diff again as I've now addressed the input-full
problem I had with
interlaced DVD content; I now try to read the second field before returning from
decode() and that seems to stabilise the buffer.

--phil

[Naren (Narendra) Sankar]

With this patch, have you seen issues with macroblocking on seeking? Forward or backwards doesn't matter.

Naren Sankar (+1 408 218 6327)
Architect/PLM
Broadcom Corp.

--phil

--
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

[Philip Langdale]

On Tue, Jan 4, 2011 at 1:51 PM, Naren (Narendra) Sankar
<nsa...@broadcom.com> wrote:
> With this patch, have you seen issues with macroblocking on seeking? Forward or backwards doesn't matter.

Not per se, but the behaviour of the device after a seek is definitely
different than from a fresh start - the
pipeline seems to build much deeper before frames are delivered. I
have seen macroblocking in situations
where the pipeline fills up yet frames don't seem to show up on the
output reliably and then it appears to
be dropping frames. I could imagine this is more likely to happen after a seek.

--phil

[Naren (Narendra) Sankar]

Does mplayer seek to a valid seek point or just random point?

In case of H.264 for example valid seek points would be IDR frames or RAP SEI. These allow the decoder to start decoding correctly per the compliance spec.

With this behavior it seems mplayer seeks not necessarily to valid seek points.

Naren

[ebsi]

Hi,

i face the following problem with mpeg2 :

this appears in the kernel log :

kernel: Tx Err:: DWORD UNAligned Tx Addr. Not Updating

after that the decoding stops.

[Naren (Narendra) Sankar]

What application are you using? What is the OS and what version of crystalhd library and drivers?

More information would be useful.

----- Original Message -----
From: crystalhd-...@googlegroups.com <crystalhd-...@googlegroups.com>
To: crystalhd-...@googlegroups.com <crystalhd-...@googlegroups.com>

[ebsi]

Archlinux 32bit, kernel 2.6.37, xine, driver and libs in the latest git version.

[Naren (Narendra) Sankar]

Is this repeatable?

The error indicates the firmware gave a unaligned address to the driver which shouldn't happen.

And does this happen with more than one clip?

[ebsi]

It is happening for me with every mpeg2 stream / clip i decode.

[Naren (Narendra) Sankar]

In file crystalhd_fleafuncs.c

In function - crystalhd_flea_update_tx_buff_info

In the printk for the error

Can you print out the actual address that the Firmware returned for TxBuffInfo.DramBuffAdd ?

And also - do you get this error using the gstreamer plugin as well or just the xine plugin?

Thanks

Naren Sankar (+1 408 218 6327)
Architect/PLM
Broadcom Corp.