The url officially has a slash after it. I don't mind, but people might ragequit the site get pissed over it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I wasn't able to find a solution for this elsewhere:
How can I encode with x264 (i.e. in HandBrake) and have it keep frames of solid black or white color? These appear fairly often in TASes, however in my experience, the codec will replace them with a freeze frame of the last non-solid color frame. This usually looks strange and not fully accurate to the source.
A recent example is Weatherton's MK64 encode, where the lack of fully black frames is seen as early as 12 seconds in. Notice how the words "Player Select" stay on screen for a while instead of going black right away, and later how the colored boxes at 1:11 never fully leave the screen. I don't believe this happens in BizHawk or on console.
I wasn't able to find a solution for this elsewhere:
How can I encode with x264 (i.e. in HandBrake) and have it keep frames of solid black or white color? These appear fairly often in TASes, however in my experience, the codec will replace them with a freeze frame of the last non-solid color frame. This usually looks strange and not fully accurate to the source.
A recent example is Weatherton's MK64 encode, where the lack of fully black frames is seen as early as 12 seconds in. Notice how the words "Player Select" stay on screen for a while instead of going black right away, and later how the colored boxes at 1:11 never fully leave the screen. I don't believe this happens in BizHawk or on console.
I uploaded mine to youtube as losslessly compressed with lagarith and that wasn't happening when I played it locally. It seems that YouTube was messing up on it... I guess maybe we can't upload logarith directly to YouTube?
That did the trick, thank you! I never would have known what that was called.
Weatherton, I've read that YouTube does its own reconversion (when it "processes" your video); perhaps it does DCT Decimation as part of that. Otherwise, make sure your Lagarith's "Enable Null Frames" box is unchecked, having that checked caused me a similar issue with lossless Dolphin dumps and certain programs.
I'm having a bit of difficulty with a video dump, specifically the 10bit MKV encode (the other two worked just fine). When I get to encoding the video, the following error comes up:
Feos said it's likely something to do with Bizhawk's N64 dumping as this is for the Banjo-Kazooie run recently submitted and to ask in IRC. I spoke to Spikestuff who encounted the same problem a while back with a run he encoded which was solved by RGamma. Unfortunately I can't stick around in IRC any longer, so can anyone here offer any insight or solution to the issue?
I'm not as active as I once was, but I can be reached here if I should be needed.
I'm having a bit of difficulty with a video dump, specifically the 10bit MKV encode (the other two worked just fine). When I get to encoding the video, the following error comes up:
Feos said it's likely something to do with Bizhawk's N64 dumping as this is for the Banjo-Kazooie run recently submitted and to ask in IRC. I spoke to Spikestuff who encounted the same problem a while back with a run he encoded which was solved by RGamma. Unfortunately I can't stick around in IRC any longer, so can anyone here offer any insight or solution to the issue?
It's not to do with the dumping but the framerate (I guess you can blame that on the dumping). The fix is to use a FPS that's close enough to it. Right now, how I did that, I forgot, lol. I'll update this in a sec after I remember.
Edit: Use the --timebase param and set it to 100/ 254118000
Okay, I took a look at it. I only found a workaround. Add this to the AVS:
Language: avisynth
AssumeFPS(60, 1)
The fact you changed the framerate slightly for x264.exe doesn't matter because the timecodes file will be used for the real times when you use mkvmerge.exe
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Okay, I took a look at it. I only found a workaround. Add this to the AVS:
Language: avisynth
AssumeFPS(60, 1)
The fact you changed the framerate slightly for x264.exe doesn't matter because the timecodes file will be used for the real times when you use mkvmerge.exe
Edit: Oops, yea this was the better solution. I brainfarted.
I should clarify the workaround to the x264 problem. It isn't just using AssumeFPS(60) and not use the timecodes file in x264. It's more like you add AssumeFPS(60), generate a new timecodes file just for x264, and then use that timecodes file with x264. Since the new timecodes file is with the base of 60 FPS instead of 60000/1001, the automatic generation from x264 would not go as crazy number as you see with the problem. Then when you create the MKV, use the original timecodes file, not the one generated with AssumeFPS(60) just for x264.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
So normally you would run 2 passes with ExactDedup and then send the timecodes to x264. But in this case you do this instead:
1. Change the AVS:
Language: avisynth
# Comment out original ExactDedup
# ExactDedup(...
#Add AssumeFPS
AssumeFPS(60)
#Add another ExactDedup (both passes) that stores to different files than the original one
ExactDedup(...
2. Create the two new ExactDedup related files (dedup info and timecodes file)
3. Encode to x264 with this new temp timecodes file as well as using the new dedup info file in the AVS
4. Remake the MKV using the timecodes file of the original ExactDedup to get the right times
The fix worked for me and I have a good understanding of the process thanks to Aktan.
Basically, you're doing the first pass of ExactDedup without the fix to generate the timecodes with the correct framerate and the correct times (for reference, we can call these the "broken" timecodes). It's useful to use a unique name (eg, times-broken.txt) as opposed to one that may get overwritten in a later step.
Next, you're applying the fix by adding AssumeFPS(60) after loading the source. You once again do the first pass of ExactDedup to generate a second set of timecodes (for reference, we can call these the "fixed" timecodes).
A few things have happened here. AssumeFPS changes the rate the frames are displayed at without altering the number of frames. This means the frames that are decimated as a result of ExactDedup will be the same, although because the rate was adjusted on the fixed set of timecodes the timings will be different.
When you hit the encoding stage of the script, you pass the fixed timecodes through to x264. Because the base is now a flat 60fps it wont encounter any sort of error and the rate is so similar you won't notice any visual difference in regards to compression.
Of course, if you left the process here because the rate was adjusted the video would gradually fall out of sync. Because of this, when you get to the MKVMerge stage of the encoding process, you use the broken timecodes. Because the decimation was identical, these timecodes will work with the video x264 encoded correctly, and because they were created with the correct frame rate (before any adjustment was made), the resulting video will also have the correct frame timings (and no desync of any sort).
I have a pretty easy way to add it to the encoding script / batch feos, I'll send you a message about it now.
I'm not as active as I once was, but I can be reached here if I should be needed.
Does anyone have any ideas as to why my encodes, like this one for example, do not show black screens after uploading to youtube? Instead, the black screen is replaced by the frame before it, or in the case of the first black screen, the frame after.
These same encodes do in fact have properly working black screens before I upload them to youtube.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I see. Switching to x264 solves that issue, but now I am getting sound desyncs.
Pretty sure I still have everything set to default in my configurations. Is there anything I should change there that might fix it?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
