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

[PATCH] add support of compression algorithm 3 in mkv demuxer
by Alexander Beregalov 02 Jan '12

02 Jan '12

Specs from http://www.matroska.org/technical/specs/ : ContentCompAlgo The compression algorithm used. Algorithms that have been specified so far are: 0 - zlib, 1 - bzlib, 2 - lzo1x, 3 - Header Stripping. ContentCompSettings Settings that might be needed by the decompressor. For Header Stripping (ContentCompAlgo=3), the bytes that were removed from the beggining of each frames of the track. I have such file, it works for me. | + A track | + Track number: 2 | + Track UID: 2 | + Track type: audio | + Lacing flag: 1 | + Default flag: 1 | + Codec ID: A_AC3 | + Content encodings | + Content encoding | + Content compression | + Algorithm: 3 (header removal) | + Settings: length 2, data: 0x0b 0x77 See an attachment. Please comment.

7 21

rtp support in mplayer
by chas williams - CONTRACTOR 30 Apr '10

30 Apr '10

while trying to play from rtp/mpeg-es streams i found i needed the following patch: --- stream/rtp.c.000 2008-05-13 17:37:23.000000000 -0400 +++ stream/rtp.c 2008-05-13 18:02:02.000000000 -0400 @@ -246,6 +246,9 @@ headerSize = 12 + 4*rh->b.cc; /* in bytes */ + if (rh->b.pt == 32) /* 32 = MPV from RFC 1890 */ + headerSize += 4; /* skip MPEG video-specific header RFC 2250 */ + *lengthData = lengthPacket - headerSize; *data = (char*) buf + headerSize; to skip over the 4-byte mpeg header present in the file. however, after looking at mplayer a bit harder, i see that there are two rtp decoders/demuxers. the one supplied in libavformat (apparently derived from ffmpeg) seems like it has more smarts. which one should i be using?

4 13

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

Direct 3D Windows VO
by Olivier Chalouhi 17 Feb '09

17 Feb '09

Are there any plans for developing a direct 3d (vs directx) vo for windows. The current directx vo on Vista forces the compatibility mode and disables aero, which results in a degraded user experience. Moreover the current directx implementation will only work with the primary display. If anyone would have the capabilities of doing it (VLC has one, so it may be possible to base the mplayer's one on the implementation from VLC), please contact me back, as my company would be willing to pay for this development. Best, Olivier Chalouhi.

6 23

libass behavior when PlayResX & PlayResY are missing in ass subs
by Robert Ramiega 14 Jan '09

14 Jan '09

Hi! Lately i've been playing with ass subtitles and i've noticed that when subtitle file doesn't specify PlayResX *and* PlayResY libass hardcodes them to 384x288. What's the reasoning with this? I think this is a bit against SSA/ASS specs I've found on the net: PlayResY: This is the height of the screen used by the script's author(s) when playing the script. SSA v4 will automatically select the nearest enabled setting, if you are using Directdraw playback. PlayResX: This is the width of the screen used by the script's author(s) when playing the script. SSA will automatically select the nearest enabled, setting if you are using Directdraw playback. Locally I've modified ass_render.c so that if both values are missing in the sub file they are set to orig_width, orig_height (this seems to be at least a bit consistent with situation when either PlayResX or PlayResY is given -- see ass_lazy_track_init() around line 210 of ass_render.c ). -- Just a friendly Jedi Knight | I find your lack of faith Robert Ramiega jedi(a)plukwa.net | disturbing http://nlj.plukwa.net/

5 10

[PATCH] correct illegal instruction on < armv5tE
by GNUtoo＠no-log.org 05 Jan '09

05 Jan '09

hello, I wanted to cross-compile mplayer from svn but it failed...that's because the pld instruction is not supported by my platform(armv4): More precisely the pld instruction was introduced in armv5tE variants( but is not present on armv5texp) here's the compilation faillure: | ccache arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -isystem/home/gnutoo/oetmp/staging/arm-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -Os -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -isystem/home/gnutoo/oetmp/staging/arm-angstrom-linux-gnueabi/usr/include -I/home/gnutoo/oetmp/staging/arm-angstrom-linux-gnueabi/usr/include/SDL -D_REENTRANT -I/home/gnutoo/oetmp/staging/arm-angstrom-linux-gnueabi/usr/include/freetype2 -I/home/gnutoo/oetmp/staging/arm-angstrom-linux-gnueabi/usr/include -isystem/home/gnutoo/oetmp/staging/arm-angstrom-linux-gnueabi/usr/include -c -o libmpeg2/motion_comp_arm.o libmpeg2/motion_comp_arm.c | ccache arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -isystem/home/gnutoo/oetmp/staging/arm-angstrom-linux-gnueabi/usr/include -c -o libmpeg2/motion_comp_arm_s.o libmpeg2/motion_comp_arm_s.S | libmpeg2/motion_comp_arm_s.S: Assembler messages: | libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:39: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:65: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:70: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:75: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:89: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:98: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:120: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:126: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:132: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:158: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:183: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:197: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:212: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:227: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:250: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:271: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:283: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:296: Error: selected processor does not support `pld [r1]' | libmpeg2/motion_comp_arm_s.S:309: Error: selected processor does not support `pld [r1]' | make: *** [libmpeg2/motion_comp_arm_s.o] Error 1 | FATAL: oe_runmake failed NOTE: Task failed: /home/gnutoo/oetmp/work/armv4t-angstrom-linux-gnueabi/mplayer-0.0+1.0rc2+svnr27726-r7/temp/log.do_compile.18445 NOTE: package mplayer-0.0+1.0rc2+svnr27726-r7: task do_compile: failed ERROR: TaskFailed event exception, aborting NOTE: package mplayer-0.0+1.0rc2+svnr27726: failed ERROR: Build of /home/gnutoo/dev/embedded/oe/local_repository/packages/mplayer/mplayer_svn.bb do_compile failed ERROR: Task 7 (/home/gnutoo/dev/embedded/oe/local_repository/packages/mplayer/mplayer_svn.bb, do_compile) failed NOTE: Tasks Summary: Attempted 736 tasks of which 730 didn't need to be rerun and 1 failed. ERROR: '/home/gnutoo/dev/embedded/oe/local_repository/packages/mplayer/mplayer_svn.bb' failed NOTE: build 200810072146: completed With the patch it builds and runs fine(I tested youtube videos with a script) I bet the patch won't be accepted as-is because it has a performance cost on the platform where the pld instruction is supported because the pld instruction preloads things...

6 21

[PATCH] Replaced deprecated QuickDraw calls in vo_quartz
by onitake 18 Dec '08

18 Dec '08

hello. when compiling mplayer against a recent (10.4+) sdk, gcc spits out quite a few deprecation warnings in the vo_quartz output module. the respective functions are part of quickdraw, which is recommended not to be used any more, and not supported at all when compiling for 64bit. i tried to fix these by replacing them with quartz calls. as far as i can see, the modifications work, the compiler warnings are gone and there are no performance issues. please review the patch and provide feedback. i know there's also the cocoa based vo_macosx module, but since both are around, they should both be free from legacy code, shouldn't they? :) i think i used one function marked as 10.1+, but the rest is marked to be available even in 10.0, if people still want to build against that. best regards, oni

