August 2010 - 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

[PATCH] -vf fixpts=use_timer
by Rudolf Polzer 22 Feb '11

22 Feb '11

Hello, I added an option to -vf fixpts that takes over the timer from mplayer/mencoder's "best known idea" of the current display time. It is mostly useless in mplayer as mplayer usually generates good pts anyway, but works there too for completeness. Its main intention is to support ASS subtitle baking in mencoder, even if the input video is variable frame rate. My mencoder profile for embedding subtitles is currently: [subtitles] vf-add=fixpts=use_timer,ass,expand=::::1,fixpts ass=yes embeddedfonts=yes It works by having mplayer/mencoder export their timer to a global variable, and having fixpts=use_timer read that back and use it as replacement pts. In case of mplayer, I simply could export sh_video->timer (did NOT use the usually more accurate sh_video->pts, as using that one is quite pointless as it is exactly what is sent as current timestamp anyway). The feature therefore is mainly a debugging help in mplayer. In case of mencoder, sh_video->timer was not available, and sh_video->pts was not monotonous (and thus bad for e.g. subtitle rendering), so I got no better idea than using the audio timer instead. As I noticed the audio timer is broken (positive infinity) for some input video files (e.g. those which use vorbis as audio codec), I had to port over mplayer's audio PTS generation (which is, if possible, no longer based on constant bitrate input data sizes, but on output data sizes of the audio codec, which also works for VBR audio like vorbis). This also solves almost all failcases of mencoder that I have that previously needed -mc 0 to encode properly, as apparently this very issue also caused AV sync to fail in mencoder. To do this port, I also had to delete the written-only (grep did not find any other access to it anywhere) delay_corrected variable. I hope that is okay. If desired, I can split up the changes into separate diffs, however the fixpts=use_timer feature depends on the mencoder.c audio timer fix, or rather, causes huge breakage (infinite pts values) on many input video files when added to the filter chain. Or you can instead download them separately on github: http://github.com/divVerent/mplayer/commits/divVerent/fix_audio_pts http://github.com/divVerent/mplayer/commits/divVerent/fixpts_get_audio_pts http://github.com/divVerent/mplayer/commits/divVerent/integration/fixpts (integration branch of both + current svn) I attached my patch to svn r31721 (= git master on git.mplayerhq.hu), and hope for a review. Best regards, Rudolf Polzer

4 17

[PATCH] proper version info for git.mplayerhq.hu
by Rudolf Polzer 17 Dec '10

17 Dec '10

I attached a small patch that, if mplayer is compiled from mplayer.git, uses the git commit hash instead of UNKNOWN as version info. The format will be: git-<commithash>-<gccversion> if mplayer is built from "master", and git-<closest commithash on master>-<commithash>-<gccversion> if mplayer is built from another branch. In my case, at the moment it prints: MPlayer git-15dfe0a-ceba2bd-4.4.1 (C) 2000-2010 MPlayer Team It changes nothing if run from a svn repository. Best regards, Rudolf Polzer

5 17

[PATCH] SMPlayer's audio equalizer slave command patch
by Adrian Stutz 17 Oct '10

17 Oct '10

Hello, SMPlayer has been using a patch to set the audio equalizer bands from the command line for a long time now, the patch was originally posted in June 2008 on this list: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-June/057840.html An updated version can be found in the SMPlayer SVN: http://smplayer.svn.sourceforge.net/viewvc/smplayer/mplayer-builds/patches/… Are there any issues with this patch? I started using it in MPlayer OSX Extended as well and would prefer if it got applied to SVN. Greetings Adrian

2 13

New SSL certificate on mphq
by Måns Rullgård 09 Oct '10

09 Oct '10

The old, expired SSL certificate on https://mphq has been replaced. SHA1 Fingerprint=3E:95:E8:B4:E0:3F:EB:AD:5B:43:AD:7F:FA:26:CA:B5:2C:1B:AF:62 -- Måns Rullgård mans(a)mansr.com

