October 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

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

MNG support for MPlayer
by Stefan Schuermans 30 Nov '08

30 Nov '08

Hello MPlayer developers, MNG animations do not seem to be supported by MPlayer 1.0rc2. Because I wanted to play back MNG animations using MPlayer, I tried to implement a demuxer in libmpdemux using libmng 1.0.9 (on Debian etch). It worked out and I've been able to play the MNG animations using the new demuxer. Perhaps the code is useful for other people, so I'm sending the patchfile. Best regards, Stefan

5 40

Re: [MPlayer-dev-eng] [PATCH] vo_macosx: use mmap instead of shmat for MPlayerOSX
by Adrian Stutz 30 Nov '08

30 Nov '08

On 23-Oct-08, at 12:11, Nicolas Plourde wrote: > Ulion is now maintainer of vo_macosx... Anyway I can commit right away > but I would like Adrian to test on tiger first. Sorry, I didn't CC the last message to mplayerosx-devel: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-October/058768.html The above message has an updated patch attached that's confirmed to work on OSX 10.4. Greetings Adrian

2 1

stream seek eof handling
by Laurent 24 Nov '08

24 Nov '08

Hi, I've been tracking an issue with mp4 file header parsing that created an infinite loop in libavformat (in mov.c). The infinite loop has been prevented in libavformat, though, the root cause of this issue seems to come from MPlayer, as ffmpeg is not impacted by it. I have been pointed to the bug #1267, that may be the issue I encountered. Basically, stream/stream.c:stream_seek_long() behavior is inconsistent regarding eof handling. In my case, stream_seek_long() fails to move the stream position because eof has been reached in a previous stream_fill_buffer() call. As the stream position never moves forward, libavformat reads in an infinite loop. This issue comes from the handling of position at or after EOF in streams. Sometimes, it is considered as a valid position, sometimes not. Sometimes, eof flag is cleared during a seek, sometimes not. Does someone knows what should be the right behavior in stream/stream.c: * Shall the stream eof flag be cleared when seek succeeds? * Shall EOF be a valid position for seek? * Shall positions past EOF be valid for seek? As a comparison, the system lseek has such behavior. Thanks, Laurent

2 4

[PATCH] A/V sync improvement for TV streams
by Laurent 12 Nov '08

12 Nov '08

Greetings, I've been trying to get a correct A/V sync on TV streams using immediatemode=0 (audio going through MPlayer). Basically, my command is (under Windows, using tvi_dshow acquisition tuner): mplayer.exe -tv immediatemode=0 tv://1 Autosync is disabled. As far as I undestand it, autosync only correct pts drift, which does not exist in my case. And from experience, autosync is failing to sync the TV A/V, even with the patch I propose. I encountered a number of issues which the proposed patches intend to fix. Issue 1: * pts_bytes, which gives the number of bytes read since the last pts, is not computed correctly within the libmpdemux/demuxer.c file. It is updated when buffers are filled, while it should be updated when they are read. With the proposed patch, the a_pts calculation, that relies on sh_audio->pts_bytes in mplayer.c gets accurate. Issue 2: * the pts from the TV audio stream is not passed through the PCM decoder (libmpcodecs/ad_pcm.c), and hence is lost and cannot be used in mplayer.c for A/V sync. This is fixed by the second patch. Issue 3: * TV streams are particular because mplayer cannot read frames faster than they are acquired. Eventually, you can get short of audio frames to grab from the demuxer. This is usually not a problem as there are still audio frames buffered in the audio pipe to the speakers (in audio filters and audio output drivers), and new audio frames will be available soon enough from the demuxer. The proposed (3rd) patch just ensure that mplayer continues to make its sync work as long as there is some audio frames to sync with in the audio pipe. I've seen that other people having issues with dvb a/v sync. These patches might help them, as the use case seems similar. Thanks,

6 17