Does anyone have settings suggestions for an Old 3ds?

[TurtleFanCoder]

(Very sorry if I put this in the wrong place, I don't use GitHub often.) I bought an Old 3ds since I thought there was no real advantage to owning a New one, but as I'd find out that would be a huge mistake. I'm curious if anyone knows settings for this to get a decent quality with minimal delay on an old 3ds, since I did manage to get playable settings using this, which was really cool, but thought I'd ask if there was recommended ones somewhere.

[zoeyjodon]

I haven't tinkered with the o3DS enough to come up with settings that are actually playable, so I'd actually love to know what settings you used to get a decent quality stream!

[Adi3000]

Ok, I have two Old3DS so let me say that make it run and make revive those console with streaming is one of my fantasies Here my config to make it work : I was running overhaul maid by #38. I lowered down FPS to 10 I lowered bitrate to 200

And it was "playable" :

• no more skipped video buffer wrap (video wrap of 1 o 1.5 second)
• less unsynch with audio
• latency above 0.1 ~ 0.2 s (noticable but playable)
• ugly crappy picture
• almost audible sound

Also :

• Changing packetsize does nothing but adding more confusion of it is better or not
• For now HW accel is blocked by the code for Old3DS so, didn't tried
• FPS have more impact than Bitrate, It is impossible to go over 10 FPS no matter what, but going over a bitrate 250 is quite incontestable, but not impossible

But, I do not have any competence in C but I managed one day the namkazt/PinBox project. It mention Hardware acceleration by conversion of YUV to RGB : I see there is use of it, and I may would try to unlock HW acceleration. Before that, what are the risks ? Here the lib which was used : https://github.com/namkazt/PinBox/blob/master/PinBox/PinBox/source/yuv_rgb.c Here the real editor source of it : https://github.com/Lectem/3Damnesic/blob/master/source/color_converter.c

I'll try my best to find something good but before wasting my 3DS and/or my time :

1. Is there any risk of unlocking HW acceleration on Old3DS at this stage ? (material damage ?)
2. Is the conversion Y2R already applied now ? (I do not succeed to understand properly C/CPP for now, I will when I'll manage this challenge)
3. If I fork Sunshine + add an extension to convert video with the good codec, it should works, no ?
4. What are the expectation of a video on a old3DS ? I mean, I hope 3DS game on old3DS uses HW accel somehow, but how they did it ?

[zoeyjodon]

If you're running the build from the C++ upgrade PR, then you're probably doing the best that the o3DS can do. I got 400x240p video running at 20fps at one point with the bitrate set to 1000kbps, but I didn't test it extensively so there may be some quality issues at that rate.

I'm already using the hardware YUV to RGB converter, the hardware acceleration option that I blocked for the o3DS uses the MVD video decoder which converts H264 to RGB. I added the check because the o3DS doesn't have MVD decoder hardware, so if you enable it on the o3DS you'll probably just cause a crash (I dont remember for sure though since I haven't tested it in a while).

If you fork Sunshine, you might be able to use a faster codec for sending video! It'll just be less efficient for communication, and since everything is getting run through the slow o3DS processor, you might need to balance the decode speed with the transfer size a bit.

The o3DS used the GPU for rendering, but like I said, it didn't have a hardware video decoder because I guess video streaming on the 3DS wasn't a big concern for Nintendo at the time.

[Adi3000]

So I go through my investigation to do better :

Looking after this benchmark, the real thing should to use MPEG2 stream. With some little computation, I saw that stream should be "only" twice heavier this way, but should be processed more than 3 time faster, letting some resources for other stuff.

But for now, I call it a night, I managed to modify Sunshine but encountered an obstacle : for now according to the NVEncoderApi and internet, NVEnc is not able to encode as MPEG the flow (cf here or there for the Api documentation ). So if I have to double encode flow, I may have some hard time. I let it here as it is if someone want to give it a try.

Nevertheless, I may pursue later

[matsilvaa]

When I connect my Old 3ds to moonlight, an error appears on the screen saying that hardware decoding is only available for the new 3ds and gives an error called -1, can anyone help me?

[Adi3000]

Yeah, you're probably trying to stream by using the hwdecode in the stream configuration option. As precised before old 3ds do not have requirements to do some hwdecode so it will use something else. Please ensure that this option hwdecode is disabled on stream options

[mirh]

You don't really need nvenc to encode with formats from before this century (let alone at these tiny resolutions). Not sure what double encoding you are thinking about, just use the cpu.

Besides MPEG 1/2 (and exotic formats), MPEG-4 and H263(p) may also be worthy contenders assuming they could provide higher quality for the same bitrate or lower. Also of note that they have just so many internal profiles. You can really see those juicy new SIMD instructions accelerating the decoding of those slightly new codecs (I doubt they could be near MPEG2 and higher than mjpg otherwise)

[Adi3000]

This is the first time I try encoding, I may be full of mislead. For what I understand, sunshine and moonlight streaming rely on the nvidia ability to encode flow seemlessly. But flow/stream sent to old 3ds has to be received on one particular encoding (mpeg should do), and the less transformation we have the best it is. So indeed, if I do not encode through nvencode, I'll be able to send mpeg but what about nvidia steam wrapper (if any) and decoding stream after exchanging pairing code and all the stuff nvidia may have wrap around their stream protocol? If any of this, I should try indeed,.nevertheless, I suspect to not be as smooth as nvidia in terms of latency streaming.

[mirh]

Shadowplay did kinda become big thanks to NVENC (for many years people didn't even think you could hardware stream/record without). Which also acted as a very convenient hardware lock for nvidia. But that aside, there's nothing magic in its H264 stream (let alone now that we have sunshine which lets you play with just whatever ffmpeg supports). Or did you mean NVFBC/NVIFR? It's not really a big deal, especially if you are encoding VGA resolutions.

If any though, I feel like you'd probably have a better time "prototyping codecs" just with Video_player_for_3DS/ffmpeg directly. There's like so many codecs and profiles that you should try (I wonder how huffyuv, ffv1, MagicYUV or ut video could fare?)