2 1

[PATCH] Fix hang on demux of matroska files with 0byte-ints using 'mkv' demuxer
by Sebastian Hagen 08 Oct '10

08 Oct '10

Hello *, Mplayer's 'mkv' matroska file demuxer has a bug preventing it from parsing integers with a length of 0 bytes correctly, even though those are valid according to the Matroska specs[1]. Thus, attempting to play mkv files containing such integers without explicitly specifying '-demuxer lavf' will result in an mplayer hang on demux. I'm attaching a small MKV file (without any actual media streams) demonstrating the bug as well as a patch that fixes it for me. [1] <http://www.matroska.org/technical/specs/rfc/index.html>, section 2.4. Sebastian Hagen

6 11

[PATCH] Fix AC3 passthrough on Intel Macs
by Sean McGovern 08 Oct '10

08 Oct '10

As I mentioned previously I have been looking into the AC3 passthrough problem on Intel Macs and have made a patch to fix the issue. Also included the changes from the previous patch that squelches some compiler warnings. Comments, suggestions, constructive criticisms welcome. Thanks in advance, Sean McGovern

8 19

[RFC] all of FFmpeg as svn:external
by Diego Biurrun 08 Oct '10

08 Oct '10

I have been working on changing the build system to use all of FFmpeg as a single svn:external instead of multiple svn:externals for each library that we use. This avoids duplicating much of the FFmpeg build system and indeed the diffstat is quite attractive: Makefile | 47 -- common.mak | 109 ------ configure | 995 ++----------------------------------------------------------- subdir.mak | 101 ------ 4 files changed, 48 insertions(+), 1204 deletions(-) Shrinking configure by a full 10% and getting rid of subdir.mak and common.mak to keep tracking is no small feat and will reduce our maintenance burden considerably. The downside is pulling in more source than we really need, like libavdevice and the FFmpeg test infrastructure. This is still strictly a work in progress, but I figured that the sooner I get feedback on the general idea and the implementation, the better. There are still quite a few rough edges. I will add a configure parameter that passes along options to FFmpeg's configure. I have not reviewed it closely myself yet and it is surely not yet free of bugs. Currently it triggers a great deal of warnings of the sort In file included from ffmpeg/libavutil/common.h:90, from ffmpeg/libavutil/avutil.h:81, from ffmpeg/libavcodec/avcodec.h:30, from libmpcodecs/vf_zrmjpeg.c:51: ffmpeg/libavutil/intmath.h:36:5: warning: "HAVE_FAST_CLZ" is not defined ffmpeg/libavutil/intmath.h:65:6: warning: "CONFIG_SMALL" is not defined In file included from ffmpeg/libavutil/internal.h:192, from ffmpeg/libavutil/common.h:307, from ffmpeg/libavutil/avutil.h:81, from ffmpeg/libavcodec/avcodec.h:30, from libmpcodecs/vf_zrmjpeg.c:51: ffmpeg/libavutil/libm.h:31:6: warning: "HAVE_EXP2" is not defined ffmpeg/libavutil/libm.h:36:6: warning: "HAVE_EXP2F" is not defined ffmpeg/libavutil/libm.h:41:6: warning: "HAVE_LLRINT" is not defined ffmpeg/libavutil/libm.h:46:6: warning: "HAVE_LLRINTF" is not defined ffmpeg/libavutil/libm.h:51:6: warning: "HAVE_LOG2" is not defined ffmpeg/libavutil/libm.h:56:6: warning: "HAVE_LOG2F" is not defined In file included from ffmpeg/libavutil/common.h:307, from ffmpeg/libavutil/avutil.h:81, from ffmpeg/libavcodec/avcodec.h:30, from libmpcodecs/vf_zrmjpeg.c:51: ffmpeg/libavutil/internal.h:199:5: warning: "CONFIG_SMALL" is not defined ffmpeg/libavutil/internal.h:223:5: warning: "HAVE_SYMVER_ASM_LABEL" is not defined ffmpeg/libavutil/internal.h:227:7: warning: "HAVE_SYMVER_GNU_ASM" is not defined In file included from ffmpeg/libavutil/bswap.h:46, from ffmpeg/libavutil/intreadwrite.h:25, from ffmpeg/libavcodec/dsputil.h:33, from ffmpeg/libavcodec/mjpegenc.h:36, from libmpcodecs/vf_zrmjpeg.c:52: ffmpeg/libavutil/x86/bswap.h:41:5: warning: "HAVE_BSWAP" is not defined In file included from ffmpeg/libavutil/intreadwrite.h:70, from ffmpeg/libavcodec/dsputil.h:33, from ffmpeg/libavcodec/mjpegenc.h:36, from libmpcodecs/vf_zrmjpeg.c:52: ffmpeg/libavutil/x86/intreadwrite.h:30:6: warning: "HAVE_FAST_64BIT" is not defined In file included from ffmpeg/libavcodec/mjpegenc.h:36, from libmpcodecs/vf_zrmjpeg.c:52: ffmpeg/libavcodec/dsputil.h:696:5: warning: "HAVE_LOCAL_ALIGNED_8" is not defined ffmpeg/libavcodec/dsputil.h:702:5: warning: "HAVE_LOCAL_ALIGNED_16" is not defined In file included from ffmpeg/libavcodec/mpegvideo.h:33, from ffmpeg/libavcodec/mjpegenc.h:37, from libmpcodecs/vf_zrmjpeg.c:52: ffmpeg/libavcodec/put_bits.h:184:6: warning: "HAVE_FAST_UNALIGNED" is not defined because it reads ./config.h instead of ffmpeg/config.h. One possible workaround is to rename our config.h to mpconfig.h. However, that will muck with our other external libraries. I'm all ears for better solutions if you have any to offer. Comments? Diego

