[PATCHES] SuperH fixes and VEU vidix improvements

Hi everyone,

Here comes patches with SuperH build fixes and some VEU vidix driver
improvements. Please apply straight away or let me know how you want
me to rework things.

Cheers,

/ magnus

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCHES] SuperH fixes and VEU vidix improvements

Magnus Damm <magnus.damm <at> gmail.com> writes:

> Here comes patches with SuperH build fixes and some VEU vidix driver
> improvements. Please apply straight away or let me know how you want
> me to rework things.

If nobody is able to test, I will apply in a few days.

Carl Eugen

Re: [PATCHES] SuperH fixes and VEU vidix improvements

On Tue, Dec 01, 2009 at 10:39:00PM +0900, Magnus Damm wrote:
> Hi everyone,
> 
> Here comes patches with SuperH build fixes and some VEU vidix driver
> improvements. Please apply straight away or let me know how you want
> me to rework things.

Well, at least the second patch no longer closes the file and thus leaks a file descriptor...

ALSA issue, r29549 fix seems incomplete

I have a 5.1 USB Audio device. I have a custom /etc/asound.conf that
dmixes the surround51 device (plug->route->dmix->hw).
Sound comes from a ac3 (a52 decoded) track extracted from a mkv container.
I get right at file start states in the libao2 alsa play function
where there are "len" bytes to play which is less than the
"ao_data.outburst" buffer size and are not part of a
"AOPLAY_FINAL_CHUNK" chunk.
My understanding of mplayer internals/alsa is limited, so the issue
may be quite worse. On my system, it works.

--- ao_alsa.c.old	2009-12-01 17:26:36.000000000 +0100
+++ ao_alsa.c.new	2009-12-01 17:25:42.000000000 +0100
 <at>  <at>  -773,7 +773,7  <at>  <at> 
 {
   int num_frames;
   snd_pcm_sframes_t res = 0;
-  if (!(flags & AOPLAY_FINAL_CHUNK))
+  if (!(flags & AOPLAY_FINAL_CHUNK) && len > ao_data.outburst)
 	len = len / ao_data.outburst * ao_data.outburst;
   num_frames = len / bytes_per_sample;

Re: ALSA issue, r29549 fix seems incomplete

On Tue, 2009-12-01 at 19:20 +0100, Sylvain Bertrand wrote:
> I have a 5.1 USB Audio device. I have a custom /etc/asound.conf that
> dmixes the surround51 device (plug->route->dmix->hw).
> Sound comes from a ac3 (a52 decoded) track extracted from a mkv container.
> I get right at file start states in the libao2 alsa play function
> where there are "len" bytes to play which is less than the
> "ao_data.outburst" buffer size and are not part of a
> "AOPLAY_FINAL_CHUNK" chunk.
> My understanding of mplayer internals/alsa is limited, so the issue
> may be quite worse. On my system, it works.

That some lengths are rounded to 0 does not in itself imply a problem.
So your post does not explicitly identify any problem that would need
fixing. Is the issue that _all_ calls are rounded to 0, and as a result
no sound plays? If so then the question is what audio parameters trigger
such behavior and how you end up with such values.

Re: ALSA issue, r29549 fix seems incomplete

> Is the issue that _all_ calls are rounded to 0, and as a result
> no sound plays?

Indeed.

To narrow down the real issue:
  - What is the purpose of "ao_data.outburst"?
  - What does make mandatory the amount of bytes passed to the play
function more than "ao_data.outburst"?

Re: ALSA issue, r29549 fix seems incomplete

On Tue, 2009-12-01 at 21:01 +0100, Sylvain Bertrand wrote:
> > Is the issue that _all_ calls are rounded to 0, and as a result
> > no sound plays?
> 
> Indeed.
> 
> To narrow down the real issue:
>   - What is the purpose of "ao_data.outburst"?
>   - What does make mandatory the amount of bytes passed to the play
> function more than "ao_data.outburst"?

Normally ao_alsa.c will pick parameters that make the total ALSA buffer
size a multiple of the outburst value, and so if no audio is yet queued
the amount of free space (the whole buffer) should be more than
outburst. MPlayer will then queue an amount corresponding to the free
space at once (up to a limit of 64 KiB, but I think you shouldn't hit
that with the default parameters).

If you start MPlayer with the -v switch what does the part corresponding
to the quote below say?

alsa-init: got buffersize=65536
alsa-init: got period size 1024
alsa: 48000 Hz/2 channels/4 bpf/65536 bytes buffer/Signed 16 bit Little Endian

Fw: Xine-lib Update Improves A Bit For Blu-ray

URL: http://feedproxy.google.com/~r/Phoronix/~3/IVUkly7zs_w/vr.php
The developers behind the Xine multimedia player have announced the
release of xine-lib 1.1.17. This isn't the major Xine 1.2 library
update that is expected to offer significantly better Blu-ray disc
support along with support for NVIDIA's VDPAU interface, but the 1.1.17
release does carry some interesting features. To be found in xine-lib
1.1.17 is improved Matroska support, fixes for UTF-16 (affecting ID3
tags in particular), support for Apple QuickTime file trailers, better
support for the OpenBSD operating system, and improved support for
unencrypted files on Blu-ray discs...

	***

	I just posted it here so MPlayer could hurry up the support for
Blu-ray discs (I mean, the unencrypted would be great). I don't know if
the patch discussed here some time ago got merged, but as far as I
remember it would handle just encrypted discs (and not BD+ of course).
But I still think it would be much more important to focus on
unencrypted discs, since no software will ever come close to the AnyDVD
HD level capable of decrypting any blu-ray disc (unless you don't care
about BD+ discs).

	So any news on MPlayer blu-ray support?

	Ps: in fact xine can play the same m2ts files MPlayer does, but
Xine at least support PGS subtitles, while MPlayer doesn't.

	Ps2: anyone wanting to port the PGS support from ffmpeg to
MPlayer?

Re: Fw: Xine-lib Update Improves A Bit For Blu-ray

2009/12/1 Dâniel Fraga <fragabr <at> gmail.com>:
>        So any news on MPlayer blu-ray support?

The person who posted that experimental patch tried to grab some
developers and develop libbluray project:
http://my-trac.assembla.com/libbluray/

It's not active for over a month now. Don't know what it really means :|

--

-- 
Rafał
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: ALSA issue, r29549 fix seems incomplete

On Tue, Dec 01, 2009 at 09:01:57PM +0100, Sylvain Bertrand wrote:
> > Is the issue that _all_ calls are rounded to 0, and as a result
> > no sound plays?
> 
> Indeed.
> 
> To narrow down the real issue:

I can't see how your questions would help there.

>   - What is the purpose of "ao_data.outburst"?

To define a kind of block size that the writes to the ao try to observe.

>   - What does make mandatory the amount of bytes passed to the play
> function more than "ao_data.outburst"?

Performance and alignment issues.

Far more interesting would be what the value of ao_data.outburst is in your case
and why len does not not become larger than that.