July 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

[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

[RFC] the future of libmpeg2
by Diego Biurrun 16 Sep '08

16 Sep '08

libmpeg2 0.5.0 was just released and it contains all the MPlayer patches I sent them. I was going to sync our internal libmpeg2 copy with the release, but I'm no longer sure this is really worth it. We now use FFmmpeg as default MPEG-1/2 decoder, so we might as well drop the internal libmpeg2 copy, possibly adding support for compiling against external libmpeg2. Thoughts? Diego

5 25

[PATCH] fbdev x and y positioning
by Sander 22 Aug '08

22 Aug '08

Hi, I was playing around with mplayer, and noticed that it does not support x- and y-positioning for playout via the framebuffer (fbdev). It is a very simple patch to make, however, and is compatible with the current "geometry"-parameter, used for other video output devices. It is particularly useful for some devices that only support basic framebuffer output, and need some way to position the output on screen. The patch adds x- and y-positioning to vo_fbdev.c via the geometry parameter. You will always have to input the real screenwidth and -height for this parameter to work. The width- and height parameters of geometry are ignored. E.g. "mplayer -vo fbdev -ao alsa -geometry 400:400 -screenw 1024 -screenh 768 myfile.mpg" would play 'myfile.mpg' at coordinates (400,400) on a screen of 1024x768 pixels. I hope this simple patch can be added to the SVN-tree/latest release. Kind regards, Sander --- MPlayer-1.0rc2/libvo/vo_fbdev.c 2007-10-07 21:49:28.000000000 +0200 +++ ../vo_fbdev.c 2008-07-22 14:30:11.000000000 +0200 @@ -25,6 +25,7 @@ #include "video_out_internal.h" #include "fastmemcpy.h" #include "sub.h" +#include "geometry.h" #ifdef CONFIG_VIDIX #include "vosub_vidix.h" #endif @@ -998,7 +999,14 @@ else #endif { - int x_offset=0,y_offset=0; + int x_offset=0,y_offset=0, geo_width=0, geo_height=0; + if (vo_screenwidth && vo_screenheight) + { + if (vo_geometry) + { + geometry(&x_offset, &y_offset, &geo_width, &geo_height, vo_screenwidth, vo_screenheight); + } + } if ((frame_buffer = (uint8_t *) mmap(0, fb_size, PROT_READ | PROT_WRITE, MAP_SHARED, fb_dev_fd, 0)) == (uint8_t *) -1) { mp_msg(MSGT_VO, MSGL_ERR, "Can't mmap %s: %s\n", fb_dev_name, strerror(errno));

3 8

[PATCH] Enhanced Cropdetect Code - 0th Order Entropy
by Roger Heflin 18 Aug '08

18 Aug '08

This code is to add the ability to detect junk added around original 4:3 content that are broadcast in 16:9 format with bars that contain slowly moving logos around them that defeats the current cropdetect code. I believe it follows all coding standards, but it would not surprise me if I missed something. As the code is done, the old functionality appears to work just like it did before, the entropy part is default disabled. I have not tested the 4 bpp part of the case statement as I don't believe have I have any video of that type to test with, the 1 bpp test all worked as expected (old behavior worked if entropy was set to -1 (default off)), and new behavior worked if entropy was set to a value and the limit was set to (-1) off. New manpage excerpt to go with the code: cropdetect[=limit:round:entropy] Calculates necessary cropping parameters and prints the recom- mended parameters to stdout. The crop is the Boolean AND of the 2 methods (unless entropy or limit is disabled by setting it to -1), if both are on then both must want it to be cropped for it to be cropped, so turning off one is probably wise. <limit> Threshold, which can be optionally specified from off (-1) to nothing (0) to everything (255) (default: 24). <round> Value which the width/height should be divisible by (de- fault: 16). The offset is automatically adjusted to center the video. Use 2 to get only even dimensions (needed for 4:2:2 video). 16 is best when encoding to most video codecs. <entropy> A measure of randomness, the lower the number the less random. It can be used to remove annoying borders added to 4:3 videos that are filled out to widescreen. Valid values are -1 (off) to 0 (nothing) to 255. Default is -1 (off), a reasonable value that works for my case seems to be in the 140 range (140 is equivalent to en- tropy of 4.75 bits). If someone believes this change warrants an entry in the AUTHORS file that please add an entry. Comments? Roger

2 3

[RFC] Makefile copyrights
by Diego Biurrun 18 Aug '08

18 Aug '08

I'd like to commit the attached patch and mark the Makefile as copyrighted by me. Not a single (non-empty) line written by Arpi or LGB remains in it, nor does any of the original structure. Nonetheless I can see a world of hurt coming down the pipe if I commit this directly, thus the RFC. Diego

5 35

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

Commit rules and coexistence rules
by Luca Barbato 07 Aug '08

07 Aug '08

In the cvslog ml you may dig a thread in which we got lots of drama, flames and assorted complaints. I perceive the main issue being the intolerance to less understood rules and scarce ability to get the rules accepted. Let's try to address this before nuking Uoti out and other actions that I consider not completely good. Let's start with the commit rules. Michael Niedermayer wrote: > On Wed, Jun 04, 2008 at 05:34:13PM +0200, Luca Barbato wrote: > These remove comments, remove outcommented code, ... > this definitly is not what indent does and its just what i quickly spotted Ok, I overlook that mostly because is a big patch, you are right. > And thats why such commits are so bad and why we all complain, they are a > nightmare to review, you missed the things above, others missed them too. > What if there where security related changes? Intentionally placed > buffer overflows or some, send /etc/shadow to badguy(a)badplace.com? > All code that goes into svn has to be reviewed or mplayer will become a > time bomb. Its trivial to get a svn account if one wanted to do something > nasty, reviews are the only way to avoid such issues. I think we could start a revision of rules and just say that - A commit should be easy to review so it should be: - small - do not mix unrelated changes in a single lump - possibly easy to follow - A commit message should be meaningful and to the point - Terse enough - Explain what the patch does. - Exceptions could could go in if: - They are discussed before - They cannot be split w/out breaking functionality in the intermediate commits. Rules should help us getting things done and we should find them reasonable and fair. Uoti finds some of them annoying and cannot see the point of some of them. I think most of them have a point but they should be clarified so they can be understood by everybody. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero

9 34