Linux 64bit MiniClient (issues with mplayer)

[stuckless]

I know there are many people that not concerned about a 64 bit miniclient, but, given that all I have now are 64bit machines, the 64bit miniclient is important, to me at least.

Sadly, I've been hit with 3 stumbing blocks...

1. JTux (already posted about that here)
2. JOGL (upgrading to 64bit was easy)
3. mplayer dies playing a video on 64 bit. (The focus of this thread)

The miniclient log (related to mplayer is)

Sat 8/22 18:31:06.708 stdout:MPlayer dev-SVN-rUNKNOWN-4.8 (C) 2000-2007 MPlayer Team
Sat 8/22 18:31:06.708 stdout:CPU: AMD FX(tm)-8350 Eight-Core Processor            (Family: 21, Model: 2, Stepping: 0)
Sat 8/22 18:31:06.708 stdout:CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Sat 8/22 18:31:06.708 stdout:Compiled with runtime CPU detection.
Sat 8/22 18:31:06.709 Waiting for MPlayer to finish loading
Sat 8/22 18:31:06.711 stdout:
Sat 8/22 18:31:06.711 stdout:Playing stv://vagrant-ubuntu-trusty-64//var/media/videos/small.mp4.
Sat 8/22 18:31:06.711 stderr:DEBUG - active_file=0 circFileSize=0
Sat 8/22 18:31:06.716 stderr:CACHE THREAD STARTING
Sat 8/22 18:31:06.766 stdout:FAILURE 237 err=2 newfd=3
Sat 8/22 18:31:06.766 stdout:
Sat 8/22 18:31:06.767 stdout:ISO: File Type Major Brand: ISO/IEC 14496-1 (MPEG-4 system) v2
Sat 8/22 18:31:06.777 stdout:Quicktime/MOV file format detected.
Sat 8/22 18:31:06.818 stderr:
Sat 8/22 18:31:06.818 stderr:
Sat 8/22 18:31:06.818 stderr:MPlayer interrupted by signal 11 in module: video_read_properties
Sat 8/22 18:31:06.819 stdout:ID_VIDEO_ID=0
Sat 8/22 18:31:06.819 stdout:ID_AUDIO_ID=1
Sat 8/22 18:31:06.819 stdout:VIDEO:  [avc1]  560x320  24bpp  30.000 fps    0.0 kbps ( 0.0 kbyte/s)
Sat 8/22 18:31:06.819 stderr:- MPlayer crashed by bad usage of CPU/FPU/RAM.
Sat 8/22 18:31:06.819 stderr:  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
Sat 8/22 18:31:06.819 stderr:  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
Sat 8/22 18:31:06.819 stdout:ID_SIGNAL=11
Sat 8/22 18:31:06.819 stderr:- MPlayer crashed. This shouldn't happen.
Sat 8/22 18:31:06.819 stderr:  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
Sat 8/22 18:31:06.820 stderr:  gcc version. If you think it's MPlayer's fault, please read
Sat 8/22 18:31:06.820 stderr:  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
Sat 8/22 18:31:06.820 stderr:  won't help unless you provide this information when reporting a possible bug.
Sat 8/22 18:31:06.868 stderr:CACHE THREAD ENDING
Sat 8/22 18:31:06.869 stdout consumer has closed
Sat 8/22 18:31:06.869 stderr consumer has closed
Sat 8/22 18:31:16.709 Done waiting for MPlayer to finish loading

I know the mplayer code is quite old, and maybe it's not 64bit compatible in the current state. Unfortunately, figuring out what has changed in order to move to a newer mplayer is beyond my scope, so I'll have to admit failure here, and just say that I don't think I'm going to get a 64bit miniclient working.


The same video running on my vagrant 32bit box plays fine, so definately something with 64bit mplayer.

[Narflex]

Updating MPlayer to the latest version shouldn't be all that bad actually. The changes we made to its internal code were for bug fixing...and hopefully those have been addressed in the main version of it now. Aside from that, we added some input & output plugins which should be easy to re-integrate into it. There's also some minor dependence on what it prints to stdout, but also shouldn't be hard to deal with if any of that even changed...and the dependencies there are easily found in sage.miniclient.MiniMPlayerPlugin.

[stuckless]

Originally Posted by Narflex

Updating MPlayer to the latest version shouldn't be all that bad actually. The changes we made to its internal code were for bug fixing...and hopefully those have been addressed in the main version of it now. Aside from that, we added some input & output plugins which should be easy to re-integrate into it. There's also some minor dependence on what it prints to stdout, but also shouldn't be hard to deal with if any of that even changed...and the dependencies there are easily found in sage.miniclient.MiniMPlayerPlugin.