12 48

[PATCH] Fix compilation on OpenBSD
by Andrew Savchenko 11 Dec '08

11 Dec '08

Hello, the following patches fix complation of mplayer svn head on openbsd-4.2. 1) socklen_t data type is defined in sys/types.h in OpenBSD, thus compilation fails with the following: ======= stream/network.h:29: error: conflicting types for `socklen_t' /usr/include/sys/types.h:161: error: previous declaration of `socklen_t' ======= socklen_t.patch fixes this. 2) Include directories reported by pkg-config for theora are not included in $_inc_extra, thus if theora is not installed in standard location, compilation fails due to unknown header file "theora/theora.h". In case on OpenBSD theora's headers are usually installed in the /usr/local/include. theora_local.patch is the fix for this. 3) The third problem is the ffmpeg's problem, I will post to ffmpeg-devel, but I want to put this patch here for convenience for those, who want to check/use these patches on OpenBSD. There is no #define INFINITY in OpenBSD, but HUGE_VAL is. So nellymouserenc.patch fixes this. -- Best regards, Andrew

2 7

Direct3D OSD discussion
by Georgi Petrov 10 Dec '08

10 Dec '08

Hello, I prefer to move all OSD questions/answers in this thread, because we're over with D3D's performance for time being. First of all - Jim, thanks for updating to the latest SVN version and posting patches relative to it - it saves us all :) Let me ask some questions: 1. Drawing on the next frame is fixed easily I think. I'm sure Jim will do it right. 2. What bothers me more is this: >>>>> 2) OSD is rendered in software first and then once more in hardware >>> Again does the same as the gl renderer. >> >> You use vo_draw_alpha_rgb32 which does alpha blending and more in >> software. vo_gl does not. >> >I will look into this. Hmmm, I have 2 questions: Why are all other drivers I looked into (like vo_directx.c) using vo_draw_alpha_xxxxx? This is supposed to be "software rendering", right Reimar? I mean - you give a texture of some size to the functions and tell in its colorspace and it draws the OSD for you? Additionally as I see the vo_draw_alpha_xxxxx has MMX/SSE/whatever optimizations and they are used when supported. What would be the "hardware" rendering? I can't really understand what is vo_gl.c doing different... vo_gl calls vo_draw_text() with a parameter "create_osd_texture". Inside "create_osd_texture" you seem to "walk" through every OSD "part" and what... generate texture for each one? Or better - vo_draw_text() calls "create_osd_texture" for every OSD element and "create_osd_texture" creates texture for it and places it somewhere, so finally everything gets "blended" on the backbuffer? Please excuse my prehistoric understanding about everything - my day job is writing software for network adapters :) :) :) Are those things explained somewhere, so you can spare your words explaining what's happening? I'm ready to read literature about it... The second question: why do you use vo_draw_alpha_rgb32? Because you create a texture with the same format as the backbuffer? This means that you DON'T "blend" the OSD with the movie's original offscreen surface and then StretchRect it on the backbuffer, but you render the OSD on a texture with the same format as the backbuffer and blend it independent from the offscreen surface of the movie? BTW, I committed a patch for enabling BGR32/16/15 a few hours ago, but this is related to the format of the offscreen surface. Another question: Why does vo_directx.c have support for: vo_draw_alpha_yv12 vo_draw_alpha_yuy2 vo_draw_alpha_rgb15 .... and so on? I think that it does blend the OSD in the equivalent of the offscreen movie source surface or just when using Overlays, the backbuffer itself is equal to the movie's source format and you have to render the OSD in YV12, YUY2 or whatever your movie uses... >Sorry, I misunderstood. It redraws for each frame whilst it is on. >I'll fix this. Does it mean that you must render the OSD in a texture on the first requested frame and just blend it until OSD is on (and haven't changed), so you don't render the OSD without need to do so on every frame (and use the already rendered instead)? I'm sorry for my dumb questions. I'm trying to understand what's happening in the driver I originally wrote and only a week later don't understand anything :D

5 83

[PATCH] Direct3D Much better D3D management
by Georgi Petrov 08 Dec '08

08 Dec '08

Ok, I know this patch may seem bigger than the Reimar's requirements. I can make more smaller patches that accomplish the same in the end if you wish so. The main purpose of this patch is to do a much better at D3D's init/reset/destroy than before and fix 2-3 bugs. Let me start: When D3D is initialized, those things are created: 1. The "D3D" itself. uses priv->d3d_handle This is handled in preinit to support query of supported formats later. 2. The D3D Device uses priv->d3d_device This is initialized in configure_d3d(); 3. The offscreen and backbuffer surfaces. uses priv->d3d_surface uses priv->d3d_backbuf This is initialized in create_d3d_surfaces(); So - we have 3 "levels" of D3D initialization before we can render frames. This is the natural way of initializing D3D. Remember good this order. We have to handle 2 situations once D3D is initialized: 1. Window resize / going to/from fullscreen 2. Adapter becoming uncooperative We handle window resize / going to/from fullscreen in function resize_d3d: * Destroy the offscreen/backbuffer surfaces * Do a D3D Reset (which requires that no surfaces are allocated) * Create both surfaces again. The whole thing is needed because the Backbuffer surface doesn't rescale itself and by reseting the D3D device and creating a new backbuffer surface, it fills the new window's coordinates. About the offscreen surface - we wouldn't need to destroy and recreate it again (as it has the non-changing coordinates of the original movie), if D3D_Reset didn't require that all D3D resources are freed before calling it. So that's it. We handle the adapter becoming uncooperative in function reconfigure_d3d: * This function has new meaning from the previous one. It totally destroys D3D and recreates it again by doing: * Destroy the offscreen/backbuffer surfaces * Destroy the D3D Device created in configure_d3d() * Stop the whole D3D started in preinit * Start the whole D3D * Call configure_d3d() After calling configure_d3d() we've simulated the initialization after preinit. Problems fixed: * Very good D3D initialize / destroy separation * More meaningful functions: create_d3d_surfaces() destroy_d3d_surfaces() configure_d3d() resize_d3d() reconfigure_d3d() uninit_d3d() Now each function does exactly what it says. Before the patch "reconfigure_d3d" used to both destroy and recreate D3D, BUT NOT FROM THE BEGINNING (ignoring to stop the whole D3D and create it again as in preinit). It's more guaranteed to work now and called ONLY when the adapter is uncooperative. Now resize_d3d does "lightweight" resizing by calling Reset instead of destroy/create the adapter. * No need for destroying and recreating the D3D adapter on each resize or going to/from fullscreen. Before this patch we killed the D3D Device and created it again. For fast window resizing this used to happen many times in a second. Now we call Reset, which based on my test is faster and safer. Before the patch if you tried to resiz the window too fast, D3D used to fall into a state, where the D3D Device can't be created again. By calling Reset this doesn't happen any more AND it's faster/safer. * Going fullscreen / coming back should be a little faster (again - we skip D3D Device destroy/create and change it with Reset) * Fixed a bug when after calling the "previous" reconfigure_d3d() we didn't allocate new backbuffer after coming from fullscreen (or something like that, I'm not sure). The problem was that after coming back from fullscreen AND resizing the window, the backbuffer stayed with the old dimensions and the image became aliased.

7 29