April 2008 - MPlayer-dev-eng - lists.mplayerhq.hu

Another sample from norway
by Håkon Alstadheim 27 Aug '09

27 Aug '09

This is just to motivate anybody having a spare 5 minutes into working receiving the norwegian dvb-t broadcasts ... (should also interest people from NZ) :-) I've uploaded another sample to incoming, filename hakon.alstadheim.priv.no.nrk3.ts. Attaching the standard output and error when playing below. As you can see I have patched my mplayer to force 25 fps framerate. Seems that patch no longer works as intended, but the straight (non-patched) mplayer gives similarily discouraging results when viewing. Happy hacking everybody :-) . If you want more debugging output, just tell me what and I'll try to comply. -------------------- MPlayer dev-SVN-r26171-4.1.2 (C) 2000-2008 MPlayer Team CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (Family: 15, Model: 2, Stepping: 4) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 Playing hakon.alstadheim.priv.no.nrk3.ts. TS file format detected. VIDEO H264(pid=521) AUDIO AAC(pid=676) NO SUBS (yet)! PROGRAM N. 103 FPS seems to be: 25.000000 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ========================================================================== Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding) versionA not supported FAAD: compressed input bitrate missing, assuming 128kbit/s! AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400) Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio) decoder) ========================================================================== AO: [oss] 44100Hz 2ch s16le (2 bytes per sample) Starting playback... FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: Failed to decode frame: Invalid number of channels [h264 @ 0x88d3070]left block unavailable for requested intra mode at 0 4 [h264 @ 0x88d3070]error while decoding MB 0 4, bytestream (24666) FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Quantised value out of range, trying to resync! FAAD: error: Quantised value out of range, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: Failed to decode frame: Gain control not yet implemented VDec: vo config request - 720 x 576 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.82:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1048x576 Planar YV12 [ASPECT] Warning: No suitable new res found! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Unexpected fill element with SBR data, trying to resync! FAAD: Failed to decode frame: Unexpected fill element with SBR data [h264 @ 0x88d3070]B picture before any references, skipping [h264 @ 0x88d3070]decode_slice_header error [h264 @ 0x88d3070]no frame! Error while decoding frame! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Scalefactor out of range, trying to resync! FAAD: error: Pulse coding not allowed in short blocks, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: Failed to decode frame: Gain control not yet implemented [h264 @ 0x88d3070]B picture before any references, skipping [h264 @ 0x88d3070]decode_slice_header error [h264 @ 0x88d3070]no frame! Error while decoding frame! FAAD: error: Invalid number of channels, trying to resync! ??,?% 0 0 FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: Failed to decode frame: Maximum number of scalefactor bands exceeded [h264 @ 0x88d3070]B picture before any references, skipping [h264 @ 0x88d3070]decode_slice_header error [h264 @ 0x88d3070]no frame! Error while decoding frame! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Gain control not yet implemented, trying to resync! FAAD: error: Channel coupling not yet implemented, trying to resync! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: error: Invalid number of channels, trying to resync! FAAD: Failed to decode frame: Invalid number of channels [h264 @ 0x88d3070]B picture before any references, skipping [h264 @ 0x88d3070]decode_slice_header error [h264 @ 0x88d3070]no frame! Error while decoding frame! FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync! FAAD: error: Quantised value out of range, trying to resync! MPlayer interrupted by signal 11 in module: decode_audio - MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.

3 5

[PATCH]Disable liba52 and libmp3 for icc
by Carl Eugen Hoyos 05 Oct '08

05 Oct '08

Hi! Currently, icc can't compile the internal libraries liba52 and libmp3 (with optimizations). Attached patch changes the default for both libraries from "enabled" to "autodetect" and disables the comilation for intel compilers. Ok to apply? Carl Eugen

5 5

ARM and liba52
by Siarhei Siamashka 18 Aug '08

18 Aug '08

Hi, Currently liba52 is broken for ARM processors which require strict alignment for accessing memory (ARM9, XScale, ...). AC3 audio playback just produces noise. Interestingly enough, the problem was introduced in 2003 (SVN revision 10314), and it was supposedly a fix for ARM: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-June/019377.html I wonder if it was a fix that turned compilation error into runtime failure ;) Anyway, it should be mentioned that modern ARM cores (such as ARM11) support unaligned memory access natively. Older cores can emulate unaligned memory accesses by handling alignment faults in the kernel, but this is very slow. PS. liba52 uses floating point math which is very slow on old ARM cores without hardware FPU, so using liba52 on such old cores is not very practical anyway. -- Best regards, Siarhei Siamashka

4 6

[PATCH] Fix for ARM compilation failure when IWMMXT support is disabled
by Siarhei Siamashka 02 Aug '08

02 Aug '08

Hi, Patch attached. -- Best regards, Siarhei Siamashka

2 7

patch backlog maintenance
by Diego Biurrun 19 Jun '08

19 Jun '08

Folks, I'm awfully overloaded. Could somebody take over the maintenance of the patch backlog that I took over from Attila some time ago? All you need to do is keep track of all unapplied patches in an mbox or something and make it available from time to time. Sending out periodic reminders from time to time is a plus. Thanks Diego

