Not OP here, but in general what can said is the following:
Regarding the 1st question:
To check the length of the buffer until R/EIP is overwritten just create a De Bruijn sequence . Then you can easily calculate the offset as shown below for an arbitrary R/EIP overwrite of for example 0xbuaaaaaa. That method is way easier than trying random buffer sizes and filling them with 'A's…
gef➤ pattern create 400
[+] Generating a pattern of 400 bytes
aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaazaaaaaabbaaaaaabcaaaaaabdaaaaaabeaaaaaabfaaaaaabgaaaaaabhaaaaaabiaaaaaabjaaaaaabkaaaaaablaaaaaabmaaaaaabnaaaaaaboaaaaaabpaaaaaabqaaaaaabraaaaaabsaaaaaabtaaaaaabuaaaaaabvaaaaaabwaaaaaabxaaaaaabyaaaaaab
[+] Saved as '$_gef1'
gef➤ pattern offset buaaaaaa
[+] Searching 'buaaaaaa'
[+] Found at offset 359 (big-endian search)
gef➤
Regarding the 2. question:
Judging from the screenshots the address 0xffffd480 is somewhere in the middle of the NOP-sled. When we can fill the buffer with NOP's plus a shellcode like in this example the following scenario is something we want:
Just return anywhere in the middle of the NOP-sled so execution continues at the shellcode as wanted. 0xffffd480 is not the only address we could have chosen but it just fits the need of being somewhere at the beginning of sled. So hitting that address with our overwritten return address guarantees us executing our shellcode.
Depending on the buffer size such an address is not arbitrary but in this scenario we would have had enough wiggle room to choose any other part of the NOP sled as well.
I hope that clears things up a bit 
PS: Note that running shellcode from the stack only works when the NX-bit is not set