gmane.comp.video.mplayer.devel

Re: [PATCH] ralf support with native demuxer

Alexander Strasser — 2012-05-25T23:45:19

Hi Roberto,

Roberto Togni wrote:

  Patch looks good to me. 

  I noticed 2 minor points that should *not* be addressed in this patch:
  1) realloc is not used properly (failure case)
     not sure if it wouldn't even be better to solve it without the realloc
  2) the formatting of the (whole?) file is a bit weird
     - mix of tabs and spaces
     - probably more...
 

  If it doesn't work, please complain here. It will for sure be fixed :)
 
[...]

  Alexander

Re: [PATCH] ralf support with native demuxer

Reimar Döffinger — 2012-05-25T20:56:05

It should, and nice to see you're still around :-)
I think you can just go ahead and commit.


I don't see the point of the comments though.


The outermost () are not really necessary.


Since that's probably a copy from other code in the file it's kind of unrelated,
but I think this kind of code shouldn't be necessary anymore, it is
already handled in new_sh_audio nowadays.

Re: Release 1.1 first packaging attempt

Stefano Pigozzi — 2012-05-25T08:45:30

On Sun, May 6, 2012 at 2:04 PM, Reimar Döffinger
<Reimar.Doeffinger< at >gmx.de>wrote:


I compiled the tarball on Mac OSX Lion (Xcode 4.3):
 -  clang 3.1 compiles and works correctly. When cc is clang (so you don't
have to call configure with --cc=clang) there is a fair amount of spam like
this:
clang: warning: argument unused during compilation: '-falign-loops=16'
clang: warning: argument unused during compilation: '-shared-libgcc'

This is because the configure script adds those flags basing the choice on
$_cc instead of $cc_vendor.

 -  llvm-gcc-4.2.1: there's the usual problem when linking vf_fspp:
Undefined symbols for architecture x86_64:
  "_MM_FIX_0_707106781", referenced from:
      _filter in vf_fspp.o
  "_MM_FIX_0_541196100", referenced from:
      _filter in vf_fspp.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1

This ticket (http://ffmpeg.org/trac/ffmpeg/ticket/353) contains all the
interesting information about this issue. I'll try

[PATCH] ralf support with native demuxer

Roberto Togni — 2012-05-24T22:37:18

Hi,
 this adds support for ralf codec (ffmpeg decoder only, not the binary 
dll) to our real demuxer.

Tested with the two ralf sample that I have.


I'll apply it in a few days if no comments (and if my svn account still
works).

Ciao,
 Roberto
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: Release 1.1 first packaging attempt

Alexander Strasser — 2012-05-23T22:22:33


  I did a bunch of small encodes from DVD material and I can say: it kind
of works. Not sure how good, and if there are any regressions but at least
it can be used.

  Alexander

Re: [Patch] live555 configure error

Zongyao Qu — 2012-05-23T13:04:00

tested. Worked as it should be, pass the old version and refuse
the new version of live555.
Thank you.

Re: [PATCH] Plaintext playlist parsing

Ingo Brückl — 2012-05-22T21:18:48

Reimar Döffinger wrote on Tue, 22 May 2012 19:57:09 +0200:



I'm aware of this, but since this additional plain text playlist parsing will
only happen if the user selects from the "Playlists" filter of the file
selector it's up to him to deal with the consequences if he selects something
that is not a playlist (but having a playlist extension, as the selection is
limited). There isn't much more that (security-wise) can be done in order to
allow playlists with the GUI. (And if you're using option -playlist by
accident with a DVD image and plain MPlayer, well, the same bad things will
happen.)

The "Playlists" filter is the GUI's equivalent to the -playlist option.


I really get your point and share your concerns, but I think the limitation
to the "Playlists" filter for this feature makes the risks acceptable.

So, ok to commit?

Ingo

Re: [PATCH] Plaintext playlist parsing

Reimar Döffinger — 2012-05-22T17:57:09

I am not sure this is a good idea at all, even for the GUI.
The problem is that there is no sanity checking at all for plain text
playlist.
Imagine if someone by accident gets a DVD image in there, I am sure
really bad things will happen (like a few million or so playlist
entries, using up loads of memory, swapping, possibly even
out-of-memory crashes).
At least I really hate it when programs can't deal with me having
too thick fingers and click on the wrong file (since I don't use
gmplayer I don't really care, but still).

Re: [Patch] live555 configure error

Reimar Döffinger — 2012-05-22T17:52:15

Thanks, fixed differently in r34960, I really dislike the duplication.
Can you test that it actually works? I have only the "distribution
version" so the test always worked for me...

[Patch] live555 configure error

Zongyao Qu — 2012-05-22T14:16:03

I found live555 checking is extended, but libliveMedia.a is forgotten.
as a result, live555 will never get passed.

this patch is going to fix this.

Best Regards,
Zongyao QU
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCH] Plaintext playlist parsing