3 13

Synchronization of players in LAN
by J.A. Gutierrez 18 Jun '08

18 Jun '08

Hello I'm trying to synchronise several players running on several computers connected to a dedicated 10/100 Ethernet switch. Each one reads a different movie (video only) from its internal hard disk, and resolution will be 768x576. I'm thinking of a simple solution: - Add some code at mplayer startup so it will wait for an UDP broadcast packet (sent by a central master in the LAN). This way all the players would start at the same time. - Use NTP to keep in sync all the computers' clocks, and trust mplayer's rtc synchronisation feature. With this simple setup, could we be sure all the players would keep the synchronisation? Or should the master computer track them all and take control on their speeds? How difficult would be to add code so all the player synchronise using the LAN? Or should I use some external clock connected to all serial ports? Or use a totally different approach? Thanks. -- finger spd(a)shiva.cps.unizar.es for PGP / .mailcap tip of the day: / La vida es una carcel application/ms-tnef; cat '%s' > /dev/null / con las puertas abiertas text/x-vcard; cat '%s' > /dev/null / (A. Calamaro)

14 40

vo_gl PBO patch ..
by Sven Gothel 10 Jun '08

10 Jun '08

Hi Team, this is regarding: - vo_gl - HD video material - AMD's low performance glTexSubImage2D() texture upload. I have experienced a very low texture upload performance with AMD GPU's while _trying_ to watch HD content. A little performance test using valgrind, showed my the it's glTexSubImage2D() (again). It looks like AMD still cannot do DMA transfers automatically, sad thing. Therefor I have added a 'pbodma' option, to use PBO's for texture uploads. It looks silly, since we do an extra dma xfer with memcpy first, and then let glTexSubImage2D() doing a DMA using PBO, but it's still faster for AMD GPU's. On a AMD 780G motherboard IPG HD3xxx we will gain a performance hit of 82% -> 24%, which makes it usable. Little performance hit on NVidia 3% -> 2%, but still :) Sad thing for AMD (again), they cannot really handle GL_UNPACK_ROW_LENGTH, therefor the only working combination for my AMD 780G is: 'rectangle=0:pbodma=1' However, it renders vo gl usable for this combination. Please submit and/or let me know your concerns. Cheers, Sven -- health & wealth mailto:sgothel@jausoft.com ; www : http://www.jausoft.ca ; pgp: http://www.jausoft.com/gpg/ land : +1 (780) 637 3842 ; cell: +1 (780) 952 4481 Timezone MST: EST-2, UTC-7, CET-8 ; MDT: EDT-2, UTC-6, CEDT-8

4 33

[PATCH] libdvdcss: fix uninitialized disk key
by Kirill Belokurov 07 Jun '08

07 Jun '08

Hi! This was originally the patch to libdvdcss-dev from 2007-09-25, but it looks like that maillist is almost dead, so I decided to propose it here (seeing that mplayer has a local libdvdcss copy). Below is the descripiton of the patch (applies with -2 lines fuzz): ============================================== Under certain conditions, the array "dvdcss->css.p_disc_key" may remain uninitialized till the line (libdvdcss.c:492) sprintf( &psz_key[1+i*2], "%.2x", dvdcss->css.p_disc_key[i] ); which will cause the "CSS keys cache folder" name for the DVD to be generated using raw memory contents. This will lead to a bug when libdvdcss often will not see the folder with previously cached keys and on the next DVD open attempt will retry the brute-force keys retrieval. The attached patch fixes this for two different cases: libdvdcss.c: for the case when DVD is encrypted but no ioctl is available (which is usual for encrypted DVDs copied via dd /dev/cdrom /path/to/file ) css.c: for the case when key decryption fails, the fallback is done, but disk key is not zeroed ============================================== Regards, Kirill

2 1

The new Makefiles
by Alban Bedel 06 Jun '08

06 Jun '08

Hi all, so the new flat build system is underway. Sadly IMHO it have a few shortcomings and there is some things that I think we should discuss here before going any further. The most important point IMHO, is do we really get rid of the .a or not? On the plus side I only see a few rule less in the Makefile. On the minus side the whole source list is required for any tool using the lib in question. Then there is the problem that now all sources are grouped together. It completely prevent any sane build system for the tools. Even if we drop the .a we need to keep a source list for each lib. Anything else is just too inflexible. If we keep separate lists we might as well put them in $LIB/Makefile and support building from the lib's dir. The latter is easy to achieve with some include. And still having separate Makefiles would make things easier for newcomers than having to dive in a 5000 lines Makefile. As an example, attached is a Makefile for osdep that can be included from the main Makefile or used "alone". Obviously it's just a draft as we still need to settle the above issues, and perhaps some more. Albeu

9 40

[PATCH] Fix vf_expand in with non-direct caps
by Pascal Massimino 31 May '08

31 May '08

Hi, attached patch makes sure vf_expand is dealing with direct-capable image before trying to use direct rendering for expanding. I've seen this problem with encoding, where the codec's replicated edges could be made visible upon expansion. skal

2 3