Code: Select all
Option "RandRRotation" "true" Using mplayer/mencoder with 3d videos
-
mickeyjaw
- Cross Eyed!
- Posts: 131
- Joined: Sun Feb 15, 2009 12:50 pm
Re: Using mplayer/mencoder with 3d videos
OK If you are using the NVIDIA proprietary drivers you need to add to your xorg.conf. This enables rotation, but still not reflection. Apparently reflection works with the Intel drivers though, and I still haven't tried with nv as i had issues getting it to work.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
half-mirrored modes
hi again,
mickeyjaw,
too bad about xrandr not working so well. I'm using an nvidia driver and xrandr by itself tells me "Reflections possible - none" and it doesn't work when I try it so no luck there. On the plus side, I found a way to process things so you can then use -xineramascreen....
Ready, let's go. I wrote this earlier offline:
Half-mirrored modes: a new approach
Hey! good news, well sort of. I've found a way to process 3d videos into half-mirrored modes. The bad news is that it's very slow but at least it works and you can process your existing interlaced (or other) 3d video into a format that should work on Linux systems and maybe Windows too if someone can figure out how to span 2 monitors on Windows with mplayer or maybe some other player. The trick is to use the geq (general equation) function. You can test it with mplayer but to really use it to watch a video, you should process it overnight. geq took some figuring but I made progress and am happy to report that it works fine for me so if you have a 3d setup that is half mirrored, I think you should try this if you want. First just test it with mplayer and any video file you have handy:
(comma's need escaping with a backslash and do not lowercase the capital letters)
*** testing -geq for half-mirroring, (left half mirrored onto right half)
mplayer d:\video.avi -nosound -vf geq=p(X\,Y)*gt(W/2\,X)+p(W-1-X\,Y)*lt(W/2\,X)
Understanding -vf geq:
I'm not sure about what all the functions are that geq has available to it but I'm guessing they are the same as for vrc_eq which includes the following functions from the manpage:
max(a,b),min(a,b) maximum / minimum
gt(a,b) is 1 if a>b, 0 otherwise
lt(a,b) is 1 if a<b, 0 otherwise
eq(a,b) is 1 if a==b, 0 otherwise
sin, cos, tan, sinh, cosh, tanh, exp, log, abs, mod
NOTE: from my tests, it looks like "lt" acutally does less-than-or-equal-to. Write your equations as if that's the case and I think you'll have fewer problems. It turns out that my efforts showed me that gt(W/2,X) is not the same as lt(X,W/2) so use gt for the first half and lt for the second and then they should work better. I guess it could be a programming bug that someone could check the source for since mplayer/mencoder is open-source. Otherwise you could do "gt(...)" for the first half and then (1-gt(...)) for the second half instead of an lt and then it would be a complementary function for sure but I'm happy with the way it's shown here. My mplayer version is 1.0 rc2 from October of 2007 so maybe it's fixed in a newer version by now. Hmmm, maybe I should update but that also might degrade my frame-sequential performance if they did something differently. I'll try it later.
manpage typo missing commas:
One other oddity is in the html version of the manpage where you might find something like this:
checkerboard invert with geq filter:
mplayer -vf geq="128+(p(XY)-128)*(0.5-gt(mod(X/SW128)64))*(0.5-gt(mod(Y/SH128)64))*4"
I realized that many commas got lost in translation from plain text to html. It should look like this with backslashes included too:
mplayer -vf geq=128+(p(X\,Y)-128)*(0.5-gt(mod(X/SW\,128)\,64))*(0.5-gt(mod(Y/SH\,128)\,64))*4
If you try this, you'll see that's not the checkerboard we want for 3d but let's save the 3d-checkerboard format for later.
Understanding the equation:
For clarity, I'll use "newpixel(X,Y)" instead of geq for the equation:
"newpixel(X,Y)=p(X\,Y)*gt(W/2\,X)+p(W-1-X\,Y)*lt(W/2\,X)"
You can see that there are two parts to the right-hand side of the equation. The first part (before the + ) describes the left half of the image and the second part describes the right half. Taking a step backwards you can try these things:
mplayer d:\video.avi -nosound -vf geq=p(X\,Y) --- 1:1 pixel-mapping
mplayer d:\video.avi -nosound -vf geq=p(X\,Y)*gt(W/2\,X) --- left half only
mplayer d:\video.avi -nosound -vf geq=p(X\,Y)*lt(W/2\,X) --- right half only
mplayer d:\video.avi -nosound -vf geq=p(W-1-X\,Y)*lt(W/2\,X) --- mirrored left on right
geq knows that W is for the video's width and H is for it's height so do not replace these variables with numbers because there are some complications depending on video color format like YUV-4:2:0.
Hopefully you see that gt and lt are used above as complementary 0 and 1 functions to zero-out one half of each video frame and insert pixel values using the appropriate p(x,y) function. Now let's try it for real on an interlaced 3d file although you can still use an ordinary 2d file at this point.
*** testing interlaced 3d to L/R-R-mirrored
mplayer d:\video.avi -nosound -vf ilpack,fil=d,scale,geq=p(X\,Y)*gt(W/2\,X)+p(1.5*W-1-X\,Y)*lt(W/2\,X)
The only thing that has changed from the above equations is the second p(x,y):
p(W-1-X\,Y) became p(1.5*W-1-X\,Y) since we have mirrored the full width of the video instead of only the left half of the video. When making your own equations, this is the tricky part. Just test your ideas with mplayer and tweak your equations from there. Remember that X,Y starts at 0,0 and ends at W-1,H-1. So for the first half of each video frame, you want pixels from 0 to (W/2-1) and not from 0 to W/2 because that wou
ld be 1 pixel over half. In other words, for an 800 pixel wide image, you want pixels 0 - 399 and W/2 is 400. Beyond that, you may have noticed that I don't use an eq function and in my opinion it's not really needed. If you disagree, experiment and see. Actually, I started out using "lt" on both sides but settled on this equation because it gave the best results. If you try out different equations, you will see what I mean. There's a vertical stripe on the edges or the middle of the frame that shows up and it has something to do with the color subsampling of some video formats.
testing with mencoder and -endpos:
If the mplayer test looks good to you, then do a real conversion using mencoder. It should be included with your mplayer installation. If not, look for a new installation that does include it. I suggest 10 seconds or possibly 30 or 60 seconds to get an idea of how long the entire conversion would take. Use -endpos for your new video's duration in seconds.
*** converting interlaced 3d to L/R-R-mirrored (10 sec test)
mencoder d:\video.avi -o d:\newvideo.avi -endpos 10 -oac copy -vf ilpack,fil=d,scale,geq=p(X\,Y)*gt(W/2\,X)+p(1.5*W-1-X\,Y)*lt(W/2\,X) -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
then just do mplayer d:\newvideo.avi to play it. See the manpage for more deatails on using mencoder. Basically you should specify at least three things:
-oac (output audio codec)
-ovc (output video codec)
-o (output filename)
I like a vbitrate of 5000 but others may think it's overkill especially if you use other options to get better quality. Also, I suggest not rescaling this half-height video during encoding since interlaced 3d is half-height-per-eye source and you don't really gain by rescaling during the encode. Just rescale during the playback and it should be fine.
Estimating conversion time:
During the encode, you can read the output text and it should tell you how many fps are being converted. On my athlon-xp-1800, I get about 2.5 fps so that means that with a 30fps source, that's about 12 times slower meaning that each hour of original video will take 12 hours to convert. Got it? Otherwise, convert 1 minute and time how long it takes and multiply that by the number of minutes in the original video.
Size issues: using -ss and -endpos to break up large videos
OK, so if you're happy with that new video, then go ahead and convert the whole thing but with vbitrate=5000, your newfile is going to get big. I believe you get about 1.2 GB per half-hour of original video and that wouldn't be a problem except that the .avi container format is limited to 2GB so one option is to convert your video into parts. I suggest about 45 minutes per file and using -fixed-vo to play multiple files in series. For converting into parts, you can use -chapter #-# (1-1 for only chapter 1) or else use -ss 0 -endpos 2700 for the first 45 minutes, -ss 2700 -endpos 2700 for the next 45 min, -ss 5400 -endpos 2700 and so on. OK, most modern users will want one file but I'll leave it to others to talk details about that. In general, other options include trying to shrink them with lower bitrates and other formats and settings but I mention this method because it will even work on windows98 although we still need someone to solve the dual-monitor playback problem under windows. As mentioned in a previous post, under Linux, you can use "-xineramascreen 1,2 -fstype none -fs" in order to span two displays.
Playing multiple files with the -fixed-vo option:
If you try to play multiple video files with one mplayer command without the -fixed-vo option, mplayer will close the current window and open a new window for each new file and it looks annoying. Just use -fixed-vo like this:
*** playing multiple files without restarting new windows/mplayers:
mplayer -fixed-vo d:\part1.avi d:\part2.avi d:\part3.avi
or of course: mplayer -fixed-vo d:\part*.avi
--- Other mirroring setups
Over/Under with Over-view mirrored vertically (flipped):
I assume that most people with half-mirror setups have either L/R with the right view mirrored or O/U with the top view flipped. The L/R case was given above so here's the O/U-O-flipped equation:
*** converting interlaced 3d to O/U-O-flipped (10 second test)
mencoder d:\video.avi -o d:\newvideo.avi -endpos 10 -oac copy
-vf ilpack,il=d,scale,geq=p(X\,H/2-1-Y)*gt(H/2\,Y)+p(X\,Y)*lt(H/2\,Y)
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
Note that you need to use H/2-1-Y instead of H/2-Y in the first part of the equation because otherwise you lose a line of resolution and you only have 240 per eye so you better keep every one you can.
Ask for help if you need something different for your setup and can't seem to get it yourself. OK, here's one more in case you have O/U monitors that are setup in software as L/R:
*** converting interlaced 3d to L/R-R-flipped (10 sec test)
mencoder d:\video.avi -o d:\newvideo.avi -endpos 10 -oac copy
-vf ilpack,fil=d,scale,geq=p(X\,Y)*gt(W/2\,X)+p(X\,H-1-Y)*lt(W/2\,X)
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
Next: 3d-checkerboard format:
mickeyjaw,
too bad about xrandr not working so well. I'm using an nvidia driver and xrandr by itself tells me "Reflections possible - none" and it doesn't work when I try it so no luck there. On the plus side, I found a way to process things so you can then use -xineramascreen....
Ready, let's go. I wrote this earlier offline:
Half-mirrored modes: a new approach
Hey! good news, well sort of. I've found a way to process 3d videos into half-mirrored modes. The bad news is that it's very slow but at least it works and you can process your existing interlaced (or other) 3d video into a format that should work on Linux systems and maybe Windows too if someone can figure out how to span 2 monitors on Windows with mplayer or maybe some other player. The trick is to use the geq (general equation) function. You can test it with mplayer but to really use it to watch a video, you should process it overnight. geq took some figuring but I made progress and am happy to report that it works fine for me so if you have a 3d setup that is half mirrored, I think you should try this if you want. First just test it with mplayer and any video file you have handy:
(comma's need escaping with a backslash and do not lowercase the capital letters)
*** testing -geq for half-mirroring, (left half mirrored onto right half)
mplayer d:\video.avi -nosound -vf geq=p(X\,Y)*gt(W/2\,X)+p(W-1-X\,Y)*lt(W/2\,X)
Understanding -vf geq:
I'm not sure about what all the functions are that geq has available to it but I'm guessing they are the same as for vrc_eq which includes the following functions from the manpage:
max(a,b),min(a,b) maximum / minimum
gt(a,b) is 1 if a>b, 0 otherwise
lt(a,b) is 1 if a<b, 0 otherwise
eq(a,b) is 1 if a==b, 0 otherwise
sin, cos, tan, sinh, cosh, tanh, exp, log, abs, mod
NOTE: from my tests, it looks like "lt" acutally does less-than-or-equal-to. Write your equations as if that's the case and I think you'll have fewer problems. It turns out that my efforts showed me that gt(W/2,X) is not the same as lt(X,W/2) so use gt for the first half and lt for the second and then they should work better. I guess it could be a programming bug that someone could check the source for since mplayer/mencoder is open-source. Otherwise you could do "gt(...)" for the first half and then (1-gt(...)) for the second half instead of an lt and then it would be a complementary function for sure but I'm happy with the way it's shown here. My mplayer version is 1.0 rc2 from October of 2007 so maybe it's fixed in a newer version by now. Hmmm, maybe I should update but that also might degrade my frame-sequential performance if they did something differently. I'll try it later.
manpage typo missing commas:
One other oddity is in the html version of the manpage where you might find something like this:
checkerboard invert with geq filter:
mplayer -vf geq="128+(p(XY)-128)*(0.5-gt(mod(X/SW128)64))*(0.5-gt(mod(Y/SH128)64))*4"
I realized that many commas got lost in translation from plain text to html. It should look like this with backslashes included too:
mplayer -vf geq=128+(p(X\,Y)-128)*(0.5-gt(mod(X/SW\,128)\,64))*(0.5-gt(mod(Y/SH\,128)\,64))*4
If you try this, you'll see that's not the checkerboard we want for 3d but let's save the 3d-checkerboard format for later.
Understanding the equation:
For clarity, I'll use "newpixel(X,Y)" instead of geq for the equation:
"newpixel(X,Y)=p(X\,Y)*gt(W/2\,X)+p(W-1-X\,Y)*lt(W/2\,X)"
You can see that there are two parts to the right-hand side of the equation. The first part (before the + ) describes the left half of the image and the second part describes the right half. Taking a step backwards you can try these things:
mplayer d:\video.avi -nosound -vf geq=p(X\,Y) --- 1:1 pixel-mapping
mplayer d:\video.avi -nosound -vf geq=p(X\,Y)*gt(W/2\,X) --- left half only
mplayer d:\video.avi -nosound -vf geq=p(X\,Y)*lt(W/2\,X) --- right half only
mplayer d:\video.avi -nosound -vf geq=p(W-1-X\,Y)*lt(W/2\,X) --- mirrored left on right
geq knows that W is for the video's width and H is for it's height so do not replace these variables with numbers because there are some complications depending on video color format like YUV-4:2:0.
Hopefully you see that gt and lt are used above as complementary 0 and 1 functions to zero-out one half of each video frame and insert pixel values using the appropriate p(x,y) function. Now let's try it for real on an interlaced 3d file although you can still use an ordinary 2d file at this point.
*** testing interlaced 3d to L/R-R-mirrored
mplayer d:\video.avi -nosound -vf ilpack,fil=d,scale,geq=p(X\,Y)*gt(W/2\,X)+p(1.5*W-1-X\,Y)*lt(W/2\,X)
The only thing that has changed from the above equations is the second p(x,y):
p(W-1-X\,Y) became p(1.5*W-1-X\,Y) since we have mirrored the full width of the video instead of only the left half of the video. When making your own equations, this is the tricky part. Just test your ideas with mplayer and tweak your equations from there. Remember that X,Y starts at 0,0 and ends at W-1,H-1. So for the first half of each video frame, you want pixels from 0 to (W/2-1) and not from 0 to W/2 because that wou
ld be 1 pixel over half. In other words, for an 800 pixel wide image, you want pixels 0 - 399 and W/2 is 400. Beyond that, you may have noticed that I don't use an eq function and in my opinion it's not really needed. If you disagree, experiment and see. Actually, I started out using "lt" on both sides but settled on this equation because it gave the best results. If you try out different equations, you will see what I mean. There's a vertical stripe on the edges or the middle of the frame that shows up and it has something to do with the color subsampling of some video formats.
testing with mencoder and -endpos:
If the mplayer test looks good to you, then do a real conversion using mencoder. It should be included with your mplayer installation. If not, look for a new installation that does include it. I suggest 10 seconds or possibly 30 or 60 seconds to get an idea of how long the entire conversion would take. Use -endpos for your new video's duration in seconds.
*** converting interlaced 3d to L/R-R-mirrored (10 sec test)
mencoder d:\video.avi -o d:\newvideo.avi -endpos 10 -oac copy -vf ilpack,fil=d,scale,geq=p(X\,Y)*gt(W/2\,X)+p(1.5*W-1-X\,Y)*lt(W/2\,X) -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
then just do mplayer d:\newvideo.avi to play it. See the manpage for more deatails on using mencoder. Basically you should specify at least three things:
-oac (output audio codec)
-ovc (output video codec)
-o (output filename)
I like a vbitrate of 5000 but others may think it's overkill especially if you use other options to get better quality. Also, I suggest not rescaling this half-height video during encoding since interlaced 3d is half-height-per-eye source and you don't really gain by rescaling during the encode. Just rescale during the playback and it should be fine.
Estimating conversion time:
During the encode, you can read the output text and it should tell you how many fps are being converted. On my athlon-xp-1800, I get about 2.5 fps so that means that with a 30fps source, that's about 12 times slower meaning that each hour of original video will take 12 hours to convert. Got it? Otherwise, convert 1 minute and time how long it takes and multiply that by the number of minutes in the original video.
Size issues: using -ss and -endpos to break up large videos
OK, so if you're happy with that new video, then go ahead and convert the whole thing but with vbitrate=5000, your newfile is going to get big. I believe you get about 1.2 GB per half-hour of original video and that wouldn't be a problem except that the .avi container format is limited to 2GB so one option is to convert your video into parts. I suggest about 45 minutes per file and using -fixed-vo to play multiple files in series. For converting into parts, you can use -chapter #-# (1-1 for only chapter 1) or else use -ss 0 -endpos 2700 for the first 45 minutes, -ss 2700 -endpos 2700 for the next 45 min, -ss 5400 -endpos 2700 and so on. OK, most modern users will want one file but I'll leave it to others to talk details about that. In general, other options include trying to shrink them with lower bitrates and other formats and settings but I mention this method because it will even work on windows98 although we still need someone to solve the dual-monitor playback problem under windows. As mentioned in a previous post, under Linux, you can use "-xineramascreen 1,2 -fstype none -fs" in order to span two displays.
Playing multiple files with the -fixed-vo option:
If you try to play multiple video files with one mplayer command without the -fixed-vo option, mplayer will close the current window and open a new window for each new file and it looks annoying. Just use -fixed-vo like this:
*** playing multiple files without restarting new windows/mplayers:
mplayer -fixed-vo d:\part1.avi d:\part2.avi d:\part3.avi
or of course: mplayer -fixed-vo d:\part*.avi
--- Other mirroring setups
Over/Under with Over-view mirrored vertically (flipped):
I assume that most people with half-mirror setups have either L/R with the right view mirrored or O/U with the top view flipped. The L/R case was given above so here's the O/U-O-flipped equation:
*** converting interlaced 3d to O/U-O-flipped (10 second test)
mencoder d:\video.avi -o d:\newvideo.avi -endpos 10 -oac copy
-vf ilpack,il=d,scale,geq=p(X\,H/2-1-Y)*gt(H/2\,Y)+p(X\,Y)*lt(H/2\,Y)
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
Note that you need to use H/2-1-Y instead of H/2-Y in the first part of the equation because otherwise you lose a line of resolution and you only have 240 per eye so you better keep every one you can.
Ask for help if you need something different for your setup and can't seem to get it yourself. OK, here's one more in case you have O/U monitors that are setup in software as L/R:
*** converting interlaced 3d to L/R-R-flipped (10 sec test)
mencoder d:\video.avi -o d:\newvideo.avi -endpos 10 -oac copy
-vf ilpack,fil=d,scale,geq=p(X\,Y)*gt(W/2\,X)+p(X\,H-1-Y)*lt(W/2\,X)
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
Next: 3d-checkerboard format:
Last edited by iondrive on Mon Nov 02, 2009 5:20 am, edited 1 time in total.
System specs:
OS: 32-bit WinXP Home SP3
CPU: 3.2GHz Athlon 64 X2 6400
RAM: 800MHz 4GB dual channel mode
Video: geForce 8800GTS PCI-e, 640MB ram, driver 196.21
OS: 32-bit WinXP Home SP3
CPU: 3.2GHz Athlon 64 X2 6400
RAM: 800MHz 4GB dual channel mode
Video: geForce 8800GTS PCI-e, 640MB ram, driver 196.21
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
converting to checkerboard 3d formats
Alright, so here we are again tackling the 3d-checkerboard (CB) format but this time we've got it. It's just even more slow than the half-mirrored modes and it should be 60fps at either 1280x720 or 1920x1080, left-eye-view first (top left corner pixel). Most formats seem to be left eye first by the way. The 60fps describes the video going to the TV which then creates two frames from every one so that the TV outputs 120fps to your face, 60fps per eye. Anyway here it is:
*** interlaced to LR/RL to 1920x1080 60fps checkerboard (10 second test)
mencoder d:\interlaced.avi -o d:\checkerboard.avi -ofps 60 -endpos 10 -oac copy
-vf ilpack,il=d,scale,rotate=1,ilpack,il=d,scale,rotate=2,
geq=p(X\,Y)*gt(W/2\,X)+p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y)+p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y),
rotate=1,ilpack,il=i,scale=1080
1,rotate=2,ilpack,il=i,scale=::1
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
-ofps defines the output fps. Don't forget the "o" in -ofps or else you will be redefining the input fps which is normally not needed.
OK, that command is big and hairy so let's just look at the parts of -vf.
1) ilpack,il=d,scale,rotate=1,ilpack,il=d,scale,rotate=2
This is the deinterlace/rotate/deinterlace/unrotate routine that gets you from interlaced to a 2x2 format of LL/RR.
2) geq=p(X\,Y)*gt(W/2\,X)+p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y)+p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y)
changes LL/RR to LR/RL by swapping Quadrant 1 with Quadrant 4.
2a) p(X\,Y)*gt(W/2\,X) --- this gets you the unchanged left half of L/R
2b) p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y) --- puts Q4 image data into Q1
2c) p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y) --- puts Q1 image data into Q4
3) rotate=1,ilpack,il=i,scale=10801,rotate=2,ilpack,il=i,scale=::1
Converts from LR/RL to CB format with a rescale via a rotate/interlace/scale/unrotate/interlace routine. Note that since the image is sideways during the scale, I use 1080:1920 instead of 1920:1080 so don't think it's a mistake. If you want 1280x720, then use 720:1280. Also don't put a normal scale right after the geq since it gave me bad results for some reason. Also don't forget the :1 after the scale for preserving interlacing integrity and you need it.
Or you could do the process in two steps which is what I prefer:
2x2, LR/RL: an intermediary format
I recommend this conversion in two steps. One to get to a 2x2 format of LR/RL, and the second step to rescale and get to your CB format.
*** interlaced to 60fps LR/RL
mencoder d:interlaced.avi -o d:\LR-RL-60.avi -ofps 60 -endpos 10 -oac copy -vf ilpack,il=d,scale,rotate=1,ilpack,il=d,scale,rotate=2,
geq=p(X\,Y)*gt(W/2\,X)+p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y)+p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y)
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
OK, so that gets you to LR/RL at 60fps and original resolution. You can check your file and see how it looks, then proceed with the next step. Note I convert to 60fps now instead of later just because I'm more confident that there will be no ghosting due to interpolated frames in case the encoder does that. That being said, it's probably OK to go to 60 fps during the next step instead if you want to since the encoder probably won't interpolate new frames and just duplicate whole frames instead in order to achieve the new framerate.
*** LR/RL to checkerboard with rescale to 1920x1080
mencoder d:\LR-RL-60.avi -o d:\CB.avi -ofps 60 -oac copy
-vf rotate=1,ilpack,il=i,scale=10801,rotate=2,ilpack,il=i,scale=::1
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
This way if there are problems with the final video, you might be able to spot where it is more easily. Like before, use the scale in the place it's shown or you may have problems... ghosting if you scale later and an odd colored stripe on a screen edge if you put it before.
Playback:
From what I've read, you need your desktop in the same res as the 3d input your tv takes, then play your video in fullscreen and enable 3d mode on your tv and it should work. One possible hitch is if your video driver decides to smooth out the image for you and cause massive ghosting so in that case use -vo directx:noaccel or, for linux users, -vo xv:noaccel or -vo x11. I may have to ask someone to test this for me if I give them a CB file I've created. It should play in other players too.
Final comments:
I've heard AVISYNTH is good for converting to CB so it's probably much faster and maybe I'll learn it someday but maybe not. Also, converting to jpegs and using netpbm tools would also be faster but that technique has some potential A/V sync loss problems. As far as it goes, I kind of like this method since it's pretty simple once you have the equations and have the time to do an overnight conversion. Still, I might post about how to do this with netpbm tools but I'll leave that for next year. I think that's it for now.
Whew:
Am I done yet? It wasn't supposed to be this long and I still have to talk about frame-sequential. I have been working on it but it takes alot of time to test different systems. It looks like OS/card/driver matter but I've had great success on my XP system with an FX-5200 card. I just want to do some more testing on another system before I post.
see ya,
--- iondrive ---
*** interlaced to LR/RL to 1920x1080 60fps checkerboard (10 second test)
mencoder d:\interlaced.avi -o d:\checkerboard.avi -ofps 60 -endpos 10 -oac copy
-vf ilpack,il=d,scale,rotate=1,ilpack,il=d,scale,rotate=2,
geq=p(X\,Y)*gt(W/2\,X)+p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y)+p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y),
rotate=1,ilpack,il=i,scale=1080
1,rotate=2,ilpack,il=i,scale=::1 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
-ofps defines the output fps. Don't forget the "o" in -ofps or else you will be redefining the input fps which is normally not needed.
OK, that command is big and hairy so let's just look at the parts of -vf.
1) ilpack,il=d,scale,rotate=1,ilpack,il=d,scale,rotate=2
This is the deinterlace/rotate/deinterlace/unrotate routine that gets you from interlaced to a 2x2 format of LL/RR.
2) geq=p(X\,Y)*gt(W/2\,X)+p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y)+p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y)
changes LL/RR to LR/RL by swapping Quadrant 1 with Quadrant 4.
2a) p(X\,Y)*gt(W/2\,X) --- this gets you the unchanged left half of L/R
2b) p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y) --- puts Q4 image data into Q1
2c) p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y) --- puts Q1 image data into Q4
3) rotate=1,ilpack,il=i,scale=1080
1,rotate=2,ilpack,il=i,scale=::1Converts from LR/RL to CB format with a rescale via a rotate/interlace/scale/unrotate/interlace routine. Note that since the image is sideways during the scale, I use 1080:1920 instead of 1920:1080 so don't think it's a mistake. If you want 1280x720, then use 720:1280. Also don't put a normal scale right after the geq since it gave me bad results for some reason. Also don't forget the :1 after the scale for preserving interlacing integrity and you need it.
Or you could do the process in two steps which is what I prefer:
2x2, LR/RL: an intermediary format
I recommend this conversion in two steps. One to get to a 2x2 format of LR/RL, and the second step to rescale and get to your CB format.
*** interlaced to 60fps LR/RL
mencoder d:interlaced.avi -o d:\LR-RL-60.avi -ofps 60 -endpos 10 -oac copy -vf ilpack,il=d,scale,rotate=1,ilpack,il=d,scale,rotate=2,
geq=p(X\,Y)*gt(W/2\,X)+p(X\,Y+H/2)*lt(W/2\,X)*gt(H/2\,Y)+p(X\,Y-H/2)*lt(W/2\,X)*lt(H/2\,Y)
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
OK, so that gets you to LR/RL at 60fps and original resolution. You can check your file and see how it looks, then proceed with the next step. Note I convert to 60fps now instead of later just because I'm more confident that there will be no ghosting due to interpolated frames in case the encoder does that. That being said, it's probably OK to go to 60 fps during the next step instead if you want to since the encoder probably won't interpolate new frames and just duplicate whole frames instead in order to achieve the new framerate.
*** LR/RL to checkerboard with rescale to 1920x1080
mencoder d:\LR-RL-60.avi -o d:\CB.avi -ofps 60 -oac copy
-vf rotate=1,ilpack,il=i,scale=1080
1,rotate=2,ilpack,il=i,scale=::1 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=5000
This way if there are problems with the final video, you might be able to spot where it is more easily. Like before, use the scale in the place it's shown or you may have problems... ghosting if you scale later and an odd colored stripe on a screen edge if you put it before.
Playback:
From what I've read, you need your desktop in the same res as the 3d input your tv takes, then play your video in fullscreen and enable 3d mode on your tv and it should work. One possible hitch is if your video driver decides to smooth out the image for you and cause massive ghosting so in that case use -vo directx:noaccel or, for linux users, -vo xv:noaccel or -vo x11. I may have to ask someone to test this for me if I give them a CB file I've created. It should play in other players too.
Final comments:
I've heard AVISYNTH is good for converting to CB so it's probably much faster and maybe I'll learn it someday but maybe not. Also, converting to jpegs and using netpbm tools would also be faster but that technique has some potential A/V sync loss problems. As far as it goes, I kind of like this method since it's pretty simple once you have the equations and have the time to do an overnight conversion. Still, I might post about how to do this with netpbm tools but I'll leave that for next year. I think that's it for now.
Whew:
Am I done yet? It wasn't supposed to be this long and I still have to talk about frame-sequential. I have been working on it but it takes alot of time to test different systems. It looks like OS/card/driver matter but I've had great success on my XP system with an FX-5200 card. I just want to do some more testing on another system before I post.
see ya,
--- iondrive ---
System specs:
OS: 32-bit WinXP Home SP3
CPU: 3.2GHz Athlon 64 X2 6400
RAM: 800MHz 4GB dual channel mode
Video: geForce 8800GTS PCI-e, 640MB ram, driver 196.21
OS: 32-bit WinXP Home SP3
CPU: 3.2GHz Athlon 64 X2 6400
RAM: 800MHz 4GB dual channel mode
Video: geForce 8800GTS PCI-e, 640MB ram, driver 196.21
-
Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Using mplayer/mencoder with 3d videos
Hi guys, nice stuff, now I can convert all my 3D movies to field sequential format. That's the only format I can read under Linux with my Simuleyes VR glasses. Thanks !
I've made some modifications to MPlayer to display the White Line Code needed to activate my glasses. All the modifications are made in the libvo/vo_x11.c file, here they are :
After static int int_pause; write :
In the flip_page function, write this code between the two existing lines :
After case VOCTRL_PAUSE: write :
Notes :
I've made some modifications to MPlayer to display the White Line Code needed to activate my glasses. All the modifications are made in the libvo/vo_x11.c file, here they are :
After static int int_pause; write :
Code: Select all
static int vo_x11_stereo = 0;Code: Select all
XSetForeground(mDisplay, vo_gc, BlackPixel(mDisplay, mScreen));
XFillRectangle(mDisplay, vo_window, vo_gc, 0, vo_dheight - 2, vo_dwidth, 2);
XSetForeground(mDisplay, vo_gc, WhitePixel(mDisplay, mScreen));
if (vo_x11_stereo)
{
XFillRectangle(mDisplay, vo_window, vo_gc, 0, vo_dheight - 2, (vo_dwidth * 3) / 4, 1);
XFillRectangle(mDisplay, vo_window, vo_gc, 0, vo_dheight - 1, (vo_dwidth * 1) / 4, 1);
}
else
{
XFillRectangle(mDisplay, vo_window, vo_gc, 0, vo_dheight - 2, (vo_dwidth * 1) / 4, 1);
XFillRectangle(mDisplay, vo_window, vo_gc, 0, vo_dheight - 1, (vo_dwidth * 3) / 4, 1);
}Code: Select all
vo_x11_stereo = !vo_x11_stereo;- - you can replace WhitePixel(mDisplay, mScreen) by 0x0000FF if you want Blue Line Code instead of White Line Code ;
- if the stereo isn't right, just make a pause with P or the spacebar to inverse the effect.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
YouTube 3d video uploading info
Fredz, your new nickname is awesome-Fredz 
Great stuff. I'm very glad you anticipated my request for BLC encoding.
Thanks.
(I had to rewrite these next few posts since they got too crazy. Anywayz...)
Now for more mencoder fun... s3d videos for YouTube
I'm still a YouTube newbie, but I've learned some things in my first week and made some s3d videos that you can see. My YouTube name is iondrive3d since iondrive was already taken. For CRT users with line-blanking shutterglass mode, I suggest a screen res of 1024x768 and hitting that double-arrow on the bottom-right of your YouTube video window to make it bigger (480p). That size seems good. Don't choose fullscreen viewing mode because that doesn't work right yet for interlaced users. Anyway, you can see my first video and slideshow here:
Title: Marvel Ultimate Alliance in s3d
http://www.youtube.com/watch?v=q97Qwd5S38g" onclick="window.open(this.href);return false;
MUA s3d slideshow, Mandarin level
http://www.youtube.com/watch?v=VV9wbCxM800" onclick="window.open(this.href);return false;
UPDATE!!! YouTube has changed some of the tags you can use so that the below info may be out of date. See these threads for info on tags as of early 2011:
http://www.mtbs3d.com/phpBB/viewtopic.p ... ags#p57374" onclick="window.open(this.href);return false;
http://www.mtbs3d.com/phpBB/viewtopic.p ... ags#p57596" onclick="window.open(this.href);return false;
http://www.google.com/support/youtube/b ... wer=157640" onclick="window.open(this.href);return false;
Basically, from the YouTube page:
YouTube 3d Video Basics:
Firstly, some basics for posting your videos on YouTube. What you need to do is get your video into O/U or R/L format and you can post it on YouTube using special YouTube-3d tags that tell your browser to display the video in some user-selected format. Viewing format choices are currently various anaglyph, interlaced, side-by-side LR or RL for free-viewing, some mirrored modes, and I've heard that iZ3D monitor owners can view in fullscreen. I will be using the 1280x720 standard HD res since 1920x1080 is too big and the maximum filesize YouTube allows is 2GB and that's also the max filesize for .avi files. YouTube is going to convert your video themselves so don't expect the quality of your upload to be the same as the quality of the final video you see on your YouTube page. Yeah, it can be disappointing but I think they do it to try and save some bandwidth. Later I'll tell you how to use mplayer/mencoder to make 3d video slideshows from your screenshots and then later from 3d photos in separate files (L,R photo-pairs). It's pretty cool.
R/L or O/U?
YouTube is currently setup to assume that your upload is in R/L format but you can use others including mirrored formats too. Anyways, I've wondered which is better to upload, R/L or O/U and so I've done some tests using 800x1200 O/U (800x600x2) source and packing the 3d video into the standard HD res of 1280x720. You can see the results of these uploads on YouTube and decide for yourself which is better of if they're equivalent. Looking closely at the text in the video, I think that R/L is better unless you're viewing in interlaced mode in which case I think O/U is slightly better. I'm choosing to upload in R/L unless I record videos in single-screen interlaced, in which case I'll use O/U since I can only record half-vertical res per eye when using interlaced mode. I think the key is how much your video is compressed. In the case of sticking 800x600 views into 1280x360 res for the O/U format, vertical res loss is 40%. In the case of sticking 800x600 views into 640x720 res for the R/L format, horizontal res loss is 20% so it's better mathematically anyway. Stretching a dimension doesn't really make you lose image data like compression does so I'm ignoring that for the sake of simplicity. It's a judgment call anyway. If your target audience is going to be using interlaced, you should probably use the O/U format. Also, results may be different if your original source is different from 800x600x2 like mine was. For example, if you're recording in widescreen format, O/U might be better for that too although you probably should do your own tests for that. I suggest 10 second tests with text in them. Anyway, here's some links to my tests so you don't have to do your own (for 800x600x2 source). You can open them in two separate tabs and scroll them up/down so that the two video windows are in the exact same physical location on your display. Pause both in the beginning and go back and forth between them to spot the difference easier. You can do this in monoscopic modes and then later in interlaced modes if that applies to you.
MUA Over/Under 3d format quality test
http://www.youtube.com/watch?v=sKrGGXxHyr8" onclick="window.open(this.href);return false;
MUA Left/Right 3d format quality test
http://www.youtube.com/watch?v=4i7TUm_OEK4" onclick="window.open(this.href);return false;
Uploading to YouTube:
If you're a complete newcomer, just go to the YouTube site, create an account if you don't already have one, hit the upload button and browse to your s3d video to select it. Then fill out some info for your video, save settings and let it finish uploading. Rename the Title something better than your filename and include appropriate tags and then some key YouTube3D tags (yt3d). There are 2 or 4 tags that we might want to use:
For LR side-by-side 4:3 aspect videos:
OLD: yt3d:enable=true yt3d:aspect=4:3 yt3d:left=0_0_0.5_1 yt3d:right=0.5_0_1_1
NEW: yt3d:enable=LR
Note: make your video LR so that each image is 50% width of it's original full-framed size. If the original source videos were 4:3 for each view, then your side-by-side video should have an overall aspect of 4:3 and you should not need to specify aspect. RL format is discouraged but you could use yt3d:enable=RL.
For L-on-R above/below videos with left-view on top and 16:9 aspect videos:
OLD: yt3d:enable=true yt3d:aspect=16:9 yt3d:left=0_0_1_0.5 yt3d:right=0_0.5_1_1
NEW: yt3d:enable=LonR
Note: make your video L-on-R so that each image is 50% height of it's original full-framed size. Side-by-side video should then have an overall aspect of 16:9 and you should not need to specify aspect.
For R-on-L, use the same as above but use yt3d:enable=RonL
aspect: (out of date info)
Note that this uses a ":" instead of a "/" and you can experiment with different numbers. I've noticed that some people needed to use 8:9 in order for their videos to look right. Just stretch/squeeze your videos to completely fill the 1280x720 frame and I don't think you'll need to use odd ratios, just 4:3 or 16:9. Also, don't accidentally invert them and use 3:4 or 9:16. If you have trouble remembering 16:9 but you can remember 4:3, then just square both 4 and 3 and you'll get 16:9. That's how I originally used to remember it.
right and left: (out of date info)
The numbers following right and left describe rectangles inside our video images. The top left is (0,0) and the bottom right is (1,1) so...
0_0 are x,y coordinates for the top left of the video,
1_0.5 are x,y coordinates for the middle of the far right edge,
0_0.5 are x,y coordinates for the middle of the far left edge, and
1_1 are x,y coordinates for the bottom right corner of the video.
and so 0_0_1_0.5 describes the top half of your video and 0_0.5_1_1 describes the bottom half. "left" and "right" define which eye that rectangle is intended for. Adjust as needed.
Mirrored formats:
Note that these rectangles are defined from the upper left corner to the lower right corner. If you define the rectangle in the opposite order from lower right to upper left, then your image for that eye will be upside-down. If you define it from top right to bottom left, that view will be mirrored horizontally and finally, if you define it from bottom left to top right, that view will be mirrored vertically. I don't think you'll need that info but you might if your screenshots have one view mirrored since mencoder has trouble mirroring one half of a video. This is a good way around it.
next, slideshow generation with mplayer/mencoder.
--- iondrive ---
Great stuff. I'm very glad you anticipated my request for BLC encoding.
Thanks.
(I had to rewrite these next few posts since they got too crazy. Anywayz...)
Now for more mencoder fun... s3d videos for YouTube
I'm still a YouTube newbie, but I've learned some things in my first week and made some s3d videos that you can see. My YouTube name is iondrive3d since iondrive was already taken. For CRT users with line-blanking shutterglass mode, I suggest a screen res of 1024x768 and hitting that double-arrow on the bottom-right of your YouTube video window to make it bigger (480p). That size seems good. Don't choose fullscreen viewing mode because that doesn't work right yet for interlaced users. Anyway, you can see my first video and slideshow here:
Title: Marvel Ultimate Alliance in s3d
http://www.youtube.com/watch?v=q97Qwd5S38g" onclick="window.open(this.href);return false;
MUA s3d slideshow, Mandarin level
http://www.youtube.com/watch?v=VV9wbCxM800" onclick="window.open(this.href);return false;
UPDATE!!! YouTube has changed some of the tags you can use so that the below info may be out of date. See these threads for info on tags as of early 2011:
http://www.mtbs3d.com/phpBB/viewtopic.p ... ags#p57374" onclick="window.open(this.href);return false;
http://www.mtbs3d.com/phpBB/viewtopic.p ... ags#p57596" onclick="window.open(this.href);return false;
http://www.google.com/support/youtube/b ... wer=157640" onclick="window.open(this.href);return false;
Basically, from the YouTube page:
I will update the following posts now (April, 2011).If your video format is:
Side by side "half" or "squashed":
Add the tag yt3d:enable=LR to your video
If the video displays incorrectly or has a poor 3D effect, try changing it to yt3d:enable=RL
Top-bottom "half" or "squashed":
Add the tag yt3d:enable=LonR to your video
If the video displays incorrectly or has a poor 3D effect, try changing it to yt3d:enable=RonL
YouTube 3d Video Basics:
Firstly, some basics for posting your videos on YouTube. What you need to do is get your video into O/U or R/L format and you can post it on YouTube using special YouTube-3d tags that tell your browser to display the video in some user-selected format. Viewing format choices are currently various anaglyph, interlaced, side-by-side LR or RL for free-viewing, some mirrored modes, and I've heard that iZ3D monitor owners can view in fullscreen. I will be using the 1280x720 standard HD res since 1920x1080 is too big and the maximum filesize YouTube allows is 2GB and that's also the max filesize for .avi files. YouTube is going to convert your video themselves so don't expect the quality of your upload to be the same as the quality of the final video you see on your YouTube page. Yeah, it can be disappointing but I think they do it to try and save some bandwidth. Later I'll tell you how to use mplayer/mencoder to make 3d video slideshows from your screenshots and then later from 3d photos in separate files (L,R photo-pairs). It's pretty cool.
R/L or O/U?
YouTube is currently setup to assume that your upload is in R/L format but you can use others including mirrored formats too. Anyways, I've wondered which is better to upload, R/L or O/U and so I've done some tests using 800x1200 O/U (800x600x2) source and packing the 3d video into the standard HD res of 1280x720. You can see the results of these uploads on YouTube and decide for yourself which is better of if they're equivalent. Looking closely at the text in the video, I think that R/L is better unless you're viewing in interlaced mode in which case I think O/U is slightly better. I'm choosing to upload in R/L unless I record videos in single-screen interlaced, in which case I'll use O/U since I can only record half-vertical res per eye when using interlaced mode. I think the key is how much your video is compressed. In the case of sticking 800x600 views into 1280x360 res for the O/U format, vertical res loss is 40%. In the case of sticking 800x600 views into 640x720 res for the R/L format, horizontal res loss is 20% so it's better mathematically anyway. Stretching a dimension doesn't really make you lose image data like compression does so I'm ignoring that for the sake of simplicity. It's a judgment call anyway. If your target audience is going to be using interlaced, you should probably use the O/U format. Also, results may be different if your original source is different from 800x600x2 like mine was. For example, if you're recording in widescreen format, O/U might be better for that too although you probably should do your own tests for that. I suggest 10 second tests with text in them. Anyway, here's some links to my tests so you don't have to do your own (for 800x600x2 source). You can open them in two separate tabs and scroll them up/down so that the two video windows are in the exact same physical location on your display. Pause both in the beginning and go back and forth between them to spot the difference easier. You can do this in monoscopic modes and then later in interlaced modes if that applies to you.
MUA Over/Under 3d format quality test
http://www.youtube.com/watch?v=sKrGGXxHyr8" onclick="window.open(this.href);return false;
MUA Left/Right 3d format quality test
http://www.youtube.com/watch?v=4i7TUm_OEK4" onclick="window.open(this.href);return false;
Uploading to YouTube:
If you're a complete newcomer, just go to the YouTube site, create an account if you don't already have one, hit the upload button and browse to your s3d video to select it. Then fill out some info for your video, save settings and let it finish uploading. Rename the Title something better than your filename and include appropriate tags and then some key YouTube3D tags (yt3d). There are 2 or 4 tags that we might want to use:
For LR side-by-side 4:3 aspect videos:
OLD: yt3d:enable=true yt3d:aspect=4:3 yt3d:left=0_0_0.5_1 yt3d:right=0.5_0_1_1
NEW: yt3d:enable=LR
Note: make your video LR so that each image is 50% width of it's original full-framed size. If the original source videos were 4:3 for each view, then your side-by-side video should have an overall aspect of 4:3 and you should not need to specify aspect. RL format is discouraged but you could use yt3d:enable=RL.
For L-on-R above/below videos with left-view on top and 16:9 aspect videos:
OLD: yt3d:enable=true yt3d:aspect=16:9 yt3d:left=0_0_1_0.5 yt3d:right=0_0.5_1_1
NEW: yt3d:enable=LonR
Note: make your video L-on-R so that each image is 50% height of it's original full-framed size. Side-by-side video should then have an overall aspect of 16:9 and you should not need to specify aspect.
For R-on-L, use the same as above but use yt3d:enable=RonL
aspect: (out of date info)
Note that this uses a ":" instead of a "/" and you can experiment with different numbers. I've noticed that some people needed to use 8:9 in order for their videos to look right. Just stretch/squeeze your videos to completely fill the 1280x720 frame and I don't think you'll need to use odd ratios, just 4:3 or 16:9. Also, don't accidentally invert them and use 3:4 or 9:16. If you have trouble remembering 16:9 but you can remember 4:3, then just square both 4 and 3 and you'll get 16:9. That's how I originally used to remember it.
right and left: (out of date info)
The numbers following right and left describe rectangles inside our video images. The top left is (0,0) and the bottom right is (1,1) so...
0_0 are x,y coordinates for the top left of the video,
1_0.5 are x,y coordinates for the middle of the far right edge,
0_0.5 are x,y coordinates for the middle of the far left edge, and
1_1 are x,y coordinates for the bottom right corner of the video.
and so 0_0_1_0.5 describes the top half of your video and 0_0.5_1_1 describes the bottom half. "left" and "right" define which eye that rectangle is intended for. Adjust as needed.
Mirrored formats:
Note that these rectangles are defined from the upper left corner to the lower right corner. If you define the rectangle in the opposite order from lower right to upper left, then your image for that eye will be upside-down. If you define it from top right to bottom left, that view will be mirrored horizontally and finally, if you define it from bottom left to top right, that view will be mirrored vertically. I don't think you'll need that info but you might if your screenshots have one view mirrored since mencoder has trouble mirroring one half of a video. This is a good way around it.
next, slideshow generation with mplayer/mencoder.
--- iondrive ---
Last edited by iondrive on Tue Apr 26, 2011 3:35 am, edited 8 times in total.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
3D video-slideshows for YouTube: general info
making 3D video-slideshows for YouTube: general info
YouTube tag info has changed since I first wrote this. I have updated the following as of April, 2011.
Introduction:
OK, so you've got some 3d screenshots you want to share with the world and you're wondering if you can use mencoder to make a video slideshow out of them and post it on YouTube. Well stop wondering. You can. I could talk about anaglyph 3d slideshow-making but if I just explain how to do this, then you'll be able to figure out anaglyph slideshows on your own. Anaglyph screenshots are generally jpg files and you can just treat them as 2d image files which means you can make 2d image slideshows the same way. The only thing to watch out for is making sure that gamma/contrast/brightness/saturation are like you want them and to make sure that your images all have the same aspect ratio like 4:3 or 16:9 and the same goes for 3d screenshots. For now, lets assume all your screenshots have the same aspect but not necessarily the same resolution. Read about using "eq2" in the documentation if you want to tweak brightness/color and use "dsize" or "-aspect" for aspect ratio control.
File selection and management issues: to list.txt or not to list.txt
So it turns out that mencoder can make videos from individual image files if they are in the form of jpeg, png, tga, or sgi. So if you wanted to, you could put together an entire movie from individual frames, but besides that, you could make a nice little video slideshow from your screenshots too. Just choose which images you want to include in your slideshow and drag copies of them to your mplayer folder. Alternatively, put your copies in a temp folder by themselves and put that folder inside your mplayer folder as a new subdirectory. Then use ..\mencoder instead of mencoder to make your new avi file. We will be using an option that looks something like this: "mf://*.jps" and you should be able to use "mf://path/*.jps" but that was buggy for me on winXP so I recommend you avoid it and use one of the other two ideas previously mentioned (files in mplayer dir, or subdir with ../mencoder command). One more option that does work is to use a text file with one-file-per-line format and use it like this: "mf://@list.txt". As an example, list.txt can be like this:
This works and shows that blank lines are ignored even at the beginning or end. It also shows that relative and absolute paths work correctly and that you can use "/" or "\" interchangeably and they both work the same. Nice. You can generate a bare list.txt file in the image folder with the command "dir *.jpg /b >list.txt". If you want paths included in the filenames, then include a "/s" like this: "dir *.jpg /b /s >list.txt". Linux users don't need help with something similar.
Putting your pics in the right order:
The real advantage of a list like this is that it's easy to get your slideshow to have your pics in the order that you want them to be in. Just cut and paste the lines where they belong. What would be even easier is if you had another viewing program like sView let you organize a kind of playlist graphically and then output a text file with all the filenames in the right order. sView currently can't do this even though it does have a slideshow function although it just goes through the files in a chosen folder. If you know of a 2d slideshow program that can do this, please post about it. Otherwise you need to change filenames so that they are alpha-numerically in the order you want when you use *.jps or *.whatever. I prefer to copy all my desired screenshots into the mplayer directory and change the names. It's pretty simple although you still may need an image browser like sView to show you the actual image content so you know what they are.
Separate sections based on source images:
At this point, I'll split this into separate sections since it gets too big otherwise. The parts will be based on the source images from which mencoder will make the 3d video slideshow from:
Section 1: R/L jps screenshots from iZ3D or nVidia
Section 2: LO/UR jpg screenshots from TriDef
Section 3: real-life left and right photos in separate files
Section 4: interlaced png screenshots from nVidia or other
UPDATE: choosing 3d output display mode for YouTube videos
YouTube used to have a different menu system for choosing which type of 3d display you had and I think it was better before. Anyway, now it uses cookies and you need to set that from a special YouTube page whereas you used to be able to select any output display mode right from the page you're watching. Now to set your display mode, you have to go to a special YouTube page: http://www.youtube.com/select_3d_mode" onclick="window.open(this.href);return false; and click your choice there. Then your browser is supposed to remember the setting for all future 3d YouTube videos because of a cookie left on your computer. If your browser is not set to accept and remember that, then you will need to reset your selected 3d output mode when you next start your browser. For Firefox, you should look under Tools/Options/Privacy/History and change the text box to "Use custom settings for history", check the box "accept cookies from sites" and then click "Exceptions..." Enter http://www.youtube.com" onclick="window.open(this.href);return false; in the text box, click "Allow" and "Close" and you should be good to go. I suggest you bookmark/favorite the select_3d_mode web page if you sometimes use more than one mode like me Thanks to cybereality for the point in the right direction.
YouTube tag info has changed since I first wrote this. I have updated the following as of April, 2011.
Introduction:
OK, so you've got some 3d screenshots you want to share with the world and you're wondering if you can use mencoder to make a video slideshow out of them and post it on YouTube. Well stop wondering. You can. I could talk about anaglyph 3d slideshow-making but if I just explain how to do this, then you'll be able to figure out anaglyph slideshows on your own. Anaglyph screenshots are generally jpg files and you can just treat them as 2d image files which means you can make 2d image slideshows the same way. The only thing to watch out for is making sure that gamma/contrast/brightness/saturation are like you want them and to make sure that your images all have the same aspect ratio like 4:3 or 16:9 and the same goes for 3d screenshots. For now, lets assume all your screenshots have the same aspect but not necessarily the same resolution. Read about using "eq2" in the documentation if you want to tweak brightness/color and use "dsize" or "-aspect" for aspect ratio control.
File selection and management issues: to list.txt or not to list.txt
So it turns out that mencoder can make videos from individual image files if they are in the form of jpeg, png, tga, or sgi. So if you wanted to, you could put together an entire movie from individual frames, but besides that, you could make a nice little video slideshow from your screenshots too. Just choose which images you want to include in your slideshow and drag copies of them to your mplayer folder. Alternatively, put your copies in a temp folder by themselves and put that folder inside your mplayer folder as a new subdirectory. Then use ..\mencoder instead of mencoder to make your new avi file. We will be using an option that looks something like this: "mf://*.jps" and you should be able to use "mf://path/*.jps" but that was buggy for me on winXP so I recommend you avoid it and use one of the other two ideas previously mentioned (files in mplayer dir, or subdir with ../mencoder command). One more option that does work is to use a text file with one-file-per-line format and use it like this: "mf://@list.txt". As an example, list.txt can be like this:
Code: Select all
xblades031.jpg
xblades032.jpg
xblades033.jpg
xblades034.jpg
C:/NVSTEREO.IMG\xblades041.jpg
C:\NVSTEREO.IMG/xblades042.jpg
../xblades027.jpg
Putting your pics in the right order:
The real advantage of a list like this is that it's easy to get your slideshow to have your pics in the order that you want them to be in. Just cut and paste the lines where they belong. What would be even easier is if you had another viewing program like sView let you organize a kind of playlist graphically and then output a text file with all the filenames in the right order. sView currently can't do this even though it does have a slideshow function although it just goes through the files in a chosen folder. If you know of a 2d slideshow program that can do this, please post about it. Otherwise you need to change filenames so that they are alpha-numerically in the order you want when you use *.jps or *.whatever. I prefer to copy all my desired screenshots into the mplayer directory and change the names. It's pretty simple although you still may need an image browser like sView to show you the actual image content so you know what they are.
Separate sections based on source images:
At this point, I'll split this into separate sections since it gets too big otherwise. The parts will be based on the source images from which mencoder will make the 3d video slideshow from:
Section 1: R/L jps screenshots from iZ3D or nVidia
Section 2: LO/UR jpg screenshots from TriDef
Section 3: real-life left and right photos in separate files
Section 4: interlaced png screenshots from nVidia or other
UPDATE: choosing 3d output display mode for YouTube videos
YouTube used to have a different menu system for choosing which type of 3d display you had and I think it was better before. Anyway, now it uses cookies and you need to set that from a special YouTube page whereas you used to be able to select any output display mode right from the page you're watching. Now to set your display mode, you have to go to a special YouTube page: http://www.youtube.com/select_3d_mode" onclick="window.open(this.href);return false; and click your choice there. Then your browser is supposed to remember the setting for all future 3d YouTube videos because of a cookie left on your computer. If your browser is not set to accept and remember that, then you will need to reset your selected 3d output mode when you next start your browser. For Firefox, you should look under Tools/Options/Privacy/History and change the text box to "Use custom settings for history", check the box "accept cookies from sites" and then click "Exceptions..." Enter http://www.youtube.com" onclick="window.open(this.href);return false; in the text box, click "Allow" and "Close" and you should be good to go. I suggest you bookmark/favorite the select_3d_mode web page if you sometimes use more than one mode like me
Thanks to cybereality for the point in the right direction.
Last edited by iondrive on Tue Apr 26, 2011 3:39 am, edited 10 times in total.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
YouTube 3d slideshows from iZ3D or nVidia screenshots
making s3D video-slideshows for YouTube: specific examples
Section 1, using iZ3D or nVidia jps screenshots
iZ3D or nVidia R/L jps screenshot source files:
These files are standardized in the sense that they are full-framed (non-squeezed) side-by-side with right-view first (on left or crosseyed). All images should have equal aspect ratios. Adjust the YouTube aspect tag as needed.
*** iZ3D/nVidia RL jps 16:9 aspect 3d screenshots to YouTube LR 3d video slideshow:
mencoder "mf://*.jps" -mf type=jpg -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720,ilpack,fil=i,il=s,fil=d,scale,dsize=16/9
YouTube tags: yt3d:enable=LR
Detailed Explanation:
"mf://*.jps" -mf type=jpg:
I think "mf" stands for "multiple-file" but that's just a guess. Anyway, regarding "-mf type=jpg", you don't need this if your files have file-extensions of .jpg, .png, .tga, or .sgi, but since we're using .jps, we specifically inform mencoder to treat these jps files as jpg files or else it won't recognize them and the program will error out. We got kind of lucky in this regard. Lucky jps is a common screenshot format and lucky that mencoder has a "type" option to help recognize it. The documentation says to use "type=jpeg" but I tried "type=jpg" instead and it works so that's what I decided to use in order to keep it easier for you. Both "jpg" and "jpeg" work the same.
-o temp.avi:
That's your output file but you already knew that, right? mencoder will overwrite it without asking you if you run the command again so make sure to change the name to something significant once you're happy with it. The input video file in this case is just a list of image files. Not really a video file but just a group of image files being treated as if it were a video file. OK, sorry to over-explain things but I want things to be clear even to newcomers.
-nosound:
This makes a video with no sound. You can use mencoder to add sound later if you want. Maybe music for your slideshow or your voice explaining and commenting on what's going on. Maybe I'll talk about that someday but it's very low on my to-do list. Maybe someone else will cover it for me. That would be great. YouTube complains a little when you upload a video without sound saying that it doesn't recognize the audio format but it still plays fine without audio so don't worry about it. I guess another option would be to have an audio stream in there but have it just be silence. I think it can be good to have a silent slideshow and I think it works fine.
-ovc x264 -x264encopts crf=20:
This refers to the h264 video compression codec and I've heard it was good so I decided to try and use it. It seems fine but I've done no hard comparisons. The "crf" number determines image quality and can range from 1 to 50 with 50 being the worst quality with the smallest file size. I did some tests and I'm happy with crf=30 for videos but if you have some images with alot of blue sky in them, then it can look blocky so that's why I bumped up the quality to crf=20. You can do your own tests if you want smaller filesizes at the expense of quality. Here's some links to my tests so you can judge something for yourself:
MUA Left/Right 3d format quality test (same video as before, h264 crf=20)
http://www.youtube.com/watch?v=4i7TUm_OEK4" onclick="window.open(this.href);return false;
Uploaded Filesize: 7 MB
MUA Left/Right h264 crf=30 test
http://www.youtube.com/watch?v=KhLG2AgcsbE" onclick="window.open(this.href);return false;
Uploaded Filesize: 3 MB
-fps 0.25:
Since individual files have no framerate and I want 4 seconds per image, I set the fps to 1/4 frames per second (-fps 0.25). So decide how many seconds/image you want and invert that number and put the decimal value after -fps. The manpage says to use "-mf fps=30" or whatever but you can just forget that and use the more generic "-fps 30" since it overrides the "-mf fps=30". This defines the input fps. This framerate gets saved in the file so that when you play the temp.avi file, it will play at that rate automatically. In this case the video file consists of only 10 frames so you can't get much more compact than that. The video will last 40 seconds since it's 4 seconds per frame. You can see this in the text output after you run this command. It says a bunch of stuff including "40.000 secs 10 frames" or whatever is appropriate for your case.
-ofps 30: This fixes 2 quirks...
OK, so "-fps 0.25" describes the fps for the input video but what about the output video framerate? That's what this defines. If you left it out, then it would default to equal the input fps of 0.25 but that would give you some quirks during playback. One quirk is that the mplayer window and program would be very unresponsive. It's as if it doesn't seem to notice when you try to pause it or drag the window. This is probably because the input routine occurs between frames and since you're playing each frame for 4 seconds, you only have a split second to have your input get noticed. The other quirk is that the last image is only on the screen for a split second and in order to fix that, you could add an extra image file on the end of your list, but -ofps fixes this too so you don't have to do that. I think 30 fps is a good fps for uploading to YouTube. Of course, change it to whatever you want.
-ofps 30: filesize concerns...
It may sound like a file with 30 fps has alot more frames than a file with only 0.25 fps and it does but wait. The duration of your output video is determined by two factors of your input video and they are: the number of input frames and the input fps defined by -fps. In this case the duration is still 40 seconds (in this case 10 frames at 0.25 fps or 4 sec/frame) but the output will be 1200 frames (still 40 seconds but at 30 fps). I've done some tests and the result is that "-ofps 30" makes my temp.avi filesize only 4% bigger. Yes, that's right. It turns out that the two filesizes are very close because the encoding recognizes that the frames are exactly the same and it doesn't really re-encode them but instead, just makes a note that says "repeat previous frame". That's how a video file with 120 times more frames as another, is only 4% bigger when it should be 120 times bigger. Neat huh?
scale=1280:720
This is a good size for your s3d videos to be uploaded to YouTube so that's why I'm using this resolution. If you want a different res for some other reason, then just change the numbers as desired. As is common in image/video processing, there are trade-offs between filesize and image quality. I find this res to be good enough for YouTube. Also, I only have a "slow" DSL modem and I would like to keep the filesize down so that's why I'm not using higher res's. Keep the aspect of the new video equal to the aspect of one of the unsqueezed image-views.
dsize=16/9:
In the past we've used dsize="x-res:y-res" but I've learned that dsize can also take a ratio and then when you play the video, that's the ratio you will see. It's a nice feature but in this case I've decided to use 16/9 which is the ratio of 1280:720 if you use square pixels. I've chosen this because I like to see the image data as it is... squashed or squeezed so that I can get some idea of where image quality is lost. If you want to see normal proportions when you play your temp.avi, you can use 8/3 for 4:3 aspect screenshots and 32/9 for 16:9 widescreen images. You see I've doubled the bottom number that represents height since the frames are 2 images stacked O/U. For a RL side-by-side format you would use either 8/3 or 32/9. Note that this is a "/" and not a ":" here when dsize is used in this way.
RL to R-on-L: you probably don't want these.
Going from RL to R-on-L can be easy or difficult depending on your situation. I'll leave out the complicated bits and just say, if your screenshots all have the same res, you should be fine with these.
*** iZ3D/nVidia RL jps 3d 16:9 aspect screenshots to YouTube R-on-L 3d video slideshow:
mencoder "mf://*.jps" -mf type=jpg -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf ilpack,fil=i,il=d,scale=1280:720,dsize=16/9
OLD: YouTube tags: yt3d:enable=true yt3d:aspect=16:9 yt3d:right=0_0_1_0.5 yt3d:left=0_0.5_1_1
NEW: YouTube tags: yt3d:enable=RonL
and finally,
*** iZ3D/nVidia RL jps 3d 16:9 aspect screenshots to YouTube L-on-R 3d video slideshow:
mencoder "mf://*.jps" -mf type=jpg -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf ilpack,fil=i,il=s,il=d,scale=1280:720,dsize=16/9
OLD: YouTube tags: yt3d:enable=true yt3d:aspect=16:9 yt3d:left=0_0_1_0.5 yt3d:right=0_0.5_1_1
NEW: YouTube tag: yt3d:enable=LonR
Section 1, using iZ3D or nVidia jps screenshots
iZ3D or nVidia R/L jps screenshot source files:
These files are standardized in the sense that they are full-framed (non-squeezed) side-by-side with right-view first (on left or crosseyed). All images should have equal aspect ratios. Adjust the YouTube aspect tag as needed.
*** iZ3D/nVidia RL jps 16:9 aspect 3d screenshots to YouTube LR 3d video slideshow:
mencoder "mf://*.jps" -mf type=jpg -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720,ilpack,fil=i,il=s,fil=d,scale,dsize=16/9
YouTube tags: yt3d:enable=LR
Detailed Explanation:
"mf://*.jps" -mf type=jpg:
I think "mf" stands for "multiple-file" but that's just a guess. Anyway, regarding "-mf type=jpg", you don't need this if your files have file-extensions of .jpg, .png, .tga, or .sgi, but since we're using .jps, we specifically inform mencoder to treat these jps files as jpg files or else it won't recognize them and the program will error out. We got kind of lucky in this regard. Lucky jps is a common screenshot format and lucky that mencoder has a "type" option to help recognize it. The documentation says to use "type=jpeg" but I tried "type=jpg" instead and it works so that's what I decided to use in order to keep it easier for you. Both "jpg" and "jpeg" work the same.
-o temp.avi:
That's your output file but you already knew that, right? mencoder will overwrite it without asking you if you run the command again so make sure to change the name to something significant once you're happy with it. The input video file in this case is just a list of image files. Not really a video file but just a group of image files being treated as if it were a video file. OK, sorry to over-explain things but I want things to be clear even to newcomers.
-nosound:
This makes a video with no sound. You can use mencoder to add sound later if you want. Maybe music for your slideshow or your voice explaining and commenting on what's going on. Maybe I'll talk about that someday but it's very low on my to-do list. Maybe someone else will cover it for me. That would be great. YouTube complains a little when you upload a video without sound saying that it doesn't recognize the audio format but it still plays fine without audio so don't worry about it. I guess another option would be to have an audio stream in there but have it just be silence. I think it can be good to have a silent slideshow and I think it works fine.
-ovc x264 -x264encopts crf=20:
This refers to the h264 video compression codec and I've heard it was good so I decided to try and use it. It seems fine but I've done no hard comparisons. The "crf" number determines image quality and can range from 1 to 50 with 50 being the worst quality with the smallest file size. I did some tests and I'm happy with crf=30 for videos but if you have some images with alot of blue sky in them, then it can look blocky so that's why I bumped up the quality to crf=20. You can do your own tests if you want smaller filesizes at the expense of quality. Here's some links to my tests so you can judge something for yourself:
MUA Left/Right 3d format quality test (same video as before, h264 crf=20)
http://www.youtube.com/watch?v=4i7TUm_OEK4" onclick="window.open(this.href);return false;
Uploaded Filesize: 7 MB
MUA Left/Right h264 crf=30 test
http://www.youtube.com/watch?v=KhLG2AgcsbE" onclick="window.open(this.href);return false;
Uploaded Filesize: 3 MB
-fps 0.25:
Since individual files have no framerate and I want 4 seconds per image, I set the fps to 1/4 frames per second (-fps 0.25). So decide how many seconds/image you want and invert that number and put the decimal value after -fps. The manpage says to use "-mf fps=30" or whatever but you can just forget that and use the more generic "-fps 30" since it overrides the "-mf fps=30". This defines the input fps. This framerate gets saved in the file so that when you play the temp.avi file, it will play at that rate automatically. In this case the video file consists of only 10 frames so you can't get much more compact than that. The video will last 40 seconds since it's 4 seconds per frame. You can see this in the text output after you run this command. It says a bunch of stuff including "40.000 secs 10 frames" or whatever is appropriate for your case.
-ofps 30: This fixes 2 quirks...
OK, so "-fps 0.25" describes the fps for the input video but what about the output video framerate? That's what this defines. If you left it out, then it would default to equal the input fps of 0.25 but that would give you some quirks during playback. One quirk is that the mplayer window and program would be very unresponsive. It's as if it doesn't seem to notice when you try to pause it or drag the window. This is probably because the input routine occurs between frames and since you're playing each frame for 4 seconds, you only have a split second to have your input get noticed. The other quirk is that the last image is only on the screen for a split second and in order to fix that, you could add an extra image file on the end of your list, but -ofps fixes this too so you don't have to do that. I think 30 fps is a good fps for uploading to YouTube. Of course, change it to whatever you want.
-ofps 30: filesize concerns...
It may sound like a file with 30 fps has alot more frames than a file with only 0.25 fps and it does but wait. The duration of your output video is determined by two factors of your input video and they are: the number of input frames and the input fps defined by -fps. In this case the duration is still 40 seconds (in this case 10 frames at 0.25 fps or 4 sec/frame) but the output will be 1200 frames (still 40 seconds but at 30 fps). I've done some tests and the result is that "-ofps 30" makes my temp.avi filesize only 4% bigger. Yes, that's right. It turns out that the two filesizes are very close because the encoding recognizes that the frames are exactly the same and it doesn't really re-encode them but instead, just makes a note that says "repeat previous frame". That's how a video file with 120 times more frames as another, is only 4% bigger when it should be 120 times bigger. Neat huh?
scale=1280:720
This is a good size for your s3d videos to be uploaded to YouTube so that's why I'm using this resolution. If you want a different res for some other reason, then just change the numbers as desired. As is common in image/video processing, there are trade-offs between filesize and image quality. I find this res to be good enough for YouTube. Also, I only have a "slow" DSL modem and I would like to keep the filesize down so that's why I'm not using higher res's. Keep the aspect of the new video equal to the aspect of one of the unsqueezed image-views.
dsize=16/9:
In the past we've used dsize="x-res:y-res" but I've learned that dsize can also take a ratio and then when you play the video, that's the ratio you will see. It's a nice feature but in this case I've decided to use 16/9 which is the ratio of 1280:720 if you use square pixels. I've chosen this because I like to see the image data as it is... squashed or squeezed so that I can get some idea of where image quality is lost. If you want to see normal proportions when you play your temp.avi, you can use 8/3 for 4:3 aspect screenshots and 32/9 for 16:9 widescreen images. You see I've doubled the bottom number that represents height since the frames are 2 images stacked O/U. For a RL side-by-side format you would use either 8/3 or 32/9. Note that this is a "/" and not a ":" here when dsize is used in this way.
RL to R-on-L: you probably don't want these.
Going from RL to R-on-L can be easy or difficult depending on your situation. I'll leave out the complicated bits and just say, if your screenshots all have the same res, you should be fine with these.
*** iZ3D/nVidia RL jps 3d 16:9 aspect screenshots to YouTube R-on-L 3d video slideshow:
mencoder "mf://*.jps" -mf type=jpg -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf ilpack,fil=i,il=d,scale=1280:720,dsize=16/9
OLD: YouTube tags: yt3d:enable=true yt3d:aspect=16:9 yt3d:right=0_0_1_0.5 yt3d:left=0_0.5_1_1
NEW: YouTube tags: yt3d:enable=RonL
and finally,
*** iZ3D/nVidia RL jps 3d 16:9 aspect screenshots to YouTube L-on-R 3d video slideshow:
mencoder "mf://*.jps" -mf type=jpg -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf ilpack,fil=i,il=s,il=d,scale=1280:720,dsize=16/9
OLD: YouTube tags: yt3d:enable=true yt3d:aspect=16:9 yt3d:left=0_0_1_0.5 yt3d:right=0_0.5_1_1
NEW: YouTube tag: yt3d:enable=LonR
Last edited by iondrive on Tue Apr 26, 2011 3:55 am, edited 3 times in total.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
YouTube 3d slideshows from TriDef screenshots
(To followers of this thread, I had to do some rewriting, take a second look at the last 3 posts)
Making s3D video-slideshows for YouTube: specific examples
Section 2, using TriDef O/U jpg screenshots
TriDef jpg L-on-R screenshot source files:
These files are standardized in the sense that they are full-framed (non-squashed) Over/Under with left-view first (on top). Otherwise things here are much the same as above so refer to Section 1 for details if needed. As usual, all images should have equal aspect ratios.
*** TriDef L-on-R 3d 16:9 aspect screenshots to L-on-R YouTube 3d video slideshow:
mencoder "mf://*.jpg" -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720,dsize=16/9
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3 yt3d:left=0_0_1_0.5 yt3d:right=0_0.5_1_1
NEW: yt3d:enable=LonR
If you want the right-eye-view on top, just swap the top and bottom with ilpack,il=i,il=s,il=d,scale like this:
*** TriDef L-on-R 16:9 aspect screenshots to video slideshow for YouTube in R-on-L format
mencoder "mf://*.jpg" -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720,ilpack,il=i,il=s,il=d,scale,dsize=16/9
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3 yt3d:right=0_0_1_0.5 yt3d:left=0_0.5_1_1
NEW: yt3d:enable=RonL
And finally L-on-R to LR:
*** 3d TriDef L-on-R 16:9 aspect screenshots to video slideshow for YouTube in LR format
mencoder "mf://*.jpg" -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=640:1440,ilpack,il=i,fil=d,scale=1280:720,dsize=16/9
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3
NEW: yt3d:enable=LR
The first "scale" here is 640x1440 because "fil=d" is going to double the width and halve the height so the final res will be 1280x720 just like we want it. Note "fil=d" is not a rescaling. It is a deinterlacing so it takes all odd lines and puts them on the left and takes all even lines and puts them on the right. Line numbering starts with "1".
Making s3D video-slideshows for YouTube: specific examples
Section 2, using TriDef O/U jpg screenshots
TriDef jpg L-on-R screenshot source files:
These files are standardized in the sense that they are full-framed (non-squashed) Over/Under with left-view first (on top). Otherwise things here are much the same as above so refer to Section 1 for details if needed. As usual, all images should have equal aspect ratios.
*** TriDef L-on-R 3d 16:9 aspect screenshots to L-on-R YouTube 3d video slideshow:
mencoder "mf://*.jpg" -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720,dsize=16/9
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3 yt3d:left=0_0_1_0.5 yt3d:right=0_0.5_1_1
NEW: yt3d:enable=LonR
If you want the right-eye-view on top, just swap the top and bottom with ilpack,il=i,il=s,il=d,scale like this:
*** TriDef L-on-R 16:9 aspect screenshots to video slideshow for YouTube in R-on-L format
mencoder "mf://*.jpg" -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720,ilpack,il=i,il=s,il=d,scale,dsize=16/9
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3 yt3d:right=0_0_1_0.5 yt3d:left=0_0.5_1_1
NEW: yt3d:enable=RonL
And finally L-on-R to LR:
*** 3d TriDef L-on-R 16:9 aspect screenshots to video slideshow for YouTube in LR format
mencoder "mf://*.jpg" -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=640:1440,ilpack,il=i,fil=d,scale=1280:720,dsize=16/9
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3
NEW: yt3d:enable=LR
The first "scale" here is 640x1440 because "fil=d" is going to double the width and halve the height so the final res will be 1280x720 just like we want it. Note "fil=d" is not a rescaling. It is a deinterlacing so it takes all odd lines and puts them on the left and takes all even lines and puts them on the right. Line numbering starts with "1".
Last edited by iondrive on Tue Apr 26, 2011 4:04 am, edited 1 time in total.
-
chinesebob
- One Eyed Hopeful
- Posts: 1
- Joined: Fri Jul 09, 2010 4:47 pm
Re: Using mplayer/mencoder with 3d videos
Wow, these are some great mplayer recipes, thank you. I'm trying to play a side by side 3d mpg as magenta/green anaglyph, with this command I can get the two sides overlayed but, I'm not sure how to adjust the colors for the anaglyph, do you know?
mplayer germany-spain-futbol-3d.mpg -autosync 30 -mc 2 -nokeepaspect -vf ilpack,fil=i,scale=1920
1,pp=lb
mplayer germany-spain-futbol-3d.mpg -autosync 30 -mc 2 -nokeepaspect -vf ilpack,fil=i,scale=1920
1,pp=lb-
jduncanator
- One Eyed Hopeful
- Posts: 3
- Joined: Tue Nov 30, 2010 12:10 am
Re: Using mplayer/mencoder with 3d videos
Hi,
I am new to all this but what I was wondering is if it was possible to take two video inputs (Left and Right) and output them as Side-by-Side and Over-Under? This would really help me.
Thanks,
Josh
I am new to all this but what I was wondering is if it was possible to take two video inputs (Left and Right) and output them as Side-by-Side and Over-Under? This would really help me.
Thanks,
Josh
-
Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Using mplayer/mencoder with 3d videos
Unfortunately MPlayer is not able to open two files at the same time for now, you'd have to use something else.
-
mickeyjaw
- Cross Eyed!
- Posts: 131
- Joined: Sun Feb 15, 2009 12:50 pm
Re: Using mplayer/mencoder with 3d videos
jduncanator:
try bino:
http://nongnu.org/bino/
I had a play with it the other day - it looks quite promising and can do what you are looking for. You will need to build ffmpeg and libswscale from SVN first, as no distro i know of has a recent enough version.
Regards,
mickeyjaw
try bino:
http://nongnu.org/bino/
I had a play with it the other day - it looks quite promising and can do what you are looking for. You will need to build ffmpeg and libswscale from SVN first, as no distro i know of has a recent enough version.
Regards,
mickeyjaw
-
jduncanator
- One Eyed Hopeful
- Posts: 3
- Joined: Tue Nov 30, 2010 12:10 am
Re: Using mplayer/mencoder with 3d videos
Hi mickey,mickeyjaw wrote:jduncanator:
try bino:
http://nongnu.org/bino/
I had a play with it the other day - it looks quite promising and can do what you are looking for. You will need to build ffmpeg and libswscale from SVN first, as no distro i know of has a recent enough version.
Regards,
mickeyjaw
Thanks! One question, is this software good enough to encode Full HD videos? The reason I am asking is I work with very high resolution PNGs (ones rendered directly from Sintels render farms. One for each eye of course) and was wondering if it was near lossless? I was also wondering how to go about encoding YouTube videos in 3D from scratch as I am completely new to this and had NO IDEA what you were talking about :O
Thanks,
JD
-
Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Using mplayer/mencoder with 3d videos
You should be able to encode full HD videos in side-by-side or above-below format with mencoder using your PNGs, you'll just need to create side-by-side versions of them before. You can automate that by using ImageMagick in a batch with the append command. It would be very nice to see Sintel in 3D.
-
Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Using mplayer/mencoder with 3d videos
Hum, thinking about it I guess you could also tell Blender to directly render side-by-side or above-and-below PNGs, that would be a more effective solution than converting PNGs afterward.
-
jduncanator
- One Eyed Hopeful
- Posts: 3
- Joined: Tue Nov 30, 2010 12:10 am
Re: Using mplayer/mencoder with 3d videos
Yes I agree but I also don't. To save us time rendering it twice (side-by-side and single images) we were just going to render with single images (one for left one for right) and then we could do whatever we wanted to! ImageMagik is good idea thanks 
-
mickeyjaw
- Cross Eyed!
- Posts: 131
- Joined: Sun Feb 15, 2009 12:50 pm
Re: Using mplayer/mencoder with 3d videos
Sorry, it looks like i misinterpreted your post - the software i referred to is a _player_ not an encoder.
I concur that imagemagik then is probably the way to go in your case since you are already working with a set of still images.
Good to hear that Sintel is getting the stereoscopic treatment - i look forward to seeing the final result!
PS What viewing solution are you using for S3D?
I concur that imagemagik then is probably the way to go in your case since you are already working with a set of still images.
Good to hear that Sintel is getting the stereoscopic treatment - i look forward to seeing the final result!
PS What viewing solution are you using for S3D?
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
new stereo3d filter in mplayer/mencoder source
hi guys!!!
I'm still alive if any of you were wondering what happened to me. I just haven't been reading/posting for a very long time... distractions abound. I don't know if I will get back into the habit of posting more actively but I'll just do a little right now at least.
New stereo3d functions in mplayer source!!! YAY!
This happened late last year but I'm actually not that excited about it since it doesn't really add formats that I could not do before except for easy stereo-to-anaglyph conversion for those times when you want that. Since it's new code, you could have some trouble finding a compiled version of mplayer/mencoder that has it but I found one for windows at
http://oss.netfarm.it/mplayer-win32.php
and tried it and it worked. The file was for athlons: mplayer-athlon-svn-32848.7z
The code adds a video filter called stereo3d and you use it in your -vf segment as in
mplayer futbol-3d.mpg -vf stereo3d=sbsl:agmh,scale
to go from LR to anaglyph green/magenta-half-color while converting on-the-fly.
This works with mencoder too so you can make 3d anaglyph videos if you want but I would just keep the originals and just convert on-the-fly as needed. My feelings about anaglyph are that it's not too repulsive and it's a good option for printing out a screenshot on paper. Remember to use scale after stereo3d or else mplayer will crash.
Anyway, there's more info in the man-page at
http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt
Once you are there, search for "stereo3d" and that should take you right to it.
NOTE: if you Google mplayer manpage, you can wind up at the Tivo mplayer manpage which is missing alot of functions in the full source so don't freak out if you don't see the options you're looking for. Just go to mplayerhq.hu instead.
Basically the format is stereo3d=input:output format and the possible s3d formats for in/out are:
LR, RL, L/R, R/L, and squashed L/R, R/L.
Output also includes various anaglyph color-sets...
3 kinds of yellow/blue (gray, half-color, and color)
3 kinds of green/magenta (as above)
4 kinds of red/cyan (as above plus dubois)
as well as mono left or right view.
Anaglyph red/cyan dubois?...
I had to try that one and I think it did look the best of all the red/cyans but it might depend on your particular content. The manpage says it is "color optimized with the least squares projection of dubois". Oh, of course. I should have realized that myself.
What's missing from the stereo3d option: half-mirrored modes and checkerboard outputs.
I'm glad this is in the code and there's a chance that this function may do a better job at converting between formats but as I said before, we already could do those conversions so this doesn't add much except for easy anaglyph conversion. What's missing is half-mirrored modes as well as checkerboard outputs. That would have been a more welcome addition to the conversions we already can do. I will for the most part not use this new function since the old approach works with older mplayer versions too. Half-mirrored modes should be easy. Maybe someone will contact the author of that subroutine and suggest it to him/her. Volunteers? I have other things on my mind. Also missing is frame-sequential and field-sequential as well as vertical interlaced. Good thing we can do all those already.
Odd-colored glasses:
If your glasses are colored backwards for some reason, it seems like you should just be able to swap eye-views prior to the stereo3d function and it should then look right to you with those odd glasses. See above posts for examples using il=s for eye-view-swapping / parallax-inversion. The other thing missing is arbitrary user-color choices for glasses. A calibration test pattern would also be nice. OH, better yet, just lie to the program instead of swapping views. If you have cyan/red glasses instead of red/cyan, then just pretend the format is opposite when you run the command Use RL when you really have LR and use BA when you really have AB). Also, treat red/blue glasses as red/cyan. That should work well enough.
Onward...
Hmmmm, should I pick up where I left off or respond to posts I've missed out on? I will respond to posts.
---
to chinesebob:
Hi guy, how did you find this thread? It's kind of buried. I'll have to put all this in a web page some day rewriting some of the things I've learned. It looks like I'm accidentally writing a book. Anyway, nice to see a new poster. Regarding anaglyph generation, you see I've answered your question with the above info so there you go. Sorry to not reply sooner. Let's see, what else...
---
to jduncantor:
What you want is AviSynth. It is a really neat helper program that I've started to use late last year and I really like it. However, I'm not ready to post about it at this point in time but it's pretty easy once you get the idea of it. You will be able to then use mplayer/mencoder to reference a fake video file that is really a text file that refers to your real 2 video files. Basically you make a text file that mentions your 2 video files and change the extension of that file from .txt to .avs, then you pretend that that file is a video file and do mencoder file.avs and that will make your new combo file side-by-side or over/under. http://www.avisynth.org bounces you to avisynth.org/mediawiki/Main_Page and you can go from there. What you want to click on is "filters", then "internal filters", then search/find StackHorizontal or StackVertical. Read/look/study/research examples and I'm confident you will be on your way to happiness and satisfaction. There could be some stumbling blocks for you though if your files are mpegs. Convert them to avi's and that will help make things a little simpler. Oh, I guess I was able to talk about this stuff now although I would have liked to expand on this more, I'm a little rusty with AviSynth right now. I've used it to add Blue-line-codes to my 3d videos that auto-trigger my shutterglasses so it's pretty great!
Oh, darn. After all that I just remembered SMM (StereoMovieMaker). It can do what you want easier. Google it. I don't know if there's a Linux version of that. Oh wait, I don't think it can input png files, just separate video files. Oh well. Just try AviSynth.
Oh yeah, AviSynth is for windows but I've heard that it works with Linux by using Wine although I haven't tried it myself.
mplayer and HD:
mencoder IS capable of HD as the user is control of the quality settings depending on the codecs used but for stereo3d, I recommend the above-below format since mencoder can crash if you try to make a video-file that is over 2000 pixels wide. Side-by-side HD would be 1920x2=3840 pixels wide although I believe you can edit the source and recompile mencoder so that it can handle that res. I would just user RO/UL which I'm starting to call RoL for short (Right-over-Left). My videocard is older so I have trouble with the playback of that high of a res (1920x2160) but I think modern cards should handle it fine. Maybe I need a quad-core which is what I've heard for Blu-Ray-3d. Anyway, it's not mplayer's fault if my system can't handle the res.
mplayer, AviSynth and png files:
mplayer/mencoder can input png files but what I've suggested was AviSynth. I'm not sure if it can import png files. Wait let me check... Yes! It can! Find ImageSource in the internal filter page and go from there. Else you could use mencoder to make avi files and use AviSynth with them instead.
YouTube videos:
Just make a side-by-side video that is 1280x720 and RL instead of LR and things will be easier for you. Go ahead and squash/squeeze the video into that frame and fix the aspect with the aspect youtube-tag. Reread some of my above post and upload your video to YouTube and post a link here so we can see/find it easily. Good luck!
---
Hi Mickeyjaw, I'll put bino on my to-try list but who knows when I'll get to it...
Just took a look. It's a nice clean simple webpage just like I like. Seems like it should be decent but I see it also has no half-mirrored modes. Oh well, I don't need those anyway.
---
Hi Fredz,
Oh, you already answered JD's question. Oh well.
---
OK, all caught up. No wonder I took such a long break. I guess I get carried away with these posts and get burnt out. Hmmm, what else...?
Spanning mode display under Windows:
Earlier in this thread I wondered how to do dual screen video in Windows and it turns out that the answer was to use -vo directx:noaccel or -vo gl since -vo directx (the default) only works on one screen at a time when playing a video. The other screen is green if you use spanning mode with two monitors/projectors. So now we know how to use mplayer to play 3d videos with dual projectors and horizontal or vertical spanning mode. It was just something simple like -vo directx:noaccel although as mentioned earlier your system might not be fast enough in software display mode to show HD 3d. If so, try -vo gl (openGL mode). If that doesn't work, then I guess we're stuck using some other program or else 2 mplayer programs simultaneously?
Does anyone know how to use FIFO's to control two mplayer programs simultaneously using tee or something? That would be slick.
---
OK, that's it for now. I've more to say but let's call it a night. Good night all.
--- iondrive ---
I'm still alive if any of you were wondering what happened to me. I just haven't been reading/posting for a very long time... distractions abound. I don't know if I will get back into the habit of posting more actively but I'll just do a little right now at least.
New stereo3d functions in mplayer source!!! YAY!
This happened late last year but I'm actually not that excited about it since it doesn't really add formats that I could not do before except for easy stereo-to-anaglyph conversion for those times when you want that. Since it's new code, you could have some trouble finding a compiled version of mplayer/mencoder that has it but I found one for windows at
http://oss.netfarm.it/mplayer-win32.php
and tried it and it worked. The file was for athlons: mplayer-athlon-svn-32848.7z
The code adds a video filter called stereo3d and you use it in your -vf segment as in
mplayer futbol-3d.mpg -vf stereo3d=sbsl:agmh,scale
to go from LR to anaglyph green/magenta-half-color while converting on-the-fly.
This works with mencoder too so you can make 3d anaglyph videos if you want but I would just keep the originals and just convert on-the-fly as needed. My feelings about anaglyph are that it's not too repulsive and it's a good option for printing out a screenshot on paper. Remember to use scale after stereo3d or else mplayer will crash.
Anyway, there's more info in the man-page at
http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt
Once you are there, search for "stereo3d" and that should take you right to it.
NOTE: if you Google mplayer manpage, you can wind up at the Tivo mplayer manpage which is missing alot of functions in the full source so don't freak out if you don't see the options you're looking for. Just go to mplayerhq.hu instead.
Basically the format is stereo3d=input:output format and the possible s3d formats for in/out are:
LR, RL, L/R, R/L, and squashed L/R, R/L.
Output also includes various anaglyph color-sets...
3 kinds of yellow/blue (gray, half-color, and color)
3 kinds of green/magenta (as above)
4 kinds of red/cyan (as above plus dubois)
as well as mono left or right view.
Anaglyph red/cyan dubois?...
I had to try that one and I think it did look the best of all the red/cyans but it might depend on your particular content. The manpage says it is "color optimized with the least squares projection of dubois". Oh, of course. I should have realized that myself.
What's missing from the stereo3d option: half-mirrored modes and checkerboard outputs.
I'm glad this is in the code and there's a chance that this function may do a better job at converting between formats but as I said before, we already could do those conversions so this doesn't add much except for easy anaglyph conversion. What's missing is half-mirrored modes as well as checkerboard outputs. That would have been a more welcome addition to the conversions we already can do. I will for the most part not use this new function since the old approach works with older mplayer versions too. Half-mirrored modes should be easy. Maybe someone will contact the author of that subroutine and suggest it to him/her. Volunteers? I have other things on my mind. Also missing is frame-sequential and field-sequential as well as vertical interlaced. Good thing we can do all those already.
Odd-colored glasses:
If your glasses are colored backwards for some reason, it seems like you should just be able to swap eye-views prior to the stereo3d function and it should then look right to you with those odd glasses. See above posts for examples using il=s for eye-view-swapping / parallax-inversion. The other thing missing is arbitrary user-color choices for glasses. A calibration test pattern would also be nice. OH, better yet, just lie to the program instead of swapping views. If you have cyan/red glasses instead of red/cyan, then just pretend the format is opposite when you run the command Use RL when you really have LR and use BA when you really have AB). Also, treat red/blue glasses as red/cyan. That should work well enough.
Onward...
Hmmmm, should I pick up where I left off or respond to posts I've missed out on? I will respond to posts.
---
to chinesebob:
Hi guy, how did you find this thread? It's kind of buried. I'll have to put all this in a web page some day rewriting some of the things I've learned. It looks like I'm accidentally writing a book. Anyway, nice to see a new poster. Regarding anaglyph generation, you see I've answered your question with the above info so there you go. Sorry to not reply sooner. Let's see, what else...
---
to jduncantor:
What you want is AviSynth. It is a really neat helper program that I've started to use late last year and I really like it. However, I'm not ready to post about it at this point in time but it's pretty easy once you get the idea of it. You will be able to then use mplayer/mencoder to reference a fake video file that is really a text file that refers to your real 2 video files. Basically you make a text file that mentions your 2 video files and change the extension of that file from .txt to .avs, then you pretend that that file is a video file and do mencoder file.avs and that will make your new combo file side-by-side or over/under. http://www.avisynth.org bounces you to avisynth.org/mediawiki/Main_Page and you can go from there. What you want to click on is "filters", then "internal filters", then search/find StackHorizontal or StackVertical. Read/look/study/research examples and I'm confident you will be on your way to happiness and satisfaction. There could be some stumbling blocks for you though if your files are mpegs. Convert them to avi's and that will help make things a little simpler. Oh, I guess I was able to talk about this stuff now although I would have liked to expand on this more, I'm a little rusty with AviSynth right now. I've used it to add Blue-line-codes to my 3d videos that auto-trigger my shutterglasses so it's pretty great!
Oh, darn. After all that I just remembered SMM (StereoMovieMaker). It can do what you want easier. Google it. I don't know if there's a Linux version of that. Oh wait, I don't think it can input png files, just separate video files. Oh well. Just try AviSynth.
Oh yeah, AviSynth is for windows but I've heard that it works with Linux by using Wine although I haven't tried it myself.
mplayer and HD:
mencoder IS capable of HD as the user is control of the quality settings depending on the codecs used but for stereo3d, I recommend the above-below format since mencoder can crash if you try to make a video-file that is over 2000 pixels wide. Side-by-side HD would be 1920x2=3840 pixels wide although I believe you can edit the source and recompile mencoder so that it can handle that res. I would just user RO/UL which I'm starting to call RoL for short (Right-over-Left). My videocard is older so I have trouble with the playback of that high of a res (1920x2160) but I think modern cards should handle it fine. Maybe I need a quad-core which is what I've heard for Blu-Ray-3d. Anyway, it's not mplayer's fault if my system can't handle the res.
mplayer, AviSynth and png files:
mplayer/mencoder can input png files but what I've suggested was AviSynth. I'm not sure if it can import png files. Wait let me check... Yes! It can! Find ImageSource in the internal filter page and go from there. Else you could use mencoder to make avi files and use AviSynth with them instead.
YouTube videos:
Just make a side-by-side video that is 1280x720 and RL instead of LR and things will be easier for you. Go ahead and squash/squeeze the video into that frame and fix the aspect with the aspect youtube-tag. Reread some of my above post and upload your video to YouTube and post a link here so we can see/find it easily. Good luck!
---
Hi Mickeyjaw, I'll put bino on my to-try list but who knows when I'll get to it...
Just took a look. It's a nice clean simple webpage just like I like. Seems like it should be decent but I see it also has no half-mirrored modes. Oh well, I don't need those anyway.
---
Hi Fredz,
Oh, you already answered JD's question. Oh well.
---
OK, all caught up. No wonder I took such a long break. I guess I get carried away with these posts and get burnt out. Hmmm, what else...?
Spanning mode display under Windows:
Earlier in this thread I wondered how to do dual screen video in Windows and it turns out that the answer was to use -vo directx:noaccel or -vo gl since -vo directx (the default) only works on one screen at a time when playing a video. The other screen is green if you use spanning mode with two monitors/projectors. So now we know how to use mplayer to play 3d videos with dual projectors and horizontal or vertical spanning mode. It was just something simple like -vo directx:noaccel although as mentioned earlier your system might not be fast enough in software display mode to show HD 3d. If so, try -vo gl (openGL mode). If that doesn't work, then I guess we're stuck using some other program or else 2 mplayer programs simultaneously?
Does anyone know how to use FIFO's to control two mplayer programs simultaneously using tee or something? That would be slick.
---
OK, that's it for now. I've more to say but let's call it a night. Good night all.
--- iondrive ---
Last edited by iondrive on Tue Mar 13, 2012 7:49 pm, edited 6 times in total.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
combining 2 videos into 1 s3d video with mencoder
hey jduncantor and others,
You don't need to use AviSynth after all. To combine two video files into one using mencoder, you just have to do it the hard way and convert the videos into image files frame-by-frame but JD, you already have that so this solution is fine for you. Try to get all your image files into the same folder with a naming pattern like this:
00000001L.jpg
00000001R.jpg
00000002L.jpg
00000002R.jpg
00000003L.jpg
00000003R.jpg
00000004L.jpg
00000004R.jpg
.
.
.
OK, JD is using png's but my examples will use jpg's cause it's more generic. It still gives good results even though jpegs are lossy. It has a quality option if you want to use it. For example: -vo jpeg:quality=99. Output file formats for mplayer include jpeg, pnm, png, tga, and animated gifs with certain limitations. See the manpage for details in the -vo section. As far as inputs for mencoder go with mf://*.xxx" onclick="window.open(this.href);return false;, I think it's the same but haven't tested all those. What's interesting is that mplayer can input files with mf://*.jpg" onclick="window.open(this.href);return false; and output files with -vo jpeg in the same command so that you can use mplayer as a file-converter (image files in, image files out). Neat huh? By the way, the mplayer versions I have can play MNG ("ming" like "ping") files. Those are like PNG image files except that it is Multiple image files. This may be of interest to you if you record game video with MAME's built-it recorder since it records in MNG. It seems to make gameplay way to slow though and doesn't record sound. Oh well, onward.
Try to have nothing else in that directory that might cause problems. If you have 100's of thousands of images, it might be a problem for the filesystem to handle so many files in one folder. Anyway, once you've got this setup, get in that directory and use this command to get an avi using h264 codec.
*** frame-sequential image files to left-over-right full frames via tile
mencoder mf://*.jpg" onclick="window.open(this.href);return false; -vf tile=1:2:2:0:0,scale -fps 48 -ofps 24 -o left-over-right.avi -ovc x264 -x264encopts crf=20
This is for a video with 24 frames/sec. If you want 30 fps output, then use "-fps 60 -ofps 30" instead of "-fps 48 -ofps 24". Use whatever output fps is right for you, just make -fps double of -ofps where -ofps is your output fps. Output fps should be 1/2 of input fps because of the tile function... every two input images create one output image.
This stacks your images above/below with Left on top just because L comes before R. Adjust as needed.
*** frame-sequential image files to side-by-side LR via tile
For side-by-side, use "-vf tile=2:1:2:0:0,scale" instead of the above but be warned that you may crash mencoder if your output res is more than 2000 pixels wide. If you're up to it, try to edit the source and recompile in order to fix this limitation.
What about sound?
Yes, this has no sound. Do you need help adding sound? I don't want to get into sound right now but maybe you can just use -audiofile file.mp3 or whatever. You may have timing issues.
What if you don't have all those image files?
In that case use mplayer to make them:
*** 2 input files to frame-sequential image files in one folder (windows version)
Dealing with unsynced input videos:
The above assumes that your videos are in perfect frame-by-frame sync. If they are not, then you have to find some work-around like cutting off the beginning of the earlier one or if it's only a few frames off, then you can delay one of the fields when your video is interlaced using -vf phase=t or phase=b. For example, use phase=t,phase=t,phase=t to delay the left-eye view by three frames. t is for top (odd lines) and b is for bottom (even lines) although some videos can have labels in them that designate the opposite relationship. Another option is to use a text file as input with all your image files listed in the order you want them. You need some experience with the text-manipulating gnu/linux/bash command line utilities to make it easier to rearrange long lists of filenames in a text file. Then you could use mf://@list.txt" onclick="window.open(this.href);return false; instead of mf://*.jpg" onclick="window.open(this.href);return false;
Doing a short test play/encode via -frames :
use -frames 600 in your mplayer commands above if you just want to do a little test that is 20 seconds long if your videos are 30 fps. This is a good option to remember and also works with mencoder. A 90 minute video at 30 fps gives you 162000 frames so make sure you have the space by testing with shorter durations first if you think it's needed.
*** frame-sequential video encoded from 2 input video files
Just follow the above approach and encode it using mf://*.jpg" onclick="window.open(this.href);return false; and appropriate -fps. I need to expand on this in a later post since there can be complications involving both encoding and playback. It can get hairy but not always.
So now you have your files all set up in that combo directory ready to run the previously mentioned mencoder command. Linux users should be able to do something similar. My linux is getting rusty or else I'd give you an example straight away. In the past, I've kept left and right images in their own dirs and just used symlinks in the combo dir. Just get the files paired up in any way you can in an alternating LR order.
To get the audio from your video files, use -ao pcm:
mplayer left.avi -novideo -ao pcm
and this will make a file called audiodump.wav that you can use with -audiofile.
If this doesn't work for some reason, try replacing "-novideo" with "-vc null -vo null" instead.
OK, this needs better examples but I'm getting lazy. Sorry.
Yes, it's awkward to make all those image files just to put the videos together but on the other hand, you can script this and it can be pretty transparent.
It's still surprising to me what you can do with mplayer/mencoder, but wait there's more for later. Here's a clue: "-vf phase=b"
Can you guess what kind of 3d conversion that would be good for?
--- iondrive ---
PS: I also wanted to mention using -vf tinterlace=0 instead of tile in order to get to LR or L-on-R. tinterlace is the opposite of tfields and takes sequential frames and combines pairs of frames into one frame by interlacing the two into alternating horizontal lines which makes your video twice as tall when you use the tinterlace=0 option. The top line of the output comes from the first frame and is considered odd so that the top line is line 1 and not line 0. Then you can use il=d to get L-on-R or else if you want LR, then use fil=d. If you get weird colors, then stick an ilpack before il or fil and a scale afterwards if needed. The tests I did, did not need ilpack.
*** frame-sequential (jpeg) image files to Left-over-Right (L-on-R, LoR), full-frames (doubles height)
mencoder mf://*.jpg" onclick="window.open(this.href);return false; -vf tinterlace=0,il=d,scale,dsize -o tinterlaced-LonR.avi -ovc x264 -x264encopts crf=20 -fps 48 -ofps 24
As before, -ofps must be half of -fps since you are combining every two frames into one or else you get each pair of frames repeated in the output video. Scale as needed.
*** frame-sequential image files to side-by-side LR, full-frames (doubles width)
For LR instead of L-on-R, just replace il=d with fil=d and rename the output file appropriately. Just beware that the output width will be the double of a single input frame and if it's more than 2000 pixels wide, it will probably crash mencoder. I think that can only be fixed by editing the mencoder source and recompiling but I really haven't investigated that. It's just a guess. Otherwise it could be a codec format limitation.
*** frame-sequential image files to RL or R/L
If you want R-on-L or RL, just append ,il=s after =d in your -vf video filter list section.
*** frame-sequential image files to interlaced (or field-sequential) video file
tinterlace does that job for you so if you just want to go from frame-sequential to field-sequential, then just don't use il=d and then make sure you use a codec that preserves interlacing integrity but I don't have examples of that handy, mpeg2video and mpeg4 should work. That's why I don't save files in field-sequential format since it limits your choices of codecs. Instead, I use R-on-L and convert to field-sequential interlaced on the fly with mplayer. Use il=s,scale to swap fields as needed of course. Also you probably want to squash the double-framed height down to a single-framed height so use scale=width:height:1 . Don't forget the :1 or else you'll lose line integrity. You have to use the right number for the height value since mencoder doesn't have a generic halving option in it's scale filter. Read the text on the console for the original video's res when you play it with mplayer. The left-eye view will be in the top (odd) line in this case.
CONCLUSIONS:
So which approach should you use, tinterlace or tile? In this case I think tile is a little better since it doesn't go through an interlaced stage which sometimes causes color-spilling problems due to subsampling although it's easy enough to test your output and if it looks good, then it looks good. Too bad the stereo3d option includes neither frame-sequential nor field-sequential 3d formats. Oh well, maybe in the future. Bye now.
You don't need to use AviSynth after all. To combine two video files into one using mencoder, you just have to do it the hard way and convert the videos into image files frame-by-frame but JD, you already have that so this solution is fine for you. Try to get all your image files into the same folder with a naming pattern like this:
00000001L.jpg
00000001R.jpg
00000002L.jpg
00000002R.jpg
00000003L.jpg
00000003R.jpg
00000004L.jpg
00000004R.jpg
.
.
.
OK, JD is using png's but my examples will use jpg's cause it's more generic. It still gives good results even though jpegs are lossy. It has a quality option if you want to use it. For example: -vo jpeg:quality=99. Output file formats for mplayer include jpeg, pnm, png, tga, and animated gifs with certain limitations. See the manpage for details in the -vo section. As far as inputs for mencoder go with mf://*.xxx" onclick="window.open(this.href);return false;, I think it's the same but haven't tested all those. What's interesting is that mplayer can input files with mf://*.jpg" onclick="window.open(this.href);return false; and output files with -vo jpeg in the same command so that you can use mplayer as a file-converter (image files in, image files out). Neat huh? By the way, the mplayer versions I have can play MNG ("ming" like "ping") files. Those are like PNG image files except that it is Multiple image files. This may be of interest to you if you record game video with MAME's built-it recorder since it records in MNG. It seems to make gameplay way to slow though and doesn't record sound. Oh well, onward.
Try to have nothing else in that directory that might cause problems. If you have 100's of thousands of images, it might be a problem for the filesystem to handle so many files in one folder. Anyway, once you've got this setup, get in that directory and use this command to get an avi using h264 codec.
*** frame-sequential image files to left-over-right full frames via tile
mencoder mf://*.jpg" onclick="window.open(this.href);return false; -vf tile=1:2:2:0:0,scale -fps 48 -ofps 24 -o left-over-right.avi -ovc x264 -x264encopts crf=20
This is for a video with 24 frames/sec. If you want 30 fps output, then use "-fps 60 -ofps 30" instead of "-fps 48 -ofps 24". Use whatever output fps is right for you, just make -fps double of -ofps where -ofps is your output fps. Output fps should be 1/2 of input fps because of the tile function... every two input images create one output image.
This stacks your images above/below with Left on top just because L comes before R. Adjust as needed.
*** frame-sequential image files to side-by-side LR via tile
For side-by-side, use "-vf tile=2:1:2:0:0,scale" instead of the above but be warned that you may crash mencoder if your output res is more than 2000 pixels wide. If you're up to it, try to edit the source and recompile in order to fix this limitation.
What about sound?
Yes, this has no sound. Do you need help adding sound? I don't want to get into sound right now but maybe you can just use -audiofile file.mp3 or whatever. You may have timing issues.
What if you don't have all those image files?
In that case use mplayer to make them:
*** 2 input files to frame-sequential image files in one folder (windows version)
Code: Select all
mkdir left
mkdir right
mkdir combo
mplayer -nosound left.avi -vo jpeg:outdir=left
mplayer -nosound right.avi -vo jpeg:outdir=right
cd left
rem renaming for windows (appending L or R to constant-length filenames)
ren ????????.jpg ????????L.jpg
move *.jpg ..\combo
cd ..
cd right
ren ????????.jpg ????????R.jpg
move *.jpg ..\combo
cd ..
cd combo
The above assumes that your videos are in perfect frame-by-frame sync. If they are not, then you have to find some work-around like cutting off the beginning of the earlier one or if it's only a few frames off, then you can delay one of the fields when your video is interlaced using -vf phase=t or phase=b. For example, use phase=t,phase=t,phase=t to delay the left-eye view by three frames. t is for top (odd lines) and b is for bottom (even lines) although some videos can have labels in them that designate the opposite relationship. Another option is to use a text file as input with all your image files listed in the order you want them. You need some experience with the text-manipulating gnu/linux/bash command line utilities to make it easier to rearrange long lists of filenames in a text file. Then you could use mf://@list.txt" onclick="window.open(this.href);return false; instead of mf://*.jpg" onclick="window.open(this.href);return false;
Doing a short test play/encode via -frames :
use -frames 600 in your mplayer commands above if you just want to do a little test that is 20 seconds long if your videos are 30 fps. This is a good option to remember and also works with mencoder. A 90 minute video at 30 fps gives you 162000 frames so make sure you have the space by testing with shorter durations first if you think it's needed.
*** frame-sequential video encoded from 2 input video files
Just follow the above approach and encode it using mf://*.jpg" onclick="window.open(this.href);return false; and appropriate -fps. I need to expand on this in a later post since there can be complications involving both encoding and playback. It can get hairy but not always.
So now you have your files all set up in that combo directory ready to run the previously mentioned mencoder command. Linux users should be able to do something similar. My linux is getting rusty or else I'd give you an example straight away. In the past, I've kept left and right images in their own dirs and just used symlinks in the combo dir. Just get the files paired up in any way you can in an alternating LR order.
To get the audio from your video files, use -ao pcm:
mplayer left.avi -novideo -ao pcm
and this will make a file called audiodump.wav that you can use with -audiofile.
If this doesn't work for some reason, try replacing "-novideo" with "-vc null -vo null" instead.
OK, this needs better examples but I'm getting lazy. Sorry.
Yes, it's awkward to make all those image files just to put the videos together but on the other hand, you can script this and it can be pretty transparent.
It's still surprising to me what you can do with mplayer/mencoder, but wait there's more for later. Here's a clue: "-vf phase=b"
Can you guess what kind of 3d conversion that would be good for?
--- iondrive ---
PS: I also wanted to mention using -vf tinterlace=0 instead of tile in order to get to LR or L-on-R. tinterlace is the opposite of tfields and takes sequential frames and combines pairs of frames into one frame by interlacing the two into alternating horizontal lines which makes your video twice as tall when you use the tinterlace=0 option. The top line of the output comes from the first frame and is considered odd so that the top line is line 1 and not line 0. Then you can use il=d to get L-on-R or else if you want LR, then use fil=d. If you get weird colors, then stick an ilpack before il or fil and a scale afterwards if needed. The tests I did, did not need ilpack.
*** frame-sequential (jpeg) image files to Left-over-Right (L-on-R, LoR), full-frames (doubles height)
mencoder mf://*.jpg" onclick="window.open(this.href);return false; -vf tinterlace=0,il=d,scale,dsize -o tinterlaced-LonR.avi -ovc x264 -x264encopts crf=20 -fps 48 -ofps 24
As before, -ofps must be half of -fps since you are combining every two frames into one or else you get each pair of frames repeated in the output video. Scale as needed.
*** frame-sequential image files to side-by-side LR, full-frames (doubles width)
For LR instead of L-on-R, just replace il=d with fil=d and rename the output file appropriately. Just beware that the output width will be the double of a single input frame and if it's more than 2000 pixels wide, it will probably crash mencoder. I think that can only be fixed by editing the mencoder source and recompiling but I really haven't investigated that. It's just a guess. Otherwise it could be a codec format limitation.
*** frame-sequential image files to RL or R/L
If you want R-on-L or RL, just append ,il=s after =d in your -vf video filter list section.
*** frame-sequential image files to interlaced (or field-sequential) video file
tinterlace does that job for you so if you just want to go from frame-sequential to field-sequential, then just don't use il=d and then make sure you use a codec that preserves interlacing integrity but I don't have examples of that handy, mpeg2video and mpeg4 should work. That's why I don't save files in field-sequential format since it limits your choices of codecs. Instead, I use R-on-L and convert to field-sequential interlaced on the fly with mplayer. Use il=s,scale to swap fields as needed of course. Also you probably want to squash the double-framed height down to a single-framed height so use scale=width:height:1 . Don't forget the :1 or else you'll lose line integrity. You have to use the right number for the height value since mencoder doesn't have a generic halving option in it's scale filter. Read the text on the console for the original video's res when you play it with mplayer. The left-eye view will be in the top (odd) line in this case.
CONCLUSIONS:
So which approach should you use, tinterlace or tile? In this case I think tile is a little better since it doesn't go through an interlaced stage which sometimes causes color-spilling problems due to subsampling although it's easy enough to test your output and if it looks good, then it looks good. Too bad the stereo3d option includes neither frame-sequential nor field-sequential 3d formats. Oh well, maybe in the future. Bye now.
Last edited by iondrive on Tue Apr 26, 2011 4:12 am, edited 3 times in total.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
YouTube 3d slideshows from LR photos in separate files
Hi again,
Before I get to talking about a new topic using the phase filter, let me finish what I started before regarding making YouTube slideshow videos.
Making s3d video slideshows for YouTube: specific examples
Section 3: using real photos from separate left/right image files
Well, I sort of accidentally covered this in the above post. If you read it, then you can guess that you need to put your files in a temp folder so that they are arranged in pairs and then use mf://*.jpg" onclick="window.open(this.href);return false; and "-vf tile..." or "-vf tinterlace..." on them as above. Otherwise use a list file. Let's see. Suppose you had a list.txt file like this:
pic0-L.jpg
pic0-R.jpg
pic1-L.jpg
pic1-R.jpg
pic2-L.jpg
pic2-R.jpg
.
.
.
pic9-L.jpg
pic9-R.jpg
All your images should be the same res and aspect ratios. Notice that the left view is first. Then you could do the following:
(in the same directory as the image files and list.txt)
*** separate eye-view 16:9 aspect image files to YouTube LR 3d video slideshow
mencoder mf://@list.txt" onclick="window.open(this.href);return false; -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.5 -ofps 30 -vf scale=640:720,tile=2:1:2:0:0,scale=1280:720,dsize
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3
NEW: yt3d:enable=LR
The tricky thing here is that -fps 0.5 makes it look like each image is going to be 2 seconds but the tile filter is combining every two images into one so that each image of your slideshow actually is 4 seconds long. I use scale in the beginning in case your pics are 12 megapixels or something. The last scale could probably be left off or just "scale" but I include it for clarity regarding the final dimensions of the video.
If your files are right-image first:
Then use -vf scale=640:720,tile=2:1:2:0:0,ilpack,fil=i,il=s,fil=d,scale,dsize
or else use -vf scale=640:720,tinterlace=0,ilpack,il=s,fil=d,scale,dsize
All the things mentioned have been explained in previous posts so I think I can skip explaining all things here. I think that's it for now. If I remember something, I'll just have to edit this.
--- iondrive ---
Before I get to talking about a new topic using the phase filter, let me finish what I started before regarding making YouTube slideshow videos.
Making s3d video slideshows for YouTube: specific examples
Section 3: using real photos from separate left/right image files
Well, I sort of accidentally covered this in the above post. If you read it, then you can guess that you need to put your files in a temp folder so that they are arranged in pairs and then use mf://*.jpg" onclick="window.open(this.href);return false; and "-vf tile..." or "-vf tinterlace..." on them as above. Otherwise use a list file. Let's see. Suppose you had a list.txt file like this:
pic0-L.jpg
pic0-R.jpg
pic1-L.jpg
pic1-R.jpg
pic2-L.jpg
pic2-R.jpg
.
.
.
pic9-L.jpg
pic9-R.jpg
All your images should be the same res and aspect ratios. Notice that the left view is first. Then you could do the following:
(in the same directory as the image files and list.txt)
*** separate eye-view 16:9 aspect image files to YouTube LR 3d video slideshow
mencoder mf://@list.txt" onclick="window.open(this.href);return false; -o temp.avi -nosound -ovc x264 -x264encopts crf=20 -fps 0.5 -ofps 30 -vf scale=640:720,tile=2:1:2:0:0,scale=1280:720,dsize
YouTube tags:
OLD: yt3d:enable=true yt3d:aspect=4:3
NEW: yt3d:enable=LR
The tricky thing here is that -fps 0.5 makes it look like each image is going to be 2 seconds but the tile filter is combining every two images into one so that each image of your slideshow actually is 4 seconds long. I use scale in the beginning in case your pics are 12 megapixels or something. The last scale could probably be left off or just "scale" but I include it for clarity regarding the final dimensions of the video.
If your files are right-image first:
Then use -vf scale=640:720,tile=2:1:2:0:0,ilpack,fil=i,il=s,fil=d,scale,dsize
or else use -vf scale=640:720,tinterlace=0,ilpack,il=s,fil=d,scale,dsize
All the things mentioned have been explained in previous posts so I think I can skip explaining all things here. I think that's it for now. If I remember something, I'll just have to edit this.
--- iondrive ---
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
YouTube 3d slideshows from interlaced png files
Hey there y'all,
Ready for more boring stuff? Let's finish this so we can get on to more interesting stuff.
Firstly, note that Ive edited my previous posts regarding YouTube tags so that they're now up-to-date as of April, 2011. Basically, I'll try to stick to side-by-side LR unless I have reason to use L-on-R or R-on-L. RL (crosseyed) format is discouraged. These are the current tags.
yt3d:enable=LR
yt3d:enable=LonR
yt3d:enable=RonL
yt3d:enable=RL
Single-eye views must be 50% squeezed horizontally or 50% squashed vertically so that the new video has the same aspect as a full-framed single-eye view. That's how they avoid needing to specify aspect with a tag. That means 4:3 aspect video should be 640x480 or something like that although I have not tried it yet. Hopefully it can take higher res like 1024x768 or 1280x960. Does anyone have more info on this? I think those should be fine. Anyway, onward...
Making s3d video slideshows for YouTube: specific examples
Section 4: using interlaced png files from nvidia or other
Old-school nvidia screenshots are normally jps files but if you use interlaced or checkerboard 3d output formats, then the screenshots are interlaced PNG files since jpegs are lossy and not good for interlaced images. Most likely, this would be used on a Zalman 3d interlaced display and so that means that the top line is meant for the right eye. Strategy is like in the previous examples but in this case, when we deinterlace the screenshots, we get a R-on-L frame that already has it's images 50% squashed so it's pretty convenient. Examples:
*** nvidia (Zalman) interlaced-3d 16:9 aspect png screenshots to YouTube R-on-L 3d video slideshow:
mencoder "mf://*.png" -o temp.avi -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720:1,ilpack,il=d,scale=1280:720,dsize=16/9
YouTube tags: yt3d:enable=RonL
General notes:
If you decide to remove the first scale, then also remove ilpack or else it will give you some software ghosting. I stuck it in there just in case your screenshots do not have a res that is multiples of 16. It's normally not needed here but it's good practice to have it.
-mf type=png is unneeded since mencoder can autodetect it.
Other options are explained in previous posts.
For left-view-first interlaced images, use il=ds instead of il=d, or else "yt3d:enable=LonR" but not both or else they'll cancel each other out and you'll have inverted stereo.
And finally, if you want to "standardize" your interlaced images into a LR slideshow:
(This is not recommended due to image data loss.)
*** interlaced-3d 16:9 aspect png screenshots to YouTube LR 3d video slideshow:
mencoder "mf://*.png" -o temp.avi -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=640
1,il=s,fil=d,scale=1280:720,dsize=16/9
YouTube tags: yt3d:enable=LR
fil quirks:
ilpack was not needed for some reason. It probably has something to do with fil. If your screenshots were 800x600, then you might have a little problem if you leave off the first scale. 800x600 is not a res that is multiples of 16 (600/16=37.5) and fil does not like it so it puts a thin gray stripe down the middle of your image-pair. The solution is to scale to dimensions that are multiples of 16 before using fil. Just remember how fil changes the dimensions of the image and figure the scale dimensions accordingly.
Viewing the images without making a video file:
Before you make these videos, you may want to preview what the slideshow will look like and you can easily use mplayer to do that if you are an interlaced user. That's what the next post is all about.
--- iondrive ---
Ready for more boring stuff? Let's finish this so we can get on to more interesting stuff.
Firstly, note that Ive edited my previous posts regarding YouTube tags so that they're now up-to-date as of April, 2011. Basically, I'll try to stick to side-by-side LR unless I have reason to use L-on-R or R-on-L. RL (crosseyed) format is discouraged. These are the current tags.
yt3d:enable=LR
yt3d:enable=LonR
yt3d:enable=RonL
yt3d:enable=RL
Single-eye views must be 50% squeezed horizontally or 50% squashed vertically so that the new video has the same aspect as a full-framed single-eye view. That's how they avoid needing to specify aspect with a tag. That means 4:3 aspect video should be 640x480 or something like that although I have not tried it yet. Hopefully it can take higher res like 1024x768 or 1280x960. Does anyone have more info on this? I think those should be fine. Anyway, onward...
Making s3d video slideshows for YouTube: specific examples
Section 4: using interlaced png files from nvidia or other
Old-school nvidia screenshots are normally jps files but if you use interlaced or checkerboard 3d output formats, then the screenshots are interlaced PNG files since jpegs are lossy and not good for interlaced images. Most likely, this would be used on a Zalman 3d interlaced display and so that means that the top line is meant for the right eye. Strategy is like in the previous examples but in this case, when we deinterlace the screenshots, we get a R-on-L frame that already has it's images 50% squashed so it's pretty convenient. Examples:
*** nvidia (Zalman) interlaced-3d 16:9 aspect png screenshots to YouTube R-on-L 3d video slideshow:
mencoder "mf://*.png" -o temp.avi -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=1280:720:1,ilpack,il=d,scale=1280:720,dsize=16/9
YouTube tags: yt3d:enable=RonL
General notes:
If you decide to remove the first scale, then also remove ilpack or else it will give you some software ghosting. I stuck it in there just in case your screenshots do not have a res that is multiples of 16. It's normally not needed here but it's good practice to have it.
-mf type=png is unneeded since mencoder can autodetect it.
Other options are explained in previous posts.
For left-view-first interlaced images, use il=ds instead of il=d, or else "yt3d:enable=LonR" but not both or else they'll cancel each other out and you'll have inverted stereo.
And finally, if you want to "standardize" your interlaced images into a LR slideshow:
(This is not recommended due to image data loss.)
*** interlaced-3d 16:9 aspect png screenshots to YouTube LR 3d video slideshow:
mencoder "mf://*.png" -o temp.avi -ovc x264 -x264encopts crf=20 -fps 0.25 -ofps 30 -vf scale=640
1,il=s,fil=d,scale=1280:720,dsize=16/9YouTube tags: yt3d:enable=LR
fil quirks:
ilpack was not needed for some reason. It probably has something to do with fil. If your screenshots were 800x600, then you might have a little problem if you leave off the first scale. 800x600 is not a res that is multiples of 16 (600/16=37.5) and fil does not like it so it puts a thin gray stripe down the middle of your image-pair. The solution is to scale to dimensions that are multiples of 16 before using fil. Just remember how fil changes the dimensions of the image and figure the scale dimensions accordingly.
Viewing the images without making a video file:
Before you make these videos, you may want to preview what the slideshow will look like and you can easily use mplayer to do that if you are an interlaced user. That's what the next post is all about.
--- iondrive ---
Last edited by iondrive on Thu Apr 28, 2011 8:45 am, edited 1 time in total.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
mplaying 3d slideshows from images for interlaced users
Hi all,
Lately I've been talking about making 3d slideshows from your files in various formats but what if you just want to view some images without actually making a video file? Well, that's what this post is about... using mplayer to view files without mencoding anything. Why not just use a slideshow program like sView or Tridef's or nvidia's 3d image viewer? Well, IDK, maybe they don't work right for you or something or if you're on Linux and have no better options. Anyway, onward.
For interlaced users:
Interlaced users are really blessed with some nice conveniences like not worrying about timing issues, being able to pause a video and still have it be in 3d, viewing 3d in a window or web browser, and being able to play some games that only offer interlaced mode. Anyway, regarding slideshows, if you have interlaced png files it's pretty easy and this works fine for 2d slideshows too of course.
*** The general slideshow command: (1 second / image)
mplayer -fps 1 mf://*.png" onclick="window.open(this.href);return false;
Quirk-1: driver ghosting
For interlaced images, if you see more than normal ghosting, you may need to use a different output driver since some of them do you the "favor" of de-interlacing video for you and so they harm the 3d effect. You might find a way to turn that off or just use another driver. I like the opengl output driver. Try -vo gl or else direct:noaccel. Both should work on Windows. Linux users can also try -vo x11.
Quirk-2: Last image lost
hmmm, darn, I see the last image is missing from view. I tried mf://*.png,filename.png" onclick="window.open(this.href);return false; but that didn't work. I guess if you care about the last image, then you should make a text file like list.txt or whatever you want to name it. For Windows: dir /b *.png > list.txt (or dir /b /s for full paths ) and then edit that txt file and duplicate the last entry. That will fix the problem.
*** general slideshow command using a list.txt file: (4 seconds / image)
mplayer -fps 0.25 mf://@list.txt" onclick="window.open(this.href);return false; -vo gl
Quirk-3: unresponsive keyboard controls
It seems that input is only checked in-between frames so when you play a video at 30 fps, it's fine, but if it's 0.25 fps, then most input seems ignored. If this is intolerable, then make a video file as shown before and play that instead. Unfortunately, mplayer cannot use a pair of input/output fps options like with mencoder using -fps and -ofps as that would probably fix things. There is another great solution for interlaced users though. Use -fps 25 and -loop 0 and then step through the images with the "." key. It's a nice slick, convenient solution but what's better is that an fps of 25 is the default for mf:// so you don't even need to specify it. Yay, a simpler command line.
*** user-controlled slideshow using "." to step through the images.
mplayer mf://*.png" onclick="window.open(this.href);return false; -loop 0 -vo gl
-loop 0 means loop the video continuously until you quit mplayer with "q" or escape. This means that you don't need to duplicate the last line of your list.txt file and you don't need to even make one since this method also fixes the missing last image quirk. Just use *.png. Nice. Note that when you reach the last image in the series, it behaves as if there is a second copy of it. Press "." once and the image is still the same. Press "." again and you start back at the first frame again. It's a good way to tell which frame is the last one in the series. Also note that -loop should be after the mf:// option and not before. It just works better that way.
Quirk-4: correct interlacing
if you are viewing in a window, you have a 50/50 chance of having the correct interlacing. If it's wrong, you can slide the window up/down till it's right or if you're using a CRT with an EDim controller and ED-Activator, then just use the hotkeys to flip the sync of the line-blanking. The other option is to rescale to fullscreen and then you will be able to always be in sync once you know if you need to use il=s or not. For 22" Zalman monitors:
*** Fullscreen slideshows for 22" Zalman Trimons ("." steps through images)
mplayer -vf il=s,scale=1680
1,dsize -fs mf://*.png" onclick="window.open(this.href);return false; -loop 0 -vo gl
Just drop the "il=s," if the lines are in the wrong place. I didn't need ilpack in my case.
Reminders:
In case you forgot, "-fs" is for fullscreen and the ":1" on the scale is to do the rescale without mixing the interlacing. Of course, you can change the numbers to change the size of your window if you don't use -fs. The dsize is important here to make sure that image alignment on your screen will match pixel for pixel. When dsize has no "=" after it, it defaults to the image's pixel dimensions which is exactly what we want here. If the interlacing is still wrong, then you just use the old ilpack,il=s, options before the scale. If you get weird colors, then drop the ilpack. Also remember that mf:// can autodetect some filetypes like png and jpg. If your input files are jps files, then you can still use them, just add -mf type=jpeg. If you have trouble remembering "mf", just think "multiple files". I think that's what it stands for but I don't really know. It's just a guess.
Side-by-side and above/below input formats:
If you have jpegs in side-by-side or above/below formats, then follow examples from previous posts regarding interlacing using "-vf fil=i" or "-vf il=i". In some cases you don't need ilpack before the il or fil but if you use it, then always follow it with a scale sometime after the il in the filter chain or else you'll get an error message. If you get some other weirdness, you may need to make sure that all your input files are the same size or aspect or that their dimensions are multiples of 16. Normally, things should just work right from the start.
using separate L and R image file-pairs as input:
For this kind of input, just follow the examples in the above posts regarding making slideshow videos. Get the files in pairs in one folder. They should all be the same size and have dimensions in multiples of 16 (800x600 screenshots need tweaking). If they are not sized right, then tile and fil may not work right. tinterlace is probably your best option. Here're some examples in case you have 800x600 separate L and R input files:
tinterlacing:
*** slideshowing separate L and R 3d image files using tinterlace ("." steps through images)
mplayer mf://*.jpg" onclick="window.open(this.href);return false; -vf tinterlace=0,scale=800:600:1,dsize -loop 0 -vo gl
tinterlace will make the images doubly tall so rescale before or after. You may need ilpack before tinterlace and then scale after. The first of each image pair will go into the odd lines and the second image will go into the even lines (top line is odd, #1). This causes the framerate to be cut in half but we're not worried about that here and the same goes for tile. Tile examples follow.
Vertical tiling:
*** tiling separate image files vertically and using il ("." steps through images)
mplayer mf://*.jpg" onclick="window.open(this.href);return false; -vf scale=640:480,tile=1:2:2:0:0,ilpack,il=i,scale=640:480:1,dsize -loop 0 -vo gl
This could be more efficient/effective but I chose the numbers for clarity. You should understand that after the tile, dimensions of the newly tiled image is 640x960 and after the il=i, it's still 640x960 so you could have made the original scale 640:240 and it would be more efficient. "fil=i" is a little trickier.
Horizontal tiling:
*** tiling separate image files horizontally and using fil ("." steps through images)
mplayer mf://*.jpg" onclick="window.open(this.href);return false; -vf scale=640:480,tile=2:1:2:0:0,ilpack,fil=i,scale=640:480:1,dsize -loop 0 -vo gl
As above, this could be more efficient/effective. After the tile, dimensions of the newly tiled image is 1280x480 and after the fil=i, dimensions are again 640x960 so you could have made the original scale 640:240 and it would be more efficient.
That's all for now, next let's start dipping our toes into frame-sequential page-flipping shutterglass mode.
--- iondrive ---
Lately I've been talking about making 3d slideshows from your files in various formats but what if you just want to view some images without actually making a video file? Well, that's what this post is about... using mplayer to view files without mencoding anything. Why not just use a slideshow program like sView or Tridef's or nvidia's 3d image viewer? Well, IDK, maybe they don't work right for you or something or if you're on Linux and have no better options. Anyway, onward.
For interlaced users:
Interlaced users are really blessed with some nice conveniences like not worrying about timing issues, being able to pause a video and still have it be in 3d, viewing 3d in a window or web browser, and being able to play some games that only offer interlaced mode. Anyway, regarding slideshows, if you have interlaced png files it's pretty easy and this works fine for 2d slideshows too of course.
*** The general slideshow command: (1 second / image)
mplayer -fps 1 mf://*.png" onclick="window.open(this.href);return false;
Quirk-1: driver ghosting
For interlaced images, if you see more than normal ghosting, you may need to use a different output driver since some of them do you the "favor" of de-interlacing video for you and so they harm the 3d effect. You might find a way to turn that off or just use another driver. I like the opengl output driver. Try -vo gl or else direct:noaccel. Both should work on Windows. Linux users can also try -vo x11.
Quirk-2: Last image lost
hmmm, darn, I see the last image is missing from view. I tried mf://*.png,filename.png" onclick="window.open(this.href);return false; but that didn't work. I guess if you care about the last image, then you should make a text file like list.txt or whatever you want to name it. For Windows: dir /b *.png > list.txt (or dir /b /s for full paths ) and then edit that txt file and duplicate the last entry. That will fix the problem.
*** general slideshow command using a list.txt file: (4 seconds / image)
mplayer -fps 0.25 mf://@list.txt" onclick="window.open(this.href);return false; -vo gl
Quirk-3: unresponsive keyboard controls
It seems that input is only checked in-between frames so when you play a video at 30 fps, it's fine, but if it's 0.25 fps, then most input seems ignored. If this is intolerable, then make a video file as shown before and play that instead. Unfortunately, mplayer cannot use a pair of input/output fps options like with mencoder using -fps and -ofps as that would probably fix things. There is another great solution for interlaced users though. Use -fps 25 and -loop 0 and then step through the images with the "." key. It's a nice slick, convenient solution but what's better is that an fps of 25 is the default for mf:// so you don't even need to specify it. Yay, a simpler command line.
*** user-controlled slideshow using "." to step through the images.
mplayer mf://*.png" onclick="window.open(this.href);return false; -loop 0 -vo gl
-loop 0 means loop the video continuously until you quit mplayer with "q" or escape. This means that you don't need to duplicate the last line of your list.txt file and you don't need to even make one since this method also fixes the missing last image quirk. Just use *.png. Nice. Note that when you reach the last image in the series, it behaves as if there is a second copy of it. Press "." once and the image is still the same. Press "." again and you start back at the first frame again. It's a good way to tell which frame is the last one in the series. Also note that -loop should be after the mf:// option and not before. It just works better that way.
Quirk-4: correct interlacing
if you are viewing in a window, you have a 50/50 chance of having the correct interlacing. If it's wrong, you can slide the window up/down till it's right or if you're using a CRT with an EDim controller and ED-Activator, then just use the hotkeys to flip the sync of the line-blanking. The other option is to rescale to fullscreen and then you will be able to always be in sync once you know if you need to use il=s or not. For 22" Zalman monitors:
*** Fullscreen slideshows for 22" Zalman Trimons ("." steps through images)
mplayer -vf il=s,scale=1680
1,dsize -fs mf://*.png" onclick="window.open(this.href);return false; -loop 0 -vo glJust drop the "il=s," if the lines are in the wrong place. I didn't need ilpack in my case.
Reminders:
In case you forgot, "-fs" is for fullscreen and the ":1" on the scale is to do the rescale without mixing the interlacing. Of course, you can change the numbers to change the size of your window if you don't use -fs. The dsize is important here to make sure that image alignment on your screen will match pixel for pixel. When dsize has no "=" after it, it defaults to the image's pixel dimensions which is exactly what we want here. If the interlacing is still wrong, then you just use the old ilpack,il=s, options before the scale. If you get weird colors, then drop the ilpack. Also remember that mf:// can autodetect some filetypes like png and jpg. If your input files are jps files, then you can still use them, just add -mf type=jpeg. If you have trouble remembering "mf", just think "multiple files". I think that's what it stands for but I don't really know. It's just a guess.
Side-by-side and above/below input formats:
If you have jpegs in side-by-side or above/below formats, then follow examples from previous posts regarding interlacing using "-vf fil=i" or "-vf il=i". In some cases you don't need ilpack before the il or fil but if you use it, then always follow it with a scale sometime after the il in the filter chain or else you'll get an error message. If you get some other weirdness, you may need to make sure that all your input files are the same size or aspect or that their dimensions are multiples of 16. Normally, things should just work right from the start.
using separate L and R image file-pairs as input:
For this kind of input, just follow the examples in the above posts regarding making slideshow videos. Get the files in pairs in one folder. They should all be the same size and have dimensions in multiples of 16 (800x600 screenshots need tweaking). If they are not sized right, then tile and fil may not work right. tinterlace is probably your best option. Here're some examples in case you have 800x600 separate L and R input files:
tinterlacing:
*** slideshowing separate L and R 3d image files using tinterlace ("." steps through images)
mplayer mf://*.jpg" onclick="window.open(this.href);return false; -vf tinterlace=0,scale=800:600:1,dsize -loop 0 -vo gl
tinterlace will make the images doubly tall so rescale before or after. You may need ilpack before tinterlace and then scale after. The first of each image pair will go into the odd lines and the second image will go into the even lines (top line is odd, #1). This causes the framerate to be cut in half but we're not worried about that here and the same goes for tile. Tile examples follow.
Vertical tiling:
*** tiling separate image files vertically and using il ("." steps through images)
mplayer mf://*.jpg" onclick="window.open(this.href);return false; -vf scale=640:480,tile=1:2:2:0:0,ilpack,il=i,scale=640:480:1,dsize -loop 0 -vo gl
This could be more efficient/effective but I chose the numbers for clarity. You should understand that after the tile, dimensions of the newly tiled image is 640x960 and after the il=i, it's still 640x960 so you could have made the original scale 640:240 and it would be more efficient. "fil=i" is a little trickier.
Horizontal tiling:
*** tiling separate image files horizontally and using fil ("." steps through images)
mplayer mf://*.jpg" onclick="window.open(this.href);return false; -vf scale=640:480,tile=2:1:2:0:0,ilpack,fil=i,scale=640:480:1,dsize -loop 0 -vo gl
As above, this could be more efficient/effective. After the tile, dimensions of the newly tiled image is 1280x480 and after the fil=i, dimensions are again 640x960 so you could have made the original scale 640:240 and it would be more efficient.
That's all for now, next let's start dipping our toes into frame-sequential page-flipping shutterglass mode.
--- iondrive ---
-
gyurman
- One Eyed Hopeful
- Posts: 2
- Joined: Tue Nov 15, 2011 4:08 pm
Re: Using mplayer/mencoder with 3d videos
Hello;
Sorry I can't find information, what i need to do with my mplayer,
if
I have a glass, with red and blue, and movie with left and right side. How I need to setup mine mplayer for playing. Do you can?
Could you offer me a best glass for movie with mplayer?
thanks
Sorry I can't find information, what i need to do with my mplayer,
ifI have a glass, with red and blue, and movie with left and right side. How I need to setup mine mplayer for playing. Do you can?
Could you offer me a best glass for movie with mplayer?
thanks
-
Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Using mplayer/mencoder with 3d videos
Have a look at Bino, it's a full featured 3D movie player for Linux, you won't have all the hassles with the command line :
- http://bino3d.org/" onclick="window.open(this.href);return false;
- http://bino3d.org/" onclick="window.open(this.href);return false;
-
gyurman
- One Eyed Hopeful
- Posts: 2
- Joined: Tue Nov 15, 2011 4:08 pm
Re: Using mplayer/mencoder with 3d videos
Bino is too slow.
-
iondrive
- Sharp Eyed Eagle!
- Posts: 367
- Joined: Tue Feb 10, 2009 8:13 pm
BLC detection testing using mplayer
OK well, I've been away for a while and now I've got BLC (blue-line code) on my mind so I'll post about that but first let me catch up on missed posts that are way too late to respond to. Sorry gyurman.
hi,
Hmmm, best glass/glasses for mplayer, well, it seems like most are pretty similar but I have a red/cyan pair from X3dworld that is a little better than the others because they show less ghosting for some reason. They are small like child-sized but I can fit them inbetween my eyes and my prescription glasses. They are from a credit-card sized CD case with an anaglyph Marvel Comic story that you can read on your computer. These are unfortunately hard to find. But regarding your other question. Yes, you are right, you can't really find red/blue options here so just use the red/cyan and it should still be good. So for you with a left/right video side-by-side, you would use this command:
mplayer -vf stereo3d=sbsl:arcd filename.avi
adapt as needed. If video is squeezed, use sbs2l instead of sbsl (that's a small L on the end there).
You can also change arcd to any of arcg, arch, or arcc, but I feel confident that arcd will be the best. Again, see the manpage for more details. http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt (search for stereo3d)
---
now that that's done, let's move on to testing your hardware for BLC detection using mplayer.
BLC detection test using mplayer: (Linux-friendly)
To test for BLC-detection, you could play a video file that has long and short BLC codes on alternating frames but it turns out that you can just use a tiny image file. The image is like a tiny above-below formatted video frame with appropriate BLC codes built-in. Let's call it BLC-test.png. Go ahead and download it if you want to try this. Put it in your mplayer folder or anywhere if mplayer is usable via your PATH variable.
BLC-test.png Here is the short version of the mplayer console command:
(you might want to put it in a .bat or .sh file)
*** simple BLC detection test for 1024x768 resolution. Change value of scale for other resolutions.
mplayer mf://BLC-test.png -vf il=i,tfields=0,scale=1024,dsize -fs -loop 180
Run this in the same folder as the image and watch your glasses to try and confirm any shuttering. There is a long version of the above command and the major difference is in the location of the blue lines, mid-screen or bottom. It turns out that my eDimensional dongle still gets triggered even if the blue lines are in the middle of the screen so that enabled me to make a simpler command. If you want the lines on the bottom, then see the long version below. The video is only a few seconds long and the only thing you might need to change in the command is the number 1024. This should be the current pixel-width of your screen's resolution. Either change your display to 1024x768 or change the number 1024 to whatever your screen's current width is. You should probably stick with 32 bits per pixel but I don't think that matters. This command works on my 7800GTX and even on my old geforce-2 laptop so I expect it to work for you too if you have an nVidia card although I could be wrong since I don't have all cards. Regarding ATI cards,I don't have any so I can't really be sure that it will work on them. Testers' results are welcome. Important: v-sync should be set to "on" or "application" but preferably "on".
test image properties:
right view is in the upper half, left view on bottom
blue lines are two pixels tall to make detection easier
resolution is 16x32 pixels
image is png and not jpeg since jpeg is lossy although jpeg can also work, png is more reliable.
image is not considerred squashed vertically, but only squeezed horizontally.
I started testing with a longer version of the command and trimmed it down to what still worked so if the above command doesn't work, you may want to try the longer version.
mplayer command, the long version:
*** BLC detection test for 1024x768 screen res.
mplayer mf://BLC-test.png -sws 4 -vf il=i,tfields=0,scale=1024:16,expand=1024:768:0:752,dsize -vo gl -fs -loop 180 -fps 60
Explanation:
mf://BLC-test.png --> this is how you input an image file as if it were a video frame.
-sws 4 --> this chooses a point-scaler that does not blend neighboring pixels when you stretch the image.
-vf --> start listing video filters
il=i --> "interlace" turns above/below stereo format into interlaced format
tfields=0 --> turns interlaced format into frame sequential format with half-height res (16x32-->16x16) at twice the frame-rate.
scale=1024:16 --> stretches image horizontally (16x16-->1024x16)
expand=1024:768:0:752 --> fill/pad screen vertically with black while positioning blue lines on bottom of screen (768-16=752)
dsize --> do not do any aspect fixes. make output video same as current video image res (1024x768).
-vo gl --> try to use OpenGL display pipeline. More reliable for this test than directx. Try directx if you want.
-fs --> show video in fullscreen mode
-loop 180 --> this loops the video (image in this case) 180 times.
-fps 60 --> this sets the frames per second input rate to 60. This value should be fine even if you're not at 60 Hz as long as vsync is on and your display is not more than 120 Hz. If unsure, set it to half your true refresh rate since output rate should be doubled via tfields=0
For other resolutions, you have to change the numbers to match your res...
*** BLC detection test for 1920x1080 screen res.
mplayer mf://BLC-test.png -sws 4 -vf il=i,tfields=0,scale=1920:16,expand=19200:1064,dsize -vo gl -fs -loop 180 -fps 60
That's it for now.
--- iondrive ---
hi,
Hmmm, best glass/glasses for mplayer, well, it seems like most are pretty similar but I have a red/cyan pair from X3dworld that is a little better than the others because they show less ghosting for some reason. They are small like child-sized but I can fit them inbetween my eyes and my prescription glasses. They are from a credit-card sized CD case with an anaglyph Marvel Comic story that you can read on your computer. These are unfortunately hard to find. But regarding your other question. Yes, you are right, you can't really find red/blue options here so just use the red/cyan and it should still be good. So for you with a left/right video side-by-side, you would use this command:
mplayer -vf stereo3d=sbsl:arcd filename.avi
adapt as needed. If video is squeezed, use sbs2l instead of sbsl (that's a small L on the end there).
You can also change arcd to any of arcg, arch, or arcc, but I feel confident that arcd will be the best. Again, see the manpage for more details. http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.txt (search for stereo3d)
---
now that that's done, let's move on to testing your hardware for BLC detection using mplayer.
BLC detection test using mplayer: (Linux-friendly)
To test for BLC-detection, you could play a video file that has long and short BLC codes on alternating frames but it turns out that you can just use a tiny image file. The image is like a tiny above-below formatted video frame with appropriate BLC codes built-in. Let's call it BLC-test.png. Go ahead and download it if you want to try this. Put it in your mplayer folder or anywhere if mplayer is usable via your PATH variable.
BLC-test.png Here is the short version of the mplayer console command:
(you might want to put it in a .bat or .sh file)
*** simple BLC detection test for 1024x768 resolution. Change value of scale for other resolutions.
mplayer mf://BLC-test.png -vf il=i,tfields=0,scale=1024,dsize -fs -loop 180
Run this in the same folder as the image and watch your glasses to try and confirm any shuttering. There is a long version of the above command and the major difference is in the location of the blue lines, mid-screen or bottom. It turns out that my eDimensional dongle still gets triggered even if the blue lines are in the middle of the screen so that enabled me to make a simpler command. If you want the lines on the bottom, then see the long version below. The video is only a few seconds long and the only thing you might need to change in the command is the number 1024. This should be the current pixel-width of your screen's resolution. Either change your display to 1024x768 or change the number 1024 to whatever your screen's current width is. You should probably stick with 32 bits per pixel but I don't think that matters. This command works on my 7800GTX and even on my old geforce-2 laptop so I expect it to work for you too if you have an nVidia card although I could be wrong since I don't have all cards. Regarding ATI cards,I don't have any so I can't really be sure that it will work on them. Testers' results are welcome. Important: v-sync should be set to "on" or "application" but preferably "on".
test image properties:
right view is in the upper half, left view on bottom
blue lines are two pixels tall to make detection easier
resolution is 16x32 pixels
image is png and not jpeg since jpeg is lossy although jpeg can also work, png is more reliable.
image is not considerred squashed vertically, but only squeezed horizontally.
I started testing with a longer version of the command and trimmed it down to what still worked so if the above command doesn't work, you may want to try the longer version.
mplayer command, the long version:
*** BLC detection test for 1024x768 screen res.
mplayer mf://BLC-test.png -sws 4 -vf il=i,tfields=0,scale=1024:16,expand=1024:768:0:752,dsize -vo gl -fs -loop 180 -fps 60
Explanation:
mf://BLC-test.png --> this is how you input an image file as if it were a video frame.
-sws 4 --> this chooses a point-scaler that does not blend neighboring pixels when you stretch the image.
-vf --> start listing video filters
il=i --> "interlace" turns above/below stereo format into interlaced format
tfields=0 --> turns interlaced format into frame sequential format with half-height res (16x32-->16x16) at twice the frame-rate.
scale=1024:16 --> stretches image horizontally (16x16-->1024x16)
expand=1024:768:0:752 --> fill/pad screen vertically with black while positioning blue lines on bottom of screen (768-16=752)
dsize --> do not do any aspect fixes. make output video same as current video image res (1024x768).
-vo gl --> try to use OpenGL display pipeline. More reliable for this test than directx. Try directx if you want.
-fs --> show video in fullscreen mode
-loop 180 --> this loops the video (image in this case) 180 times.
-fps 60 --> this sets the frames per second input rate to 60. This value should be fine even if you're not at 60 Hz as long as vsync is on and your display is not more than 120 Hz. If unsure, set it to half your true refresh rate since output rate should be doubled via tfields=0
For other resolutions, you have to change the numbers to match your res...
*** BLC detection test for 1920x1080 screen res.
mplayer mf://BLC-test.png -sws 4 -vf il=i,tfields=0,scale=1920:16,expand=1920
0:1064,dsize -vo gl -fs -loop 180 -fps 60That's it for now.
--- iondrive ---
You do not have the required permissions to view the files attached to this post.