Ingo Brückl — 2012-05-22T09:18:44

I wrote on Tue, 22 May 2012 00:24:34 +0200:


Yeah, I think

  entry      = parse_playtree(mpctx->stream, use_gui);

is probably much better, because it doesn't change the current (non-GUI)
behaviour.

Ingo

Re: [PATCH] compile as PIE by default

Reimar Döffinger — 2012-05-22T07:20:23

I'll have to test, though it really shouldn't, these are orthogonal things (even though I admit it is a bit confusing).


Agreed in principle, I was too lazy to do it for an RFC oatch.


Was a long time ago, so I don't remember. However we have no win32loader for 64 bit, and for 32 bit it is a link only option, so compiling should work.
The only issue should be that loading some dlls might randomly fail if MPlayer by chance is placed at the location where the dll needs to be loaded. Disabling address randomization for MPlayer would fix it, even if it eliminates the advantage.
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCH] compile as PIE by default

Ivan Kalvachev — 2012-05-22T01:27:12

Without researching the topic.
Would the above check fail if --enable-static is used?
I think there must be a way to disable this with configure option,
e.g. --disable-pie

Have you tested it with the win32loader?
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCH] compile as PIE by default

Alexander Strasser — 2012-05-21T22:56:14

Hello Reimar,

Reimar Döffinger wrote:

  Sounds reasonable, judging from what you say. I cannot evaluate the
ramifications myself. So no strong opinions on my side.

  Waiting a bit for more informed comments, may be better though.

  Alexander

Re: [PATCH 0/2] configure fixes

Alexander Strasser — 2012-05-21T22:43:42

  Applied this one as there were no objections and it
makes things easier for people (including me).


  This one is dropped.
  Thanks for the alternative fix go to Reimar!


  Alexander

[PATCH] Plaintext playlist parsing

Ingo Brückl — 2012-05-21T22:24:34

I'm missing plaintext playlist parsing. Is this patch ok or should it be
somehow restricted to the GUI (use_gui)?

Ingo
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

[PATCH] compile as PIE by default

Reimar Döffinger — 2012-05-21T20:54:15

Hello,
below patch would compile MPlayer as PIE on x86 by default.
On 32 bit, the cost would only be in a larger binary size and having to do
relocations at startup, but no real cost at runtime.
On 64 bit, there is almost no size or runtime overhead, mostly that
in some cases PIC-relative addressing has to be used.
I believe that none of the assembler code will be disabled by either.
I have not made any changes to other architectures since I can't
judge the impact.
A side effect of the 64 bit case is that MPlayer will refuse to link
against some static libraries (those not compiled with PIC and thus violating
the ABI), one example (which only exists as static library) is LIVE555
as provided by Debian.
Another point is that backtraces without debug info will probably be
even less useful.
Any comments? My belief is that there is negligible if any disadvantage
for a sometimes significant win in security.

Index: configure
===================================================================
--- configure(revisio

Re: A bit more liberal parsing of tags in .srtfiles?

Szokovacs Robert — 2012-05-21T15:46:20

Could somebody take a look please?

br

Szo

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCH] Fix wrong runtime and average bitrate for VBR MP3.

Benoît Thébaudeau — 2012-05-18T21:06:29

Indeed. Thanks!

Regards,
Benoît
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCH] Fix wrong runtime and average bitrate for VBR MP3.

Reimar Döffinger — 2012-05-18T20:53:32

Thanks, removed.
Am I right that everything should be fine now?

Re: [PATCH] Fix wrong runtime and average bitrate for VBR MP3.

Benoît Thébaudeau — 2012-05-18T20:48:16

http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm says "Frame size is the
number of samples contained in a frame. It is constant and always 384 samples
for Layer I and 1152 samples for Layer II and Layer III.", which contradicts
http://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header#MPEGAudioFrameHeader,
which gives 576 s/f for LSF Layer III. The latter information seems more
reliable, and MPlayer's code is based on it. If we rely on this, [spf < 1152]
and [lsf] are the same for mp3_vbr_frames() since it has checked beforehand that
the layer is III. Hence, you can drop this part of my patch.

BTW, ssize is computed by mp_get_mp3_header(), but never used.


Correct.

Regards,
Benoît
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng< at >mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng