Posts for Aktan

1 2 3 4 5
49 50
Posted: 8/7/2018 7:33 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
creaothceann wrote:
Which is ideal for framerates close to 60 fps, e.g. the SNES.
You should specify that, since my first thought was like DooM 35 FPS =p.
Posted: 8/6/2018 4:45 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
creaothceann wrote:
Video framerates can be capped without frame loss with AssumeFPS, there's also a parameter that syncs the sample rate.
That just makes the video play faster or slower.
Posted: 8/4/2018 10:12 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
The problem with your suggestion is that there is no guarantee that YouTube will indeed re-encode all the source files nor keep all those files. Imagine if YouTube has to do that every time they change. That doesn't mean just our files, but all files sent to YT. I believe what you saw was YouTube only re-encoding videos uploaded after a certain point, but not all videos.
Posted: 4/8/2018 12:44 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Evil_3D wrote:
Is there a quick guide in video on how to do a official encode? my english and scripting is limited to understand some things in the actual guide
Sorry, there is not. I would think that a video is harder to understand as it be spoken English vs written where you could copy and paste a text and translate it.
Posted: 2/12/2018 10:30 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Well the other option is move to VapourSynth which has native support for Linux
Posted: 2/11/2018 11:31 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
So we're moving to AVS+ 64-bit? =D
Posted: 2/3/2018 8:23 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
direct264 is very old and outdated. I guess if you want a GUI of some sort, something like Handbrake would be better. https://handbrake.fr/
Posted: 2/1/2018 6:11 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Nice work! I was going to say we need to test what colorspace YT goes to anyway, but you kind of beat me to it. I'll take a closer look at the results in a bit. Edit: After reading more on it, you may need to change the color bit to 10-bit in AVS+. After all BT.2020 color range is greater than BT.709 and needs higher bit, which is 10-bit or 12-bit. Edit 2: Doing a ton more reading (this is interesting after all), I found out there is no need for us to go to BT.2020 as sRGB (RGB) has the same color primaries as BT.709 but slightly different transfer (gamma) functions while converting the BT.2020 is very different and difficult. I also found out that UHD can use BT.709 anyway, so it's fine. I guess the focus of this thread is now more towards if we should move to AVS+.
Posted: 2/1/2018 5:37 AM
Post subject: BT.2020 Colorspace and AVS+
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
So I was doing some VHS captures and was suck back into colorspace hell, when I noticed that we are not using the correct colorspace for our 4K videos. That's BT.2020. https://en.wikipedia.org/wiki/Rec._2020. Unfortunately, or maybe fortunately, we would need to move to AVS+ to get this conversion. I think AVS+ is stable enough to move towards. It even comes with 64-bit support! 64-bit plugins are a problem, but most commonly used plugins are now available. Thoughts?
Posted: 1/22/2018 2:37 AM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Reeve wrote:
Had to use 59450/1001 for it to match the emulator file lenght. With 60000/1001 it gives me a 10 seconds faster video than the emulator file. I wonder what's right, the gotvg emulator time, the 10 seconds slower time I got with the video encode or the 10 seconds faster file avisinth gave me. Thanks for the help.
No problem
Posted: 1/17/2018 1:30 AM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Reeve wrote:
Arcade's Alien Vs Predator. Edit: I may have done something wrong when trying to convert the file to avi when I first tried. I managed to do it now, but the result is still the same, a final video that is 10 seconds longer than the original file. I also tried mov and the result is the same, so all 4 possible formats give me the same result.
I couldn't find what the native frame rate of a CP System II game is, but assuming what you said it correct, it should probably be 60000/1001. You can use AviSynth to change it to that using the AssumeFPS() function with audio change set to true.
Posted: 1/13/2018 10:14 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Reeve wrote:
I tried MP4 and FLV. For some reason AVI does not work, because the final video skips/miss frames (Have no idea why), so the only other option left to test is MOV.
What game were you playing?
Posted: 1/13/2018 5:28 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Reeve wrote:
Hey, Guys! So, here goes a question: There's an online emulator called gotvg and it records the inputs while you're playing and generates a file. There's a feature that allows you to convert the file to 4 different video formats: avi, flv, mov or mp4. Thing is, I have a file that is 24 minutes and 24 seconds long, but when I convert the file it ends up beeing a 10 seconds longer video file. It's like the video file is 59,5 fps instead of the 60fps that the recorded input file is.Do you guys know if this has something to do with my codec pack or if it's just the emulator settings that does this? My issue with this is that I'm recording speedruns while playing online, and a final time that should be 23:25 seems like a 23:35 in the video file. Edit: I tried two different video formats and the result is around the same.
What file did you output to? AVI, FLV, MOV, or MP4?
Posted: 12/28/2017 1:17 AM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I would still say test, if you got time, as maybe YouTube does better than we think.
Posted: 12/28/2017 12:54 AM
(Edited: 12/28/2017 1:27 AM)
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
If we send 4:4:4, YouTube would resample to 4:2:0 for us. That gives us less control for the max res encode on chroma. I can see your argument that it will give a better source to do the resize and resample for the other resolutions, but the chroma bleeding at max res is minimal and it should be fine to resize off of that. For example, a max res of 2880x2160 would have chroma res be 1440x1080. Resizing to 1080p, the luma would resize to 1440x1080 and the chroma will be resized to 720x540. Basically 1/4th for both luma and chroma. If the file was 4:4:4, the resize would be from 2880x2160 to 720x540 for chroma. 1/8th the size. I don't think there be much difference. Bottom line is, I don't think there be any potential to look worse as the resize ratio using a 4:2:0 source would always be the same. Problem with sending 3584x2688 is that we know YT will resize it to it's standard resolutions and I rather have more control. Plus the fact of straight resize to 4K is a bit sharper (at the cost of inconsistent pixel sizes). If you want, you can do a comparison. We did send that res in the past, and I thought it was the best until I realized we have less control.
Posted: 12/1/2017 2:22 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Keep up the good work! Hope you continue one day.
Posted: 10/8/2017 9:54 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
The thing is, it is never a waste, people will always come and go. Look at it another way, you might miss people in the past, but there are so many other people in the world you have not met that could give you good memories! The 5 years is not a waste because you learn and grew during those 5 years. Nothing can take that away from you.
Posted: 9/28/2017 2:10 AM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283 
ffmpeg -i <in> -acodec copy -vcodec ffv1 -level 1 -pix_fmt bgr0 -g 1 -coder 1 -context 1 <out>
Edit: A FFV1 Version 1 VfW decoder is ffdshow. You will need to install that to use AVISource.
Posted: 9/27/2017 2:39 AM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I have not tested it so I can't comment, honestly. I just know of FFMS2 problems. Edit: I think a good test is to do a compare of the output from LSMASHSource and FFMPEG with lossless FFV1 level 1. If they match completely, then it would be pretty safe to say LSMASHSource is a good idea.
Posted: 9/26/2017 2:14 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I still recommend the best solution is use FFMPEG to convert the file to FFV1 Level 1 AVI to load with AVISource in AVISynth.
Posted: 9/25/2017 6:19 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I would recommend you try not to ruminate about the bad times, and only think of the good times. Try to distract yourself when you find yourself ruminating about bad times.
Posted: 9/25/2017 5:40 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I heard that supposedly if you do multiple AVS, it will work. I, myself have not tried it nor do I know if you use Import or AVISource to load the AVS.
Posted: 9/25/2017 12:54 AM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
ffms2 is known to not be a/v sync, I usually avoid it as much as possible. Unfortunately the only solution to your problem I know of, feos, is to combine segments =(.
Posted: 9/8/2017 1:57 AM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
thecoreyburton wrote:
Whoops! Well, at least now we can be sure we were thorough about this in the future.
"./programs/avs2pipemod" -wav encode.avs | "./programs/qaac64" -v 0 --he -q 2 --delay -5187s --threading --no-smart-padding - -o "./temp/audio.mp4"
"./programs/avs2pipemod" -wav encode.avs | "./programs/sox" -t wav - -t wav - trim 0.0065 | "./programs/opusenc" --bitrate 64 --padding 0 - "./temp/audio.opus"
Yep except add --padding 0 to the opus line.
Posted: 9/7/2017 4:20 PM
Quote
Aktan
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Okay, I did more testing. If I encode to AAC using qaac, and then mux to MP4 using MP4Box, the delay is 5187 samples (very close to the original number I said for HE-AAC of 5186 samples!). I think we went on a wild goose chase when it was all fine all this time >_>.
1 2 3 4 5
49 50