Yeah, I took a stab at it... I basically search searched for "stv" and "sagetv" and there were a number of hits. Some of the core structures appear to changed slightly from the release you have to the current release. For example the stream_t (I think) no longers has a size element, etc. If I get some time, I might take another stab at it.

[Narflex]

I was checking on my old workstation to see the last time I did an MPlayer merge and it was on April 4th, 2007. So pulling that one to figure out what all the real diffs are would be a good place to start.

From what I had on that machine, it looked like the diffs weren't that bad (about 190 files, but 90%+ of the ones I looked at were just adding a config.h include or moving its location). If anybody wants me to zip that up and upload it somewhere I'm more than happy to do it...but you can probably just pull the same day down from MPlayer's SVN repo and go with that.

[stuckless]

Originally Posted by Narflex

I was checking on my old workstation to see the last time I did an MPlayer merge and it was on April 4th, 2007. So pulling that one to figure out what all the real diffs are would be a good place to start.

From what I had on that machine, it looked like the diffs weren't that bad (about 190 files, but 90%+ of the ones I looked at were just adding a config.h include or moving its location). If anybody wants me to zip that up and upload it somewhere I'm more than happy to do it...but you can probably just pull the same day down from MPlayer's SVN repo and go with that.

If you post what you have, I can take it, and be sure I'm comparing to the right version

[Narflex]

OK, you can get it from http://download.sagetv.com/mplayer-public.zip

Here's a few notes from when I looked it over (this doesn't reflect all changes)

1. There's rate control changes in the 'ratecontrol' and 'mpegvideo' files that were used for dynamic bitrate adjustment for placeshifting
2. There's EM8622 conditionals in the code...that can all be removed, we'll never build for that platform again (it was the HD100)
3. There's code around handling inputs from SageTV via stdin, this was used to control mplayer from SageTV
4. There's various files that were merged from upstream changes...so certain diffs that seem odd may be due to that.
5. Unicode filename parsing was added in the file source plugin for windows
6. Lots of changes are just relocation of the '#include "config.h"' directive...don't remember why we did that
7. Anything referring to 'eavios' is no longer used at all
8. There's some video output plugins for vo_stv/stvmin/macstv you'd definitely want to keep around (except for the mac one)
9. There's a streaming plugin for stream_sagetv which supports streaming from a SageTV server

Feel free to ask any questions about stuff if you dig into this...or anybody else for that matter. It'd be great to get us working off the current Mplayer & ffmpeg builds again.

[stuckless]

Originally Posted by Narflex

OK, you can get it from http://download.sagetv.com/mplayer-public.zip

Here's a few notes from when I looked it over (this doesn't reflect all changes)

1. There's rate control changes in the 'ratecontrol' and 'mpegvideo' files that were used for dynamic bitrate adjustment for placeshifting
2. There's EM8622 conditionals in the code...that can all be removed, we'll never build for that platform again (it was the HD100)
3. There's code around handling inputs from SageTV via stdin, this was used to control mplayer from SageTV
4. There's various files that were merged from upstream changes...so certain diffs that seem odd may be due to that.
5. Unicode filename parsing was added in the file source plugin for windows
6. Lots of changes are just relocation of the '#include "config.h"' directive...don't remember why we did that
7. Anything referring to 'eavios' is no longer used at all
8. There's some video output plugins for vo_stv/stvmin/macstv you'd definitely want to keep around (except for the mac one)
9. There's a streaming plugin for stream_sagetv which supports streaming from a SageTV server

Feel free to ask any questions about stuff if you dig into this...or anybody else for that matter. It'd be great to get us working off the current Mplayer & ffmpeg builds again.

Thanks, I'll definately take a stab at it... I'll create branch and work in there, and maybe others can checkout the branch, if they want as well.

My first question, which I alluded to earlier, was that doing a quick compile by bringing in stream_sagetv.c is that it won't compile because it's missing some fields in the stream_st stuct. (size and activeFileFlag for sure, but there may be others as well)

https://github.com/google/sagetv/blo.../stream.h#L113

Do you recall if you added those, or where they core to mplayer... since not having them, is going to make it a bit hard to port the sage code ahead, if they were removed

Mplayer is also re-organized as well... they now do a git pull of the current ffmpeg when you configure mplayer, so it's now in it's own ffmpeg dir. The current sagetv version just looks like it plopped ffmpeg into the source tree. I think the diff of what you posted to what is in sagetv now should help alot to sort out the specific changes.

