thethrillness.blogspot.com
What you should do to check is change the frame rate to 29.97 in VDub and use that new source to identify if it is a problem with the frame rate or a Yua programming error.
can you post a source file?
SDA Forum
Fucking Weeaboo
Here's the raw footage. I've been playing around with a bunch of things in VirtualDub with AVS files and have generally ended up with stuff either being too fast or with footage duplicated (thankfully at the end) but no perfect encodes so far.
Mainly using my Xenosaga videos for test encodes on my end, since they have the same issue (480i component at 59.94fps).
Edit: I finally got an encode to go right, but it took me to do the following:
Load a file through AVS where I ran this line:
assumeFPS(30000, 1001, false)
Then told VDub to process every other frame and reencode the video (I did it lossless but I will play around with just direct stream copy later).
Then told Yua to cut off the last half of the video.
Yeah, it shouldn't take that much effort.
Mainly using my Xenosaga videos for test encodes on my end, since they have the same issue (480i component at 59.94fps).
Edit: I finally got an encode to go right, but it took me to do the following:
Load a file through AVS where I ran this line:
assumeFPS(30000, 1001, false)
Then told VDub to process every other frame and reencode the video (I did it lossless but I will play around with just direct stream copy later).
Then told Yua to cut off the last half of the video.
Yeah, it shouldn't take that much effort.
Attachment:
Fucking Weeaboo
You're right...kinda.
The video does indeed encode properly...if there is no statID. As soon as I put it in, BOOM. Instant audio desync. Everything else has the exact same settings, all I did was just turn on the statID. I tried encoding with my own personal statID and with the built in SDA one.
I hear something though in the statID initial audio at about 3 seconds in. Sounds like a "thupt" (honestly, that's the best way I can describe it) and something with that is causing the audio to start before the video. I guess anyways.
The video does indeed encode properly...if there is no statID. As soon as I put it in, BOOM. Instant audio desync. Everything else has the exact same settings, all I did was just turn on the statID. I tried encoding with my own personal statID and with the built in SDA one.
I hear something though in the statID initial audio at about 3 seconds in. Sounds like a "thupt" (honestly, that's the best way I can describe it) and something with that is causing the audio to start before the video. I guess anyways.
0-10
I will now officially request PSP aspect ratio support. The system outputs at 480x272, which isn't 16:9.
I've made a couple of comparison videos for you guys. The first is with Yua, with "Widescreen" selected under aspect ratio. The video playback properties say that the ratio is 251:120.
The second is with Anri-chan, with 3:2 aspect ratio set.
Here is a 10-second source file in case you guys want to muck with anything to confirm any kinds of settings.
I've made a couple of comparison videos for you guys. The first is with Yua, with "Widescreen" selected under aspect ratio. The video playback properties say that the ratio is 251:120.
The second is with Anri-chan, with 3:2 aspect ratio set.
Here is a 10-second source file in case you guys want to muck with anything to confirm any kinds of settings.
PSP is 16x9. http://en.wikipedia.org/wiki/PlayStation_Portable#Technical_specifications
What's causing this mess is the canvas seems to be 720x480 but with a non-stretched 480x272 picture in the center. This is atypical as far as I'm aware - usually 720x480 need to be stretched out to display at 856x480 (16x9), or shrunk down to 640x480 (4x3). However in your case you actually don't want any stretching/shrinking whatsoever. That's why specifying 3:2 (equivalent to 720:480) works in Anri, but once you crop it changes everything; cropping down to 480x272 yields a 16x9 SAR&DAR with 1:1 PAR.
I'm guessing this is interlaced material? (otherwise a progressive encode wouldn't mess with the aspect ratio in this way) If it's interlaced, I can see this as a Yua bug in that you can't choose interlaced + non 16/9 or 4:3.
What's causing this mess is the canvas seems to be 720x480 but with a non-stretched 480x272 picture in the center. This is atypical as far as I'm aware - usually 720x480 need to be stretched out to display at 856x480 (16x9), or shrunk down to 640x480 (4x3). However in your case you actually don't want any stretching/shrinking whatsoever. That's why specifying 3:2 (equivalent to 720:480) works in Anri, but once you crop it changes everything; cropping down to 480x272 yields a 16x9 SAR&DAR with 1:1 PAR.
I'm guessing this is interlaced material? (otherwise a progressive encode wouldn't mess with the aspect ratio in this way) If it's interlaced, I can see this as a Yua bug in that you can't choose interlaced + non 16/9 or 4:3.
0-10
Quote from ballofsnow:
Huh, learn something new.
Quote:
I'm guessing this is interlaced material? (otherwise a progressive encode wouldn't mess with the aspect ratio in this way) If it's interlaced, I can see this as a Yua bug in that you can't choose interlaced + non 16/9 or 4:3.
This particular material is progressive.
Now I'm curious about something. Amarec has cropping support, and has a preset for PSP. I've been hesitant in using it because I don't want to screw anything up with a source file. If that is shot, the video is dead and it'll just be depressing/etc. That's why I've been recording with the extreme letterbox, in other words no cropping, because it's easy enough to crop for processing.
But for a test, I set Amarec to use its built-in cropping. I dumped the properties of both the source video and this new one:
Code (previous_source):
General Format : AVI Format/Info : Audio Video Interleave File size : 143 MiB Duration : 10s 944ms Overall bit rate : 109 Mbps Video ID : 0 Format : Lagarith Codec ID : LAGS Duration : 10s 944ms Bit rate : 103 Mbps Width : 720 pixels Height : 480 pixels Display aspect ratio : 3:2 Frame rate : 59.940 fps Standard : NTSC Bits/(Pixel*Frame) : 4.992 Stream size : 135 MiB (95%) Audio ID : 1 Format : PCM Format settings, Endianness : Little Format settings, Sign : Signed Codec ID : 1 Duration : 10s 944ms Bit rate mode : Constant Bit rate : 1 536 Kbps Channel(s) : 2 channels Sampling rate : 48.0 KHz Bit depth : 16 bits Stream size : 2.00 MiB (1%) Alignment : Aligned on interleaves
Code (Amarec_crop):
General Format : AVI Format/Info : Audio Video Interleave File size : 2.75 GiB Duration : 5mn 42s Overall bit rate : 69.0 Mbps Video ID : 0 Format : Lagarith Codec ID : LAGS Duration : 5mn 41s Bit rate : 64.8 Mbps Width : 480 pixels Height : 272 pixels Display aspect ratio : 16:9 Frame rate : 59.940 fps Bits/(Pixel*Frame) : 8.274 Stream size : 2.58 GiB (94%) Audio ID : 1 Format : PCM Format settings, Endianness : Little Format settings, Sign : Signed Codec ID : 1 Duration : 5mn 42s Bit rate mode : Constant Bit rate : 1 536 Kbps Channel(s) : 2 channels Sampling rate : 48.0 KHz Bit depth : 16 bits Stream size : 62.6 MiB (2%) Alignment : Aligned on interleaves
I did a test encode with Yua with the crop file, and it looks like the output should. Although the video properties shouldn't be saying 119.88 FPS. Dissidia is F2, and I set that in Yua for this test. Not sure what happened there.
Here's a source file that was recorded cropped with Amarec.
0-10
Quote from ballofsnow:
"source 2.avi" through yua seems fine to me with the settings you chose. I don't know where you're seeing ~120 fps.
Download this test encode and check the properties, it says it's 119.88 FPS.
I re-encoded that same source clip with Yua with the exact same settings: D1 F2 3D, and this time the video is 29.97 FPS. In both cases, "Aspect ratio" was checked and "Widescreen" was selected.
I did. Looks fine.
Code:
General Complete name : Dissidia test3_IQ.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom File size : 7.42 MiB Duration : 19s 370ms Overall bit rate mode : Variable Overall bit rate : 3 214 Kbps Encoded date : UTC 2014-11-18 20:13:56 Tagged date : UTC 2014-11-18 20:13:56 Comment : yua7 d1 f2 3d progressive 16:9 IQ Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:2:2@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 4 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 19s 252ms Source duration : 19s 278ms Bit rate : 2 911 Kbps Maximum bit rate : 5 670 Kbps Width : 480 pixels Height : 272 pixels Display aspect ratio : 16:9 Original display aspect ratio : 16:9 Frame rate mode : Variable Frame rate : 29.620 fps Minimum frame rate : 7.493 fps Maximum frame rate : 29.970 fps Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.753 Stream size : 6.68 MiB (90%) Source stream size : 6.68 MiB (90%) Writing library : x264 core 142 r2453 ea0ca51 Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 Tagged date : UTC 2014-11-18 20:13:56 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : 40 Duration : 19s 370ms Bit rate mode : Variable Bit rate : 317 Kbps Maximum bit rate : 325 Kbps Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 KHz Compression mode : Lossy Stream size : 750 KiB (10%) Title : Ip4236a.aac@GPAC0.5.1-DEV-rev4375M Encoded date : UTC 2014-11-18 20:13:56 Tagged date : UTC 2014-11-18 20:13:56
Is there any way to make Yua store its temp files on a second HD? It crashes, apparently due to running out of space on my main SSD, when I try to encode a video I recorded. This was asked early in the thread, but I didn't find an answer.
If not, can you estimate how much space I would need? The source is a 1:42:26 29.8 GB (27.7 in powers-of-2 metric misuse) H.264 mp4 recorded with nVIDIA ShadowPlay.
If not, can you estimate how much space I would need? The source is a 1:42:26 29.8 GB (27.7 in powers-of-2 metric misuse) H.264 mp4 recorded with nVIDIA ShadowPlay.
Quote from Sir VG:
Here's the raw footage.
finally had a chance to look at this. i did replicate it. best guess is it has to do with the input having 2 ticks_per_frame and/or marking the timebase as ~119.88011988011988 fps. so even if you factor in the 2 ticks_per_frame the framerate is still wrong. it's like someone hit the wrong button when that thing was being made or something.
i'd love to say i could do something about it but the situation is just really complicated. yua is such a beast when it comes to framerate and i'm very hesitant to change anything now that it has such good coverage of so many cases. it's especially frustrating because it seems that the only real fallout is the transition from the statid, because the statid's timestamps are wacked because of the bad assumption about the input. thinking about it now i think in order to fix this i would need to put in "force framerate". but that isn't as simple as it sounds because of how yua accepts input with any framerate for appending and is a vfr encoder.
curious - did you try changefps(last.framerate/4) in avisynth? does that make it play at the wrong speed and that's why you used assumefps()? that *would* be consistent with the framerate being outright wrong in the original.
Quote from Lenophis:
Clicking over to the MediaInfo tab, however, says exactly what you pasted. I don't know why they would be reporting differently. *shrug*
probably different ways of supporting variable framerate material. i could speculate further but there's no point.
Quote from NMS:
I think I solved my problem by changing my TMP environment variable to a location on my second hard drive. Still, it would be nice if Yua handled this more gracefully.
nice workaround. especially since you got it working this way i'm reluctant to include this in the ui since so few people will use it. my thinking was probably that the maximum amount of space you would need is a few gigabytes and i didn't want to get into dealing with checking people's supplied paths (it is on a disconnected network share -> yua freezes -> why!?).
My encoding did eventually succeed. I was away, but based on reports from someone who was home, it may have taken multiple days to encode all qualities on my 3.4 GHz quad-core i5. I'll have to see if more compressed ShadowPlay files encode faster. I tried setting the bitrate target to the SDA goal, but it didn't hit it very well, so I figured the sensible thing was to encode at max in real time and then do a proper two-pass final encode on anything I want to submit.
How hard would it be to add GPU acceleration to Yua? Given that my GTX 760 can do a decent encoding job in real time while running a game, there's obviously a big performance advantage. Edit: Looks like it could be done with OpenCL for cross-platform compatibility, but I guess you'd have to rewrite the actual encoding code, which you didn't write in the first place, so that's probably out.
Based on how quickly my disk was filling, the temporary files may have ended up being over 20 GB by the end of the first XQ pass.
By gracefully, I meant it would be good to notify the user that encoding failed due to running out of disk space and clean up the files (unless you can reuse them), rather than crashing and leaving the disk full.
How hard would it be to add GPU acceleration to Yua? Given that my GTX 760 can do a decent encoding job in real time while running a game, there's obviously a big performance advantage. Edit: Looks like it could be done with OpenCL for cross-platform compatibility, but I guess you'd have to rewrite the actual encoding code, which you didn't write in the first place, so that's probably out.
Based on how quickly my disk was filling, the temporary files may have ended up being over 20 GB by the end of the first XQ pass.
By gracefully, I meant it would be good to notify the user that encoding failed due to running out of disk space and clean up the files (unless you can reuse them), rather than crashing and leaving the disk full.
ah yeah that's true.
yeah i don't want to use gpu encoding because the performance difference with x264 is going to come with lower quality output in some cases. the gpu encoders are just so all over the board when it comes to quality. it may be slow right now but at least you can be sure you're getting the same quality as anyone else.
apologies if you already mentioned, but what were the stats on the input of this long encode? duration, framerate and dimensions primarily? it's not every day that i see a 20 gb output file.
yeah i don't want to use gpu encoding because the performance difference with x264 is going to come with lower quality output in some cases. the gpu encoders are just so all over the board when it comes to quality. it may be slow right now but at least you can be sure you're getting the same quality as anyone else.
apologies if you already mentioned, but what were the stats on the input of this long encode? duration, framerate and dimensions primarily? it's not every day that i see a 20 gb output file.
Dapper as fuck.
So.. not sure why, but when I made a video for Quality Test for Phantasy Star 2, when I add statid it tacks the statid on the front AND the end of the video. If I leave statid off it encodes fine. Other than the extra statid it doesn't seem like anything else is out of whack. Attached is the statid example (PS2AnyE), and the non-statid example (PS2AnyE-3). The raw video is here: https://www.dropbox.com/s/tgf0rb6rw1jr1j8/PhantasyStar2QT-Final.avi?dl=0
Quote from ballofsnow:
Another potential workaround for the temp directory is to run Yua in Sandboxie. You'd change the sandbox container folder to a different drive and then whatever Yua writes out will be contained within that sandbox.
An option to set the temp folder i.e. via command line might be useful.