6 29

Re: [MPlayer-dev-eng] [PATCH] unified timing patch for H264
by Pásztor Szilárd 07 Oct '10

07 Oct '10

Hi, (sorry for replying out of thread, my server is experiencing difficulties.) Since michaelni doesn't seem fond of changing ffmpeg because of this mplayer-specific h264 problem, here comes a patch that does it in mplayer according to this: Reimar Döffinger: > If not however, you can fix this while avoiding any issues by > returning the "only one field" indication only for CODEC_ID_H264 and > only if the packet size was not 0. Now codec is checked and return value is set accordingly. (Packet size is already checked at start of function.) Please review the patch if you can take the time. It is working stable on all samples I could test. Main changes to original sources: * PTS reordering bug fixed. If correct-pts is set, now only the PTS of "full frames" (or second fields) get buffered. It was buggy before because all fields' timestamps were buffered but the buffer length was checked and cut according to reported number of B-frames. At most streams, it threw away half of the values, causing jerkiness. * added stable time-based PTS recalculation for nocorrect-pts. PTS are untouched until A-V sync gets close, then replacement starts at the proper point where the calculated should-be PTS is practically equal to what comes in the stream, finding frame accurate A-V sync both after starting playback and seeking. This recalculation is needed to prevent the A-V sync algorithm from trying to correct for the jumpy B-frame PTS all the time. The patch is not small but all parts depend on each other, so it can't really be split into separate patches. I hope it's a clean patch and covers all cases.

6 42

[RFC] libavutil/x86_cpu.h
by Diego Biurrun 07 Oct '10

07 Oct '10

We use libavutil/x86_cpu.h all over the place even though it not a public header. This makes building without libavutil in the source tree impossible. Since this header depends on config.h it will never become a public header in FFmpeg. I suggest that we just copy it to the top level of MPlayer. The header is small and useful and its content are not really subject to change; it has been untouched for more than a year. Diego

5 28