[Narflex]

Originally Posted by stuckless

My first question, which I alluded to earlier, was that doing a quick compile by bringing in stream_sagetv.c is that it won't compile because it's missing some fields in the stream_st stuct. (size and activeFileFlag for sure, but there may be others as well)

https://github.com/google/sagetv/blo.../stream.h#L113

Do you recall if you added those, or where they core to mplayer... since not having them, is going to make it a bit hard to port the sage code ahead, if they were removed

I definitely added those. 'active file' is concept in SageTV, so anything with that type of wording likely came from me (and that is going to be in a few places in mplayer). Same thing for circular files...those wouldn't have been part of any normal standalone player and would only come from our integration.

[sacrament055]

Originally Posted by Narflex

OK, you can get it from http://download.sagetv.com/mplayer-public.zip

Here's a few notes from when I looked it over (this doesn't reflect all changes)

1. There's rate control changes in the 'ratecontrol' and 'mpegvideo' files that were used for dynamic bitrate adjustment for placeshifting
2. There's EM8622 conditionals in the code...that can all be removed, we'll never build for that platform again (it was the HD100)
3. There's code around handling inputs from SageTV via stdin, this was used to control mplayer from SageTV
4. There's various files that were merged from upstream changes...so certain diffs that seem odd may be due to that.
5. Unicode filename parsing was added in the file source plugin for windows
6. Lots of changes are just relocation of the '#include "config.h"' directive...don't remember why we did that
7. Anything referring to 'eavios' is no longer used at all
8. There's some video output plugins for vo_stv/stvmin/macstv you'd definitely want to keep around (except for the mac one)
9. There's a streaming plugin for stream_sagetv which supports streaming from a SageTV server

Feel free to ask any questions about stuff if you dig into this...or anybody else for that matter. It'd be great to get us working off the current Mplayer & ffmpeg builds again.

Does removing number 2 above mean a new build of SageTV would no longer work with HD100's?

[stuckless]

Originally Posted by sacrament055

Does removing number 2 above mean a new build of SageTV would no longer work with HD100's?

No... it just means that we can't build an image to run on hd100, which we can't do anyways. But the HD100 will continue to work with the open source sagetv.

[sacrament055]

Originally Posted by stuckless

No... it just means that we can't build an image to run on hd100, which we can't do anyways. But the HD100 will continue to work with the open source sagetv.

Sounds good, thanks for the reply.

[stuckless]

So, I've spent all weekend upgrading mplayer to the latest build. For linux, it's about 95% done, and it's done enough that I can do some testing.

The irony, is that after all this work, the new mplayer dies EXACTLY where the original MPLAYER dies, with the exact same error message.

After some troubleshooting, the issue appears to be with using the -cache 2048. If I modify the java code to NOT pass the -cache flag, then mplayer 64 bit works fine.

So, my MPLAYER commandline looks like this..

./mplayer -identify -osdlevel 0 -autosync 30 -noconsolecontrols -mc 1 -sid 99 -slave -stream-buffer-size 65536 -vo stv:socket=/tmp/sagevideo4819774973985777979.socket -vc ffmpeg12, -cache-seek-min 0 -framedrop -ao alsa -cache 2024 -nokeepaspect "stv://192.168.1.10//opt/MEDIA/videos/tv/Dark Matter/Season 1/Dark Matter S01E13 Episode Thirteen.mkv"

and by removing -cache 2048, it works ( can even run it from the command line, and if remove -vo option, I can view the video locally).

Jeff, I'm guessing you had issue with -cache before, since in the Java code, I can see a variable disableCache=false, and in every place where you add -cache to the command line, you are checking this variable. So, disabling -cache was pretty easy

I have no idea why the -cache is causing issues, or what the impact of turning it off would do. It obviously works in 32bit, so why it fails in 64 bit is odd. I'll re-check the cache2.c (I think this is where it's being handled... I think)

[Narflex]

Sweet, nice progress! And I don't recall at all why the cache flag is in there unfortunately.

[stuckless]

Originally Posted by Narflex

Sweet, nice progress! And I don't recall at all why the cache flag is in there unfortunately.

Not that I'm ready to commit anything yet, but I was wondering how you'd like this to flow...

Option 1
I was thinking of actually delivering a git patch of my changes as a .patch file, and then in the build process, I was going to git clone the specific version that I used, and then apply my patch, and then do the build, to create the mplayer output. Doing this could allow us to upgrade the mplayer distribution quite easily (maybe).

