March 2011 - 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

DxVA in MPlayer
by Georgi Petrov 26 Jun '11

26 Jun '11

Hello, I'm Georgi Petrov and a year ago I developed the Direct 3D renderer. Now I'm interested in implementing DxVA support in MPlayer. Yesterday I started to investigate the amount of work and any difficulties I may have and I came up with the following questions: 1. Since DxVA 2 requires EVR renderer (the current Direct 3D one won't work), I suppose that the best way to start is implementing a working EVR renderer first. If so, are there anybody who is familiar at least a little with it? The only thing that bothers me is that EVR is supposed to be used in a DirectShow chain and MPlayer has nothing to do with DirectShow... In short - does anybody know is it feasible to develop the EVR renderer first and test it with the current (non-accelerated) internal MPlayer codecs? 2. Once the EVR custom presenter is ready, FFmpeg already has the needed infrastructure for offloading computations for H.264, VC-1, MPEG-2 and MPEG-4 ASP. Excuse me if I don't get it, but each one of these standards should have an "accelerated" implementation, which from MPlayer's point of view is a new codec. Then inside the codec there are places, where one can hook and transfer the decoding part to the DxVA/VA API/VDAPU at any given stage (IDCT, MO and so on). Is this right? I'm starting to look at the code right now, but a higher abstract point of view is welcome. 3. As far as I understand this approach is used by VA API and VDPAU. Can I reuse their infrastructure as well? On this page I see a VA API patches: http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/ Are they part of MPlayer already or not? 4. Can somebody, who has already worked on VA API/VDPAU implementations give me some clue? How much work is involved in getting the whole chain work? Are most of the puzzle pieces in place or I will have to dig deeper into understanding how H.264 / VC-1 and so on work on a pure codec level? 5. I am trying to figure out a realistic estimate about how much time and hard work this is about, so any help in this direction is welcome. Greeting, Georgi

9 46

[PATCH] Add size based support for -endpos in MPlayer
by Clément Bœsch 11 Jun '11

11 Jun '11

A small patch to add size based support for -endpos in MPlayer. I tested it with random videos, audio only files and -loop option and it seems to work. Anything else I should test? However, I don't understand why mpctx->sh_audio is tested when mpctx->sh_video is NULL; is there a way to call the code around mplayer.c:L3698 without having neither mpctx->sh_video and mpctx->sh_audio? And then, does this mean mpctx->stream could be NULL? -- Clément B. Not sent from a jesusPhone.

2 12

[PATCH] vf_delogo: variable rectangle
by Nicolas George 23 May '11

23 May '11

Hi. The attached patch makes it possible to change the coordinates of the rectangle for the delogo filter, by supplying a subtitle-like file with the times and coordinates. Regards, -- Nicolas George

3 24

compiling mplayer with gcc 4.6, broken audio decoding
by Ionuț Bîru 18 May '11

18 May '11

Hi, right now i only found that mp3lib codec is affected, very high pitch sound, doesn't matter which audio output i'm using. mplayer log while playing: http://paste.xinu.at/XqVg/ config.log http://paste.xinu.at/XxBKH/ config.mak http://paste.xinu.at/gAHO/ -- Ionuț

8 12

[PATCH] Bind to seek to a given percent
by Clément Bœsch 05 May '11

05 May '11

Hi, It's the second time a person tells me he prefers GUI over classic MPlayer because the progress bar allows them to seek to a given position immediately. So I was wondering about making a default bind for this. It seems there is not current solution to bind a combination of keys, just like KEY_CTRL + '1', so I just binded F1 to F9 ('1' to '9' are for most of them already in use). I know this bind is not really good (especially for those using desktop managers) but I didn't find any better. What do you think of this? -- Clément B. Not sent from a jesusPhone.

3 8

Subtitles out-of-sync with 23.976 mkv files with lavf demuxer
by Anssi Hannula 05 Apr '11

05 Apr '11

Hi! Frame-based (microdvd) subtitles currently get out of sync towards the end of 23.976 fps H264 matroska files (some 1-2s in 40min). This doesn't happen with the legacy demuxer (-demuxer mkv). AFAICS this happens because demux_lavf.c uses st->r_frame_rate to determine sh_video->fps and sh_video->frametime, and r_frame_rate is rounded up to 24 fps by av_find_stream_info(). I'm not immediately sure what is the correct solution here, so does someone else know? -- Anssi Hannula

2 3

Video CPU usage reported incorrectly since 33114 threading patch
by Hermi Mercury 30 Mar '11

30 Mar '11

I noticed that when multiple threads are used with mplayer revision 33114 (through r33148), the video CPU usage reported is near 0%, as compared to ~20% for revision 33113 of mplayer. The changes introduced in r33114 enable threading (for the ffh264 video decoder at least). Some output from testing indicates that because thread_count was not being set in r33113 (when using pthreads at least), threading was not enabled with this earlier build. I tracked CPU usage reporting down to the video_time_usage variable, where it is incremented in dec_video.c, but was unable to determine exactly how threading was interfering with this counter. If someone with some more experience in this area could take a look I'd appreciate it. Regards, - Hermi

3 2

MPlayer MPEG4 Seeking Bug (and patch)
by Andyz Smith 29 Mar '11

29 Mar '11

Ubuntu 10.04 Mplayer 1.0rc4 Encore TV Card I use mencoder to capture video from the TV card and encode it to MPEG4. I open the resulting file with GMplayer, while it's still growing to achieve a DVR like effect. I noticed that the seek behaviour with MPEG4 was quite poor. Major distortion of the image was present for several seconds after seeking forward 10 seconds or selecting a random position with the slider. Encode to MPEG2 worked much better. MPEG4 with a keyint of 10 also made large improvements. Neither of those is really a solution. Upon review of the mplayer source code I believe the following is a rather large bug in the MPlayer MPEG4 decoder/demuxer seeking. My suggested patch and comments (AJS) follow. demux_mpg.c ln 980 if(sh_video->format == 0x10000004) { //mpeg4 if(i==0x1B6) { //vop (frame) startcode if ( (peek_nal_descriptor & 0xc0) == 0) // AJS 0x1b6 and then 00xxxxxx binary is an IDR (keyframe) break; //int pos = videobuf_len; //if(!read_video_packet(d_video)) break; // EOF AJS this might lookahed, but I think it reads too far //if((videobuffer[pos+4] & 0x3F) == 0) break; //I-frame AJS this bitwise AND is backwards I think } parse_es.c ln 38 int videobuf_code_len=0; int peek_nal_descriptor = -1; //ajs LookAhead for MPEG4 P,B,IDR frame detection #define MAX_SYNCLEN (10 * 1024 * 1024) ln 51 next_nal = demux_getc(ds); peek_nal_descriptor = demux_peekc(ds); //ajs LookAhead for MPEG4 P,B,IDR frame detection if (next_nal < 0) ln 96 next_nal = demux_getc(ds); peek_nal_descriptor = demux_peekc(ds); //ajs LookAhead for MPEG4 P,B,IDR frame detection if (next_nal < 0) parse_es.h ln 30 extern int videobuf_code_len; extern int peek_nal_descriptor; //ajs LookAhead for MPEG4 P,B,IDR frame detection // sync video stream, and returns next packet code Ok, So The MPEG4 Part 2 spec defines frame type using AN EXTRA BYTE. It seems that neither MPEG2 nor H264 ( MPEG Part 10? ) do this. The first part 0x1B6 specifies only that the frame is a VOP (Video Object Plane). It could be differential compression frame (B) or predicted frame (P) or a actual full picture (IDR, Immediate Decoder Refresh, keyframe). The next byte specifies which kind of frame. During seeking we only want IDR(keyframes), otherwise distortion will be large until the next keyframe. Ok... The code to check for this is in there, but it doesn't seem to work. Specifically, this appears quite wrong and broken. if((videobuffer[pos+4] & 0x3F) == 0) The spec says that the higher 2 bits from this byte determine the frame type. VOP_CODING_TYPE (binary) Coding method 00 intra-coded (I) 01 predictive-coded (P) 10 bidirectionally-predictive-coded (B) 11 sprite (S) So to find out if this definitely is an IDR(keyframe) we must: videobuffer[pos+4] & 0xC0 00xxxxxx & 00111111 (x3F) Doesnt tell us anything 00xxxxxx & 11000000 (xC0) Will be 00000000 (==0) if and only if it's an IDR(keyframe). On to the next. Since the other encoding methods (MPEG2 and H264) don't use this extra byte we have to go and get it special. Specifically, this seems designed to do this. An extra read inside of the main read loop. //if(!read_video_packet(d_video)) break; // EOF But if you look at the code for read_video_packet, it seems to only 'copy the startcode' for the first bytes. // COPY STARTCODE: packet_start=videobuf_len; videobuffer[videobuf_len+0]=0; videobuffer[videobuf_len+1]=0; videobuffer[videobuf_len+2]=1; videobuffer[videobuf_len+3]=next_nal; videobuf_len+=4; SOOOO, not only is x3F the wrong bit-mask, the data won't be there anyway. And, to compound the problem, this extra read_video_packet PROBABLY does something funky to the state of the stream. Not sure. Anyway. My solution/hack. Super Global variable "peek_nal_descriptor" Set this whenever getting data, but don't mess up the state of the stream..use "demux_peekc". next_nal = demux_getc(ds); peek_nal_descriptor = demux_peekc(ds); Use super global variable in seek code. if(i==0x1B6) { if ( (peek_nal_descriptor & 0xc0) == 0) break; OK, good. Works. Furthermore... AFAIK, this code is only for skipping packets until an I-frame. It seems no provision is made for re-generating a picture by skipping backward to the previous I-frame and applying the B and P differential frames. Code for such a feature would certainly break this whole deal. I don't like the global variable any more than anyone else, but this is C, kind of old crusty C....anyway It would be better if this were more integrated in the flow of parse_es.c. Like if read_video_packet set the rest of the structure. Or if sync_video_packet did something to set up the structure. This would probably be part of the problem. Return value from sync_video_packet. return 0x100|next_nal; Only room for one byte. I think demux_ts.c has the same problem. Allright, let me know what you think. Gotta go watch *hicago *ode on my 'DVR' andyzsmith(a)yahoo.com

4 4

[PATCH] CrystalHD: Improve library detection
by Philip Langdale 29 Mar '11

29 Mar '11

Gwenole pointed out, in the context of ffmpeg, that the library detection could look for a newer symbol so that it will reject old versions of the library that won't work. This change implements that for mplayer. --phil

2 1