03:08
<JohnTeddy>
Compn: o wow, I didn't know there was an mplayer android versino
03:15
<JohnTeddy>
Compn: I can't find the mplayer version of android anywhere on the website or on the Google Market
04:02
<mystica555_>
is there any way in mplayer to prevent this scenario: when the cache empties, i am prevented from hitting any keys while it tries to refill the cache, basically rendering me unable to pause to let the cache actually fill
04:03
<mystica555_>
as i play a video across a VPN tunnel, the cache sometimes bottoms out, the mpeg2 playback goes frame by frame slowly, and i cannot pause
04:04
<mystica555_>
its a mounted samba share
04:04
<mystica555_>
but even http shoutcast streams have the same issue
04:36
<JohnTeddy>
Compn: http://forum.xda-developers.com/showthread.php?t=890761 ... is that what you're refering to?
04:39
<JohnTeddy>
Those URLs are dead, does mplayer's website have something?
04:51
<JohnTeddy>
Compn: According to the XDA thread.. that person isn't releasing their source code...
06:40
<Compn>
mystica555 : no, another bad luck is that cache wont fill when paused either , haha
06:41
<mystica555_>
Compn: well i see a percentage meter growing as i pause it, when i can pause it, after waiting for keyboard repeat and then it bouncing on and off of pause
06:41
<mystica555_>
til i finally get it paused
06:42
<mystica555_>
50x/sec repeat
06:42
<Compn>
JohnTeddy : https://github.com/ajeet17181/mplayer-android
10:21
<Compn>
wonder if frogs enjoys the amount of replies such a small patch garners :)
10:58
<iive>
Compn: should I go ahead and commit the patch?
11:03
<Compn>
and berate others for spending so much time on a small patch instead of reviewing the other dead patches on the list :P
11:06
<sacarasc>
How long was the patch? :D
11:06
<Compn>
12 lines, replacing non-ascii with hex codes or something
11:07
<Compn>
non controversial
11:07
<Compn>
but it is old code
11:07
<Compn>
so , time for bikeshed
11:08
<iive>
i've sent email as reply to diego
11:09
<iive>
and asking you to commit it, so feel free to go ahead.
13:34
<chx>
hi. i am having trouble with starting position.i tried $ mplayer -ss 347 with an mp3 file to jump to five minutes 47 seconds. what did i do wrong?
13:39
<relaxed>
chx: what happens?
13:40
<relaxed>
you can also use -ss 00:05:47
13:41
<chx>
it seeks a little
13:41
<chx>
but never a lot
13:41
<chx>
and the time display is completely wrong
13:41
<chx>
if i press say left arrow then it rights itself
13:42
<relaxed>
are you using a recent version?
13:42
<chx>
MPlayer SVN-r34578-4.6.2
13:46
<relaxed>
Does it happen with other mp3s? It's working for me using mplayer2.
13:47
<chx>
it's definitely the MP3
13:47
<chx>
very interesting
13:48
<chx>
what happened, seriously, i bought the album in 7digital last week, it was broken so i pirated the same album and forgot to download the legal version now that the store unbroke itself.
13:49
<chx>
the legal version works :)
14:04
<lockheed>
can someone tell me why mplayer doesn't support ffw/rewind by set second value? This is really annoying to be randomly thrown back or forward, instead of preset value like in any, even the most crappy, windows player
14:09
<lockheed>
it just jumps to nearest keyframe
14:11
<frogs>
that's normal
14:11
<frogs>
it will go to the seek time and then look for a keyframe there and past until it finds one
14:26
<lockheed>
yeah, and it sucks because that means if I set it to go back 5 seconds, it can end up anywhere between 3 and 9 seconds, while in windows it is always 5 seconds. I have talked about it with mplayer developers about a year or more ago, but for the love of me I cannot begin to understand how can they not consider it a shortcoming and aim to remedy it ASAP.
14:27
<Compn>
keyframes are useful
14:27
<Compn>
otherwise you could jump into an asteroid field or straight into a supernova, and that would ruin your day real quick
14:30
<lockheed>
millions of windows users live their lifes never having this problem, and still having precise seeking mechanism in their players
14:31
<iive>
lockheed: use mplayer2
14:33
<iive>
windows play also takes forever to seek... that is the price of exact seeking.
14:33
<mystica555_>
seek to previous keyframe, decode forward...
14:33
<* relaxed>
takes a screenshot to preserve iive's comment forever
14:36
<frogs>
Compn: did you commit patch?
14:36
<Compn>
i commit nothing!
14:36
<Compn>
lockheed : mplayer2 has a fixed seeking thing
14:37
<Compn>
so give that a try
14:37
<Compn>
btw, number of mplayer developers = 1
14:37
<frogs>
funny thing to do: make only one keyframe in the file
14:38
<Compn>
frogs : its not like dustin' crops boy!
14:39
<frogs>
with xvid, your video turned to jelly. it works with x264
14:39
<relaxed>
Compn: This isn't the mplayer he's looking for.
14:41
<lockheed>
I am using mplayer2...
14:41
<Compn>
lockheed : then bug uau in #mplayer2 channel
14:41
<lockheed>
but only since few days, so am not sure about the seeking thing
14:42
<lockheed>
but by 'fixed' what do you mean? that it does not go to the keyframe?
14:42
<uau>
lockheed: mplayer2 still defaults to keyframe seek if you use arrow keys (but defaults to precise seeks for chapter seeks for example)
14:42
<Compn>
well i thought it was 'fixed' over there
14:42
<Compn>
tbh i havent tested nor cared
14:42
<uau>
Compn: yes it does support precise seeks
14:43
<uau>
but keyframe seeks still exist too
14:43
<uau>
you can choose which one to use
14:43
<Compn>
well how do you make precice seeks default then ?
14:43
<uau>
"--hr-seek=always" for example
14:43
<Compn>
thats what lockheed wants
14:43
<uau>
there are also default keybindings for them, shift+arrow
14:44
<uau>
(requires you to be using an input method that supports key modifiers - terminal and windows VOs do not)
14:44
<Compn>
windows vo does
14:45
<Compn>
i cant remember now , its been a while since i tested
14:45
<uau>
shift+left is 1 second seek back, shift+down is 5 second seek back
14:46
<Compn>
uau : this works in vo directx > CTRL_d seek -10
14:46
<Compn>
in input.conf
14:46
<Compn>
and direct3d
14:46
<Compn>
and vo gl...
14:47
<Compn>
also works if command prompt is active
14:47
<Compn>
instead of video window
14:48
<lockheed>
how about xv?
14:48
<uau>
lockheed: should work in all X-based VOs
14:48
<Compn>
i'm on windows, cant test ;D
14:48
<uau>
Compn: that ctrl thing is actually a kind of bug
14:49
<lockheed>
so, if I am using smplayer2, do I set this "--hr-seek=always" in options for mplayer2 cmd line?
14:49
<Compn>
iive : why do mplayer2 users always seem to bother us here in happy #mplayer ?
14:50
<uau>
lockheed: yes, and that's probably the only way in smplayer2 (AFAIK smplayer2 does not yet have support for those shift-arrow keys, and under smplayer2 mplayer2's own input handling is not used)
14:51
<uau>
Compn: note that ctrl is handled as a normal key there
14:52
<uau>
(in win32_common.c)
14:52
<uau>
not as a modifier
14:53
<Compn>
you want modifier so you can copy and paste into mplayer? :P
14:53
<Compn>
but yeah, i have no idea about this
14:54
<lockheed>
Yes! It works! Finally after 4 years on linux I can have perision seeking again. Thanks, uau
14:54
<uau>
Compn: i mean it doesn't actually support Shift+Left and Shift+Right separately
14:54
<uau>
you'd get a separate "ctrl press" even "left arrow press" event
14:59
<iive>
Compn: go ahead and commit that patch already.
15:01
<iive>
do you want me to commit it?
15:03
<Compn>
iive : sure
15:04
<Compn>
are they hex values ?
15:04
<Compn>
i dont know what to call them
15:05
<iive>
afraid from the bikeshedding?
15:20
<Compn>
iive : afraid i'll have to change the commit message because king diego doesnt like it
15:20
<Compn>
so yeah, bikeshedding
15:23
<iive>
he is not king anymore.
15:27
<frogs>
iive: arguing about the clang?
15:27
<iive>
yeh,, bikeshed
15:27
<iive>
do we have your email/realname to give you credit for the patch?
15:28
<frogs>
iive: you know how sometimes programs will not build after gcc upgrades because they added more checks that make it stricter on what it will accept?
15:28
<frogs>
it is the same here, just with clang
15:28
<frogs>
they are adding checks to make sure that strings you type are compatible with the encoding of the variable
15:28
<iive>
the patch is OK, it is just random people picking on unsignificant details
15:29
<iive>
like comments.
15:29
<frogs>
it's done as part of adding support for 8-16-32 bit wide characters
15:29
<iive>
wide characters.... are spawns of the devil
15:30
<frogs>
iive: i'm glad for your support. a lot of people are hostile towards clang for some reason
15:30
<frogs>
license wars
15:30
<iive>
well, nobody likes gcc. it have so many bugs and poor optimizations
15:31
<iive>
it have been unchallenged for quite some time, it needs competition.
15:31
<frogs>
we (freebsd) were switching for license reasons
15:31
<frogs>
we hope to have a gpl-free base system for freebsd 10
15:32
<iive>
doesn't bother me, as long as I can singlehandedly license the whole clang as gpl :)
15:32
<frogs>
we are hoping to move into a market of companies who have no-gpl policies
15:33
<iive>
:) pure evil. Like Apple and MS.
15:34
<frogs>
apple gave us clang
15:35
<frogs>
we are finding and fixing bugs and it's working well so far
15:35
<frogs>
i haven't tested again with the clang devel 3.1 against gcc 4.6 benchmark
15:36
<frogs>
i don't encode much any more
15:55
<beastd>
iive, frogs: the clang patch should be OK and I don't care having them in the comments or not (though I dislike having latin1 characters in the source files and therefore also don't like them in comments)
15:56
<frogs>
beastd: i have looked more and if no option, clang does assume file to be ascii, but i don't yet know how to tell clang to assume different charset for input file
15:57
<beastd>
additionally i think nicolas was OK with the patch from the beginning (the comments stuff was only non-important nit). but after nicolas had reviewed the patch diego rewinded the thread to the beginning starting to ask: "what is this good for?"
15:58
<frogs>
i think if i tell clang that input file is utf-8, it would build ok
16:00
<beastd>
frogs: do i misremember now, or wasn't it latin1 encoding that got changed to hex literals by the patch? also why should ascii not be enough for source files if we comment in english? it is the most compatible encoding and every character fits in 7 bits.
16:01
<Compn>
frogs : but you need to tell iive if he should credit you, and if so, want him to credit your email or nickname or real name or what
16:01
<beastd>
i could only imagine it would be bad for writing the name of the author/copy right holders
16:01
<frogs>
beastd: i just changed some > 127 things to hex
16:01
<frogs>
beastd: http://pastebin.com/raw.php?i=0eEqkkZR
16:03
<beastd>
frogs: right, but would it have been utf8 than it would have 2 or more bytes in that case. also i remember nicolas having checked that the string literals were latin1 and the patch changed them to corresponding hex literals (which can be represented with ascii chars only)
16:13
<beastd>
frogs: i don't have time currently. but if nothing gets committed until the weekend i will see what can I can do.
16:19
<frogs>
iconv -f ASCII -t UTF-8 sub_cc.c iconv: sub_cc.c:68:19: cannot convert
16:20
<iive>
ascii is 7 bit
16:21
<frogs>
it does accept if i do -f latin1, but clang fails to build that file with error: character too large for enclosing character literal type
16:30
<frogs>
iive:for 0x2a, hex editor says 0xe1, after convert with iconv, it's now 0xc3a1, it's probably complain cos you can't stuff 16 bits into a char
16:30
<frogs>
the chartbl[0x2a] line
16:31
<iive>
utf8 encodes codes that are bigger than 0x7F with 2 bytes
16:31
<frogs>
iive: the right way to fix this is to tell clang "this file is latin1" or make chartbl two byte elements intead of one byte elements?
16:32
<iive>
the right way is to put the hex codes and don't bother with encodings
16:32
<iive>
as you've done.
16:33
<frogs>
i tried changing chartbl to wchar_t, but didn't change anything
16:34
<beastd>
frogs: your initial fix was correct: removing the latin1 character literals
16:34
<frogs>
what is diego's nick on this network?
16:35
<beastd>
We don't really want to have latin1 encoded character constants in our source files.
16:54
<frogs>
iive: i could test if it complains about the comment letters, should those be latin1 or utf-8 in the comment though?
16:57
<frogs>
iive: builds with latin1 and utf8 in comment
16:59
<iive>
good to know. thus I expected it.
16:59
<frogs>
pastebin (or my copy and paste or browser) converted patch to utf-8 though
16:59
<frogs>
so it does fail to apply
17:55
<redxii>
what does mplayer look for for libmng and fribidi?
17:56
<redxii>
supposedly fribidi-config but they don't have one, even with a fribidi-config it still can't find it
18:06
<beastd>
redxii: did you look into config.log?
18:12
<redxii>
seems i need icms for mng
18:15
<redxii>
I can add -DFRIBIDI_ENTRY="" for fribidi but i seem to be the only one who does this, google only shows my pastebins
18:16
<redxii>
for some reason the lcms sourceforge site is broken
19:15
<Joe7>
Is there any particular compiling option for mencoder that could greatly affect video encoding performance? Have 2 hosts, 1 with intel E5345 (8cores at 2.33Ghz) the other with Intel X5450 (8cores at 3.00Ghz) and the latter is almost 3x faster when encoding the very same test video. Wondering why is it like that
19:18
<iive>
are you using same binary?
19:19
<Joe7>
not the same, have compiled on both hosts, but with the very same config afaik (pretty much default)
19:19
<iive>
3x difference could be explained if the binary is compiled without any assembler SIMD.
19:19
<Joe7>
uhm whats that? :P
19:19
<iive>
x264 uses yasm I think.
19:19
<iive>
mmx,sse stuff like that.
19:20
<Joe7>
uhm if I see #define HAVE_MMX 1 in config.h that was made during the compilation it shall be good though right? Or what other way could I check that?
19:21
<iive>
depends what encoder are you using.
19:22
<iive>
aka, libavcodec encoders use mostly inline gcc assembler, so most of the stuff would be accelerated.
19:22
<Joe7>
is always x264
19:22
<frogs>
Joe7: no runtime cpu detection?
19:22
<iive>
but libx264 uses exclusively external assembler like yasm or nasm
19:23
<iive>
and that is not part of typical gcc installation.
19:23
<frogs>
Joe7: try diffing the output of the two commands
19:23
<Joe7>
of what command?
19:23
<frogs>
the mencoders
19:23
<iive>
Joe7: frogs ask you if you use exactly same options
19:24
<Joe7>
very same shellscript and src actually, just copied over from 1 host to other, testing from cmd line simply
19:24
<Joe7>
so yeah, same mencoder cmd for sure
19:24
<frogs>
try copying over the mencoder binary too
19:24
<Joe7>
that won't work
19:25
<iive>
Joe7: did you compile libx264 on your own?
19:25
<Joe7>
as the binary won't find the referencing includes/files on the other host most likely
19:25
<Joe7>
iive: I have yeah
19:25
<iive>
Joe7: ok, compile it again on the slower system, and see if it would find the n/yasm
19:35
<Joe7>
iive: Platform: X86_64
19:35
<Joe7>
System: FREEBSD
19:35
<Joe7>
^thats the relevant part right?
19:36
<frogs>
you'll see some yasm lines when it runs it
19:36
<Joe7>
uhm runs what exactly?
19:36
<beastd>
Joe7: is that from libx264?
19:37
<frogs>
yasm -f elf -m amd64 ... file.asm
19:37
<Joe7>
beastd: yeah, from its ./configure
19:38
<beastd>
ah ok, fine
19:39
<Joe7>
frogs: have not seen anything like that during make/install
19:39
<frogs>
the port does use yasm
19:40
<frogs>
see, we are not alone. they accused me several times of being the only mencoder user on freebsd
19:42
<Joe7>
yeah tbh its not the port that is available from among freebsd ports..is some kinda checkout from x264 repository from..sometime ago. (Was used on live system and just copied over to build and test on a new supposedt-to-take-encodingover-host)
19:43
<frogs>
i build mplayer from source cos of the lack of releases
19:44
<frogs>
Joe7: you should update the x264 checkout. they improve it rapidly
19:44
<frogs>
speed+quality improvements
19:44
<iive>
Joe7: after you build x264 you can find some .asm files and see if there are corresponding .o object files.
19:44
<Joe7>
allright, can give it a try atm
19:44
<Joe7>
iive: just building x264 from freebsd repo, this definitely detected yasm (seen it reported) and the yasm cmds r getting executed as well..right now
19:45
<iive>
i hope it installs shared and static libraries.
19:45
<Joe7>
installed shared ones it seems yeah
19:46
<Joe7>
I do not need to recompile mencoder too right? would just these new files anyway? :>
19:47
<iive>
Joe7: depends, try ldd mencoder, if it detects the new library, you are good to go.
19:48
<iive>
if it have been statically linked, you'd have to at least re-link mencoder (aka if the build still lays around).
19:49
<Joe7>
ldd mencoder does not seem to have any x264 related stuff in the list
19:49
<Joe7>
http://pastebin.com/0SYzgaCi
19:50
<iive>
i don't see it either
19:50
<Joe7>
what does that mean sir? It's kinda late here and am kinda superdumb anyway ;)
20:04
<iive>
i don't see libx264 in the mencoder shared libraries. You need to recompile/relink it.
20:10
<frogs>
Joe7: if mencoder -ovc help lists x264, it's ok
20:11
<iive>
frogs: compiling new x264 won't change the version that is already inside mencoder binary. so relink/recompile.
20:12
<Compn>
its possible ffmpeg linked x264 ...
20:12
<Compn>
since x264 can go directly in mencoder or ffmpeg which mencoder uses -ovc lavc -lavcopts codec=libx264
20:13
<iive>
Compn: i don't see shared ffmpeg either, so...
20:13
<frogs>
iive: did you ever commit those patches i mailed? the ones to reduce the number of local patches in the port
20:14
<iive>
i think i forgot them. I guess I'll look them up.
20:15
<frogs>
our port looks like a mass number of patches various people threw in to fix something at some point in time
20:15
<frogs>
i like to document when adding some thing like that, the reason why so that later it can be seen if it's still necessary
20:16
<iive>
frogs: yeh. Diego loves to remove workaround that are no longer required.
21:03
<Joe7>
sweet, compiling from freebsd ports and recompiling mplayer as well helped! an amazing 3x boost in speed, even faster than on the higher spec host ;) Thx!
21:10
<iive>
i'm glad it helped :)
22:27
<Compn>
haaaaaaaaayyyyyyyy
22:29
<ZenGuy311>
i have some new x264 videos and apparently my netbook is too slow to play the videos , Architecture: i686
22:29
<ZenGuy311>
CPU op-mode(s): 32-bit
22:29
<ZenGuy311>
CPU(s): 2
22:29
<ZenGuy311>
Thread(s) per core: 2
22:29
<ZenGuy311>
Core(s) per socket: 1
22:29
<ZenGuy311>
CPU socket(s): 1
22:29
<ZenGuy311>
Vendor ID: GenuineIntel
22:29
<ZenGuy311>
CPU family: 6
22:29
<ZenGuy311>
Model: 28
22:29
<ZenGuy311>
Stepping: 2
22:29
<ZenGuy311>
CPU MHz: 1600.000
22:29
<ZenGuy311>
how can I get the video to play it's like 200MB
22:34
<frogs>
you need vdpau or bigger cpu
22:35
<frogs>
or you could convert it and rescale it to be smaller and to a less cpu using format
22:37
<Compn>
ZenGuy311 : try -lavdopts threads=2
22:38
<Compn>
that should fix it
22:38
<Compn>
does your netbook not have accelerated h264 playback ?
22:38
<ZenGuy311>
Compn: thanks for responding
22:38
<ZenGuy311>
I don't think so, i'm using a varient of ubuntu 10.04
22:39
<ZenGuy311>
i tried mplayer2 too
22:42
<Compn>
mplayer2 should automatically try multiple threads i thought
22:42
<Compn>
ZenGuy311 : did -lavdopts threads=2 work ?
22:43
<ZenGuy311>
my netbook is hanging with opera i'm bookmarking private tabs so I can then exit it , i'll run it in 1 minute
22:47
<Compn>
opera rules :)
22:47
<ZenGuy311>
Compn: it has way better memory managment than any other browser i've tried especially on my netbook
22:51
<ZenGuy311>
Compn: THANK YOU! it works!
22:52
<ZenGuy311>
sweet, I just aliased it in bashrc .. I'll decipher what the operators do tommorow but thanks
22:53
<ZenGuy311>
i like to use umplayer as a frontend, is there anyway I could have it invoke those operators when playing .mp4 files only ?
22:55
<Compn>
you put it in config
22:55
<diegoviola>
ZenGuy311: use pastebin pls
22:55
<Compn>
with [extension.mp4]
22:55
<Compn>
lavdopts=threads=2
22:55
<Compn>
two lines at the bottom of your config file
22:56
<ZenGuy311>
diegoviola: ok
22:56
<ZenGuy311>
Compn: which config file exactly?
22:56
<Compn>
~/.mplayer/config
22:56
<ZenGuy311>
Compn: ok
23:01
<ZenGuy311>
Compn: now I can't play any videos in umplayer .. it doesn't even tell me the length of the videos in the playlist .. just 00.00.00
23:03
<Compn>
did you type it all right ?
23:05
<ZenGuy311>
I copied and pasted it
23:06
<ZenGuy311>
i'm looking at a arch wiki for mplayer .. i'm going to remove "with
23:06
<Compn>
yes remove the with
23:07
<ZenGuy311>
works no prob ... man I get so excited when a problem gets solved