Option 2
I was thinking I could clone mplayer into the OpenSageTV area, independent of SageTV, and then apply the SageTV changes into that fork. SageTV could then use OpenSageTV mplayer fork and git clone it during buid time to rebuild the mplayer pieces. In this way, people can fork the mplayer part, independent of SageTV and fix bugs, etc, and upgrading SageTV would be a matter of rebasing the fork.

Option 3
I an just check in ALL the mplayer sources (as it is done now). If I did this, then I'd probably not replace the existing mplayer tree, but rather create a new tree for the new sources, since I don't think this will be 100% replacment for some time, as well do testing, etc.

Personally, I'm thinking that I'm leaning to #2 since it would provide a clean way to track all the SageTV changes and still allow for cleaner and easier upgrades of the mplayer base over time.

[Narflex]

#2 does sound like the best approach for the reasons you gave.

Of course mplayer also uses FFMPEG inside of it as well...so you may want to go one more level down the rabbit hole with that too. Although more than likely we should just keep the public ffmpeg as part of mplayer and then we can have our own fork for the ffmpeg that SageTV uses on its own (since I don't think any changes in ffmpeg used by mplayer are required for SageTV to work properly, although I could be wrong about that).

[stuckless]

Originally Posted by Narflex

#2 does sound like the best approach for the reasons you gave.

Of course mplayer also uses FFMPEG inside of it as well...so you may want to go one more level down the rabbit hole with that too. Although more than likely we should just keep the public ffmpeg as part of mplayer and then we can have our own fork for the ffmpeg that SageTV uses on its own (since I don't think any changes in ffmpeg used by mplayer are required for SageTV to work properly, although I could be wrong about that).

Yeah, basically, mplayer actually does a git clone of ffmpeg during the ./configure phase, which is interesting. ie, mplayer doesn't bundle ffmpeg anymore, they just clone it, and compile it. I haven't tackled the ffmpeg changes, yet, so not 100% sure what your changes are.

[JREkiwi]

Originally Posted by Narflex

(since I don't think any changes in ffmpeg used by mplayer are required for SageTV to work properly, although I could be wrong about that).

Did you do you own change to get LATM AAC audio working? or did the timing of the FFMPEG patch coincide with the last build?

John

[Narflex]

Originally Posted by JREkiwi

Did you do you own change to get LATM AAC audio working? or did the timing of the FFMPEG patch coincide with the last build?

John

I do not recall.

[stuckless]

I've uploaded 4 version of mplayer to the Open SageTV github site.

There 2 repositories
mplayer-sagetv9os (mplayer, as it was delivered in the SageTV 9 Open source release)
mplayer-sagetv (newer mplayer)

Each repository has a "master" and "sagetv" branch. So, if you look at hte mplayer-sagetv9os repo, you can compare the changes from the base that Jeff provided, to the changes that Jeff made to get it working with sagetv.

The mplayer-sagetv repo's "master" is a snapshot from today, and the "sagetv" branch, is a set of changes that I've done (form comparing the old releases) and merged into the newer release.

Some notes about the mplayer-sagetv repo (ie, the newest release)

1. Video playback appears to be working, but PAUSE does not work, and I don't know why.
2. NOTHING from ffmpeg has bee updated since ffmpeg is handled differently in the newer releases, and I haven't got that sorted out yet.
3. Windows is likely broken, since I can't compile on windows, and someone will need to port the windows stuff.

Some notes about the 64bit miniclient...

1. the Old mplayer will work in 64bit, but the mplayer client needs to be changed to disable caching.
2. On my machine, the "old" mplayer using 64bit works, but is pixelated. The new mplayer renders beatifully.

Jeff... if you have any thoughts as to why pausing is not working it would be appreciated. (Obviously I missed something ). You can check mplayer.c and command.c to double check stuff... the mplayer.c section where it is parsing and handling commands is slightly different, and my C skills are not what they used to be

I think from here, what I'll do is add a buildmplayer.sh script to the core sagetv repo. This script will git clone (or pull a snapshot) of one of the mplayer "sagetv" builds and build/configure it on the fly. This way the mplayer code doesn't need to be checked in directly into the sagetv core, and it can evolve on it's own.

[wnjj]

Hi Stuckless,

I took a look at the "original" source versus the Sage one and your newest one of mplayer.c

I think I've gotten all of the "Jeff" edits into the pause_loop function. Want to give it a shot?

What's the best way to get it to you?