December 2010 - MPlayer-dev-eng - lists.mplayerhq.hu

EVR Renderer
by Georgi Petrov 30 Dec '10

30 Dec '10

Hi, The Enhanced Video Renderer (EVR) turned out much more complicated than I imagined from what I've tried and saw as code. I may underestimated it a little bit, but I'm working on it. As my experimental code is very far from initial inclusion, I have a question. Can I submit the first patch to enable the "EVR infrastructure"? I refer to needed changes in configure, the new vo_evr.c and so on. Unfortunately VLC doesn't implement EVR at all. It just reads back from DXVA 2 and displays using other renderers. Right now the most complete implementation is in MPC-HC's source. I will write more information in the following days.

4 7

[PATCH] better detection of ASS comas number
by Aurelien Jacobs 29 Dec '10

29 Dec '10

Hi, Currently, when parsing an ASS file without using libass, MPlayer is wild-guessing the number of comas before the Text field of dialog events lines, just hopping that it is the most commonly used one without really checking. Attached patch adds some real auto-detection of the comas number by counting the number of comas in the "Format:" line of extradata. If no extradata is present or auto-detection don't work, it fallback on the previously used wild-guessing. Aurel

1 0

make x264 options more clear patch
by Joseph Miller 27 Dec '10

27 Dec '10

Dear list, I just found out that I should have been using crf instead of qp for x264 encoding and have been using the wrong options for the last 2 years. So that other people who are as dumb as I am don't make the same mistake, I propose the following patch to add make the man page more explicit. Please let me know if this is acceptable or if another approach should be made here. -Joseph

2 1

internal libfaad2 forked copy
by Diego Biurrun 23 Dec '10

23 Dec '10

Janne just committed LATM support to FFmpeg. AFAIK that fixes the main shortcoming of FFmpeg's AAC decoder compared to libfaad2. IOW, the time for us to remove the internal libfaad2 copy from MPlayer appears to have come. libfaad2 is still faster than ffaac in fixed-point mode on my K6-III, which has a slow FPU, but I'm not aware of any other major issues. Anything I'm missing? Otherwise libfaad2 shall go the way of the dodo. Diego

8 34

[PATCH] RFC: CrystalHD decoder support
by Philip Langdale 22 Dec '10

22 Dec '10

Hi all, For the past few weeks, I've been attempting to implement CrystalHD decoder support, first directly in ffmpeg and then in mplayer - and I'll touch on why that is in a moment. The current patch is largely functional with a few important caveats: * It doesn't work properly with the 70012 hardware. I did all my development against a 70015 and haven't really paid any attention to the 70012. It will run but it performs terribly for some reason. * Interlaced frames are not handled very well - it kinda works but av-sync is a mess. * Files with resolutions above 720p probably won't play properly due to not being able to get data in and out of the decoder fast enough. Broadcom state in the driver/lib source that you need separate input and output threads to keep it fed and I'm not sure how to reconcile that with the mplayer/ffmpeg API (I assume ffmpeg-mt could do this). However, the biggest issue is that the decoder breaks an assumption in mplayer about how many calls to decode can occur before a frame is returned. At the start up, the crystalhd might require 20 or more calls before it ever returns a frame, and without increasing the maximum number of buffered_pts, it will start discarding them, ensuring that av-sync goes out the window. So, I've bumped max buffered_pts to 128 in this patch - 64 was too low, but it might need to be even higher for 1080p content. I'm also not sure how QUERY_UNSEEN_FRAMES should be used. I don't know how many complete frames are in the decoder waiting to be decoded and mplayer seems to be comparing the result with buffered_pts which comes from the pts passed to each decode call, so I'm pretty confused. It also doesn't help with vd_ffmpeg adding 10 and then having it subtracted later. So I ended up returning 20 + the number of decode calls that haven't returned a frame since the last flush. It seems to work but it's hardly scientific. With that in place, progressive <= 720p content plays well - with a note that I have to force lavf to demux avi and wmv files correctly. The native demuxers dont' sync properly - i think because they also make assumptions about how long you have to wait for frames to come back. I'm not sure what's going on with interlacing. xbmc does line-doubling on each field and the gstreamer plugin doesn't handle it at all so I had to guess, and while I can construct a frame that de-interlacing filters are happy with, av-sync goes way out the window; NTSC content plays at not-quite half rate (if I force 59.94, it plays slightly too fast), etc. Now, why an mplayer plugin? I originally wrote this as an ffmpeg hwaccel on top of Gwenole's v2 patch with some additions to support accelerating decode_frame as opposed to decode_slice and it kinda worked but most of my h.264 streams would make the crystalhd grumpy (those play fine with the mplayer plugin). There's also no real benefit in terms of code sharing as the only place we need codec awareness is the sps/pps decoding and ffmpeg's h.264 codec doesn't build up a compatible struct anyway. I also had a problem where I just got solid grey output with x11/xv (but correct frames with vdpau). So, combining all that with wanting to debug the sync problems as directly as possible, I switched to an mplayer plugin and everything worked much better. Philosophically, I think it can be argued either way; you can consider libcrystalhd to be a library codec like theora or xvid and say it's a valid mplayer codec on that basis, or you can argue that it's an accelerator that should be usable from ffmpeg (although the advantages for a transcode job are going to be very marginal). At this point, I'm not seriously suggesting it's ready to go in - the interlaced handling needs to get sorted out and I think we need a more rigorous basis for how the av sync interactions are done; still I'm sure some people will be very happy to see mplayer finally using this hardware. --phil

5 9

Work on SDP and RTP support
by Clément Bœsch 22 Dec '10

22 Dec '10

Hi, At the moment, the FreeSDP library copy is only used in for the code in librtsp/rtsp_rtp.c. Since the freesdp code is a bit overkill, and unmaintained upstream, I thought of rewriting a small parser for the SDP protocol. So I just did it this week end, and it implements almost everything of RFC4566 in something like 400 lines (instead of the 10 times more with FreeSDP). Then I changed the freesdp calls in rtsp_rtp.c to the new sdp parser without any special issue. But the major issue now is to get a RTP stream working: I tried something like 10 streams on http://wiki.multimedia.cx/index.php?title=RTSP#RTSP_MOV.2FMP4 but none work. If I use the -rtsp-stream-over-tcp switch, it fallbacks to live555 module and then works. ffmpeg:// also works. But in both cases, it's a fallback to the RTP code failure. So a few questions: 1) Are you interested in a fix for the RTP code or you prefer to let it rot/drop it? 2) If you're ok with a fix, do you have a stream that currently works with it, or at least "should" 3) Are you ok with dropping FreeSDP over a simpler (already done) SDP implementation? Regards, -- Clément B. Not sent from a jesusPhone.

6 8

Re: [MPlayer-dev-eng] [PATCH] RFC: CrystalHD decoder support
by Philip Langdale 21 Dec '10

21 Dec '10

On 2010-12-20 8:34:29, Benjamin Zores wrote: > FYI, I had a BCM70012 which never worked out that well (in > gst-crystalhd). > I just bought a BCM70015 that does wonder. > So I'm starting considering it's the 70012 itself (or its firmware) > that is actually bugged. I actually got my 70012 to work well with gstbcmdec after one of the more significant updates to the driver/lib so I think it can be made to work, but certainly my current code is not treating it well. I would not be surprised to hear that the vlc patch has similar problems. > Haven't looked at the patch yet but I'll give it a try by tonight if > possible. > > FYI, VLC just added CrystalHD support very recently (or at least a > patch is 2-3 weeks old on mailing list), > if you need something else to compare with (other than gst). Thanks for the heads up, I took a look and it's conceptually the same; but it doesn't touch interlacing at all, and I suspect that if vlc actually uses output timestamps, things will go south fast on a 70015 as that fails to return them with the decoded frames (as mentioned in my reply to Reimar. I do intend to move this to an ffmpeg codec once I've dealt with the major problems and hopefully vlc can share that. --phil

1 0

[PATCH] Allow double quote to be defined in font file
by Ingo Brueckl 20 Dec '10

20 Dec '10

Hi, so far, it doesn't seem to be possible to define the double quote character in the font.fnt file. The patch enables this now. Ingo

4 9

[PATCH] RFC: CrystalHD decoder support
by Philip Langdale 20 Dec '10

20 Dec '10

Hi all, For the past few weeks, I've been attempting to implement CrystalHD decoder support, first directly in ffmpeg and then in mplayer - and I'll touch on why that is in a moment. The current patch is largely functional with a few important caveats: * It doesn't work properly with the 70012 hardware. I did all my development against a 70015 and haven't really paid any attention to the 70012. It will run but it performs terribly for some reason. * Interlaced frames are not handled very well - it kinda works but av-sync is a mess. * Files with resolutions above 720p probably won't play properly due to not being able to get data in and out of the decoder fast enough. Broadcom state in the driver/lib source that you need separate input and output threads to keep it fed and I'm not sure how to reconcile that with the mplayer/ffmpeg API (I assume ffmpeg-mt could do this). However, the biggest issue is that the decoder breaks an assumption in mplayer about how many calls to decode can occur before a frame is returned. At the start up, the crystalhd might require 20 or more calls before it ever returns a frame, and without increasing the maximum number of buffered_pts, it will start discarding them, ensuring that av-sync goes out the window. So, I've bumped max buffered_pts to 128 in this patch - 64 was too low, but it might need to be even higher for 1080p content. I'm also not sure how QUERY_UNSEEN_FRAMES should be used. I don't know how many complete frames are in the decoder waiting to be decoded and mplayer seems to be comparing the result with buffered_pts which comes from the pts passed to each decode call, so I'm pretty confused. It also doesn't help with vd_ffmpeg adding 10 and then having it subtracted later. So I ended up returning 20 + the number of decode calls that haven't returned a frame since the last flush. It seems to work but it's hardly scientific. With that in place, progressive <= 720p content plays well - with a note that I have to force lavf to demux avi and wmv files correctly. The native demuxers dont' sync properly - i think because they also make assumptions about how long you have to wait for frames to come back. I'm not sure what's going on with interlacing. xbmc does line-doubling on each field and the gstreamer plugin doesn't handle it at all so I had to guess, and while I can construct a frame that de-interlacing filters are happy with, av-sync goes way out the window; NTSC content plays at not-quite half rate (if I force 59.94, it plays slightly too fast), etc. Now, why an mplayer plugin? I originally wrote this as an ffmpeg hwaccel on top of Gwenole's v2 patch with some additions to support accelerating decode_frame as opposed to decode_slice and it kinda worked but most of my h.264 streams would make the crystalhd grumpy (those play fine with the mplayer plugin). There's also no real benefit in terms of code sharing as the only place we need codec awareness is the sps/pps decoding and ffmpeg's h.264 codec doesn't build up a compatible struct anyway. I also had a problem where I just got solid grey output with x11/xv (but correct frames with vdpau). So, combining all that with wanting to debug the sync problems as directly as possible, I switched to an mplayer plugin and everything worked much better. Philosophically, I think it can be argued either way; you can consider libcrystalhd to be a library codec like theora or xvid and say it's a valid mplayer codec on that basis, or you can argue that it's an accelerator that should be usable from ffmpeg (although the advantages for a transcode job are going to be very marginal). At this point, I'm not seriously suggesting it's ready to go in - the interlaced handling needs to get sorted out and I think we need a more rigorous basis for how the av sync interactions are done; still I'm sure some people will be very happy to see mplayer finally using this hardware. --phil -- --phil

1 0

[PATCH] Replace two malloc+memset with calloc
by Clément Bœsch 19 Dec '10

19 Dec '10

A trivial patch for two malloc+memset in stream module. Ok to apply? -- Clément B. Not sent from a jesusPhone.

2 3