I can't remember what the levels are, but there must be something for 1080p30. It's beyond that where it gets hairy. Maybe finally constrain xq and make up the next quality version? RQ for ridiculous quality or something. 1440p or 1600p will come eventually. But it's probably impractical to split 1080p30 and 1080p60... Random thoughts for now
SDA Forum
Edit history:
ballofsnow: 2013-04-02 11:13:00 am
ballofsnow: 2013-04-02 11:10:54 am
ballofsnow: 2013-04-02 11:10:32 am
ballofsnow: 2013-04-02 10:52:51 am
ballofsnow: 2013-04-02 10:51:41 am
Quote from UraniumAnchor:
I'd be surprised if quicktime really cared about the level that much, but 4.1 isn't technically able to display 1080p at 60fps, you need 4.2 for that. Past that, not sure.
Ah yes I remember now. 4.1 was our goal a while back for PS3/Xbox but then realized 1080p60 needs higher, so we abandoned the idea. Actually that wasn't the direct reason, but it didn't help.
Quote from nate:
problem is that quicktime x is refusing to decode the resulting video. definitely need to check that constraining non-mq to level 4.1 as i've done for alpha 6 doesn't break 1080p+ encodes. 4.1 is bluray so there shouldn't be any problem but who knows. maybe i should just make xq unconstrained and say screw quicktime/hardware decoders for it.
iirc, x264 can auto-level, i.e. it detects the appropriate level based on the input and settings. Is Anri producing =<4.1 for the videos you're testing and that's why they work? Or am I misreading and the anri vids aren't working either?
For example, I just ran a 1600x900p@30 into anri 3.3 and got:
LQ 2.1
MQ 1.3
HQ 3.1
IQ 4.0
XQ 4.0
mediainfo of input:
Code:
General Complete name : Z:\FrapsCap\captureshort.avi Format : AVI Format/Info : Audio Video Interleave File size : 237 MiB Duration : 10s 0ms Overall bit rate : 199 Mbps Writing library : VirtualDub build 32842/release Video ID : 0 Format : Fraps Codec ID : FPS1 Duration : 10s 0ms Bit rate : 197 Mbps Width : 1 600 pixels Height : 900 pixels Display aspect ratio : 16:9 Frame rate : 30.000 fps Bits/(Pixel*Frame) : 4.562 Stream size : 235 MiB (99%) Audio ID : 1 Format : PCM Format settings, Endianness : Little Format settings, Sign : Signed Codec ID : 1 Duration : 10s 0ms Bit rate mode : Constant Bit rate : 1 536 Kbps Channel(s) : 2 channels Sampling rate : 48.0 KHz Bit depth : 16 bits Stream size : 1.83 MiB (1%) Interleave, duration : 35 ms (1.05 video frame) Interleave, preload duration : 500 ms
Keep in mind IQ "720p" actually gets resized to 1368x768 coming down from a 1080p file.
Another:
1920x1080p@30 input
LQ 2.1
MQ 1.3
HQ 3.1
IQ 4.0
XQ 5.0
Interesting that XQ went to 5.0, and didn't stay at 4.1. If I were to force 4.1, I wonder if it would complain.
And one more:
1920x1080p@60 input
LQ 2.1
MQ 1.3
HQ 3.1
IQ 4.2
XQ 5.0
One last thing, the version of x264 in anri 3.3 is pretty old now, so auto leveling may have improved.
Quote from hokorippoi:
I think it was talked about some where in here, but anything can be done about the small time difference?
Time:
Fraps = 2:29:56
LQ Yua = 2:30:06
LQ anrichan3.3 = 2:29:56
10 secs is not much for hours log run, and Yua is not finished, so not for fished runs anyway. Just wanted to point it out.
Time:
Fraps = 2:29:56
LQ Yua = 2:30:06
LQ anrichan3.3 = 2:29:56
10 secs is not much for hours log run, and Yua is not finished, so not for fished runs anyway. Just wanted to point it out.
thanks for reporting this. unfortunately i would need the original video to figure out why this is happening. i also changed some stuff involving timestamps in alpha 6 (not released yet) so it may be different now.
anri's output is always fine. i think the autoleveling actually got "worse" (or maybe more accurate in some subtle way) with the new version of x264 i'm using because i was getting 5.1 from mq. it's also possible libx264 isn't being given all the info it needs or otherwise inaccurate info before making the decision. that's ffmpeg and it's a clusterfuck. in any case this would be easy - we could just constrain to 1.3 for mq, 4.1 for everything else, except that xq can easily be more demanding than 4.1. i don't like the idea of making another quality. i also don't like the idea of making xq unconstrained but i like it more than adding another quality.
Levels are typically overrated. Many platforms (except PCs, obviously) state they can handle a certain level + resolution, but even given that, some files still refuse to work.
Trying to get compatibility with mobile platforms is difficult at best. Though I think many platforms today can handle 720p with few bframes and ref frames. 1080p is mostly just anyone's guess.
Trying to get compatibility with mobile platforms is difficult at best. Though I think many platforms today can handle 720p with few bframes and ref frames. 1080p is mostly just anyone's guess.
released alpha 6:
- fixed interlaced rgb (thanks snow)
- fixed spurious cfr -> vfr (thanks israelird)
- tweaked statid text to better resemble the output of anri ... still pretty gross under windows though
- throttled the preview display and the progress bar to a maximum of one update per second during encoding
- trimming. the ui isn't done yet. only two points right now. try it out and let me know. thanks.
didn't get a chance to look at the crashes under windows yet. still getting settled in to my new system.
if you don't specify an option, yua will decide for you.
--d1, --d4
--f1, --f2, --f3
--2d, --3d
--interlaced, --progressive
--bff, --tff
--mono
--widescreen
--input=filename
--qualities=lmhix any or all of the letters
--output-basename=basename e.g. Mario1_459
--statid encode with statid
--statid1="my name" first statid line
--statid2="game name" second statid line
--statid3="time" third statid line
e.g.
--d1, --d4
--f1, --f2, --f3
--2d, --3d
--interlaced, --progressive
--bff, --tff
--mono
--widescreen
--input=filename
--qualities=lmhix any or all of the letters
--output-basename=basename e.g. Mario1_459
--statid encode with statid
--statid1="my name" first statid line
--statid2="game name" second statid line
--statid3="time" third statid line
e.g.
Code:
./Yua --input=/down/test/genesis2.vob --d4 --f1 --2d --qualities=hml --output-basename=TJE2
- fixed interlaced rgb (thanks snow)
- fixed spurious cfr -> vfr (thanks israelird)
- tweaked statid text to better resemble the output of anri ... still pretty gross under windows though
- throttled the preview display and the progress bar to a maximum of one update per second during encoding
- trimming. the ui isn't done yet. only two points right now. try it out and let me know. thanks.
didn't get a chance to look at the crashes under windows yet. still getting settled in to my new system.
The Dork Knight himself.
Ok, so I tested out the trimming, and it does work pretty reliably. I have noticed something that probably has to do with the different deinterlace/resize filters used in Yua compared to Anri: using the same footage gives a really blurry image in Yua but Anri is as clear as the source.
The Dork Knight himself.
Here's another sample to try out. It might just be a false alarm though, cause at the time I noticed it I had 2 players open side by side to make sure that both the anri and yua videos were perfectly sync'd (which they are) and that's when I noticed the Yua vid was slightly blurry. So it could simply be a player problem and not necessarily a Yua problem. I was thinking that, since the video is 720x480 resized to 320x240 for the HQ encodes that maybe recording the source at 640x480 would minimize resizing artifacts since it would be a perfect 1/2 resize instead of a 720 to 320 resize.
jay i'm actually having trouble checking on this resizing/colorspace conversion issue. i added a screenshot function post-alpha 6 and the screenshots came out pretty well i think. this is after conversion from whatever the colorspace of the input is to rgb which yua uses internally and before the conversion to yv12 for output. there should be no other conversions. all of the conversions are ffmpeg libswscale with the exception of interlaced yv12 source material which is handled by manao's avisynth 3 code. the resize to d4 happens after the colorspace conversion to rgb and it's ffmpeg's libswscale SWS_LANCZOS, whatever that is. i picked that one because it seemed the most similar to the avisynth one anri uses, at least in name. there is actually at least one issue i've been meaning to check with d4 content - i'm not quite happy with it yet either. check out around knuckles's sprite in the last attached screenshot. there's some kind of weird sharp edges, almost like blocking from a lossy video codec but this is a lossless source. there's a slope changing at a rate of two pixels when it seems like it should be only one. i'm not sure if this is the source material or something i'm doing because i haven't had the time to encode the test clip with anri and look at it.
The Dork Knight himself.
Nate: don't worry about my problem with Batman. I'm gonna chalk it up to a fluke for now unless someone else has the same issue. After I uploaded that video I didn't have any other video come out as blurry so I'm going to assume that it was just from MPC being stupid. Further proof is that when I watched the video again it wasn't blurry anymore, further proof that MPC and side-by-side comparison isn't reliable (sorry to waste your time).
One thing I was looking to test was whether or not it's best to resize the final video to the native resolution of the console itself (start with 640x480 cap, field split, resize to 320x240) or do line doubling to increase the resolution to match the original capture (start with 640x480, field split, double each 240 line to 480, encode 640x480 as base resolution for nmf). I just picked up a decent s-Video cable for my Wii, and after comparing footage from my Genesis (composite) to the Wii (s-vid) I'm almost convinced that not resizing down from 640x240 (after field splitting) to 320x240 would yield a clearer video.
I'm attaching the finished log file and the HQ.avs file for reference. If someone knows how to edit that to add in a quick and dirty line doubling effect (with possibly a 1 pixel field bob to compensate) I'd appreciate it. If this really isn't the best place to discuss this, just delete my post and I'll send a PM. What I'm hoping for is a good comparison for native video resolutions vs captured resolutions when it comes to encoding runs.
One thing I was looking to test was whether or not it's best to resize the final video to the native resolution of the console itself (start with 640x480 cap, field split, resize to 320x240) or do line doubling to increase the resolution to match the original capture (start with 640x480, field split, double each 240 line to 480, encode 640x480 as base resolution for nmf). I just picked up a decent s-Video cable for my Wii, and after comparing footage from my Genesis (composite) to the Wii (s-vid) I'm almost convinced that not resizing down from 640x240 (after field splitting) to 320x240 would yield a clearer video.
I'm attaching the finished log file and the HQ.avs file for reference. If someone knows how to edit that to add in a quick and dirty line doubling effect (with possibly a 1 pixel field bob to compensate) I'd appreciate it. If this really isn't the best place to discuss this, just delete my post and I'll send a PM. What I'm hoping for is a good comparison for native video resolutions vs captured resolutions when it comes to encoding runs.
it is the place to discuss it. i've thought about it many times but it's never been clear to me what to do about the height. with simple line doubling it looks quite pixelated ... and it is now some kind of weird video that can't be encoded as efficiently. the encoder may notice that every two lines are the same, but what about the width? theory was always that there is in fact no more information than the equivalent of 320 pixels, so that's what the encoder should be given.
for line doubling you can probably just get the width to where you want with lanczos and then switch to pointresize for the height. you will probably see what i mean about the pixelation.
there's also weird stuff to look at if you view d4 stuff as d1 in yua. there is bobbing because it's not expecting the lines to be the same. i could change that of course but again i do not see the point. sda attitude has always been "let them do it on playback".
for line doubling you can probably just get the width to where you want with lanczos and then switch to pointresize for the height. you will probably see what i mean about the pixelation.
there's also weird stuff to look at if you view d4 stuff as d1 in yua. there is bobbing because it's not expecting the lines to be the same. i could change that of course but again i do not see the point. sda attitude has always been "let them do it on playback".