Homebrew Homebrew app [Release] Video player for 3DS

  • Thread starter Thread starter Core_2_Extreme
  • Start date Start date
  • Views Views 195,459
  • Replies Replies 504
  • Likes Likes 66
The v1.6.1 is here!!!!!

Changes
Number of decoding threads are selectable now.
Full-screen transition period has been changed from 5 seconds to 3 seconds.
Progress message (`xx.yy%`) has been added to `seeking` and `processing video` messages.
3D slider bar no longer moves video.

Fixed bugs
Race condition that may cause model detection to fail and disable use of HW decoder has been fixed.
Seek issue on audio only file and 3D videos have been fixed.
Many issues on code that may cause problems on 3D videos have been fixed.
Unable to play 3D videos if HW decoder is enabled has been fixed (by disabling HW decoder on 3D videos).

About high RAM cia
`..._high_ram.cia` can use more RAM than normal `.cia` and `.3dsx`, this can reduce chance of getting `out of (linear) memory` errors.
When you open/close it your 3DS will reboot so it may take a while to open/close the app, and you can't use the Internet browser while you are using it.

https://github.com/Core-2-Extreme/Video_player_for_3DS/releases/tag/v1.6.1
 
Last edited by Core_2_Extreme,
The v1.6.1 is here!!!!!

Changes
Number of decoding threads are selectable now.
Full-screen transition period has been changed from 5 seconds to 3 seconds.
Progress message (`xx.yy%`) has been added to `seeking` and `processing video` messages.
3D slider bar no longer moves video.

Fixed bugs
Race condition that may cause model detection to fail and disable use of HW decoder has been fixed.
Seek issue on audio only file and 3D videos have been fixed.
Many issues on code that may cause problems on 3D videos have been fixed.
Unable to play 3D videos if HW decoder is enabled has been fixed (by disabling HW decoder on 3D videos).

About high RAM cia
`..._high_ram.cia` can use more RAM than normal `.cia` and `.3dsx`, this can reduce chance of getting `out of (linear) memory` errors.
When you open/close it your 3DS will reboot so it may take a while to open/close the app, and you can't use the Internet browser while you are using it.

https://github.com/Core-2-Extreme/Video_player_for_3DS/releases/tag/1.6.1
Hey man, i have a dumb question. where should I place audio files for different languages so the app can recognize them? I have them in the same folder as the movie, but when I click "select the audio track," they don't appear in the list.

Edit: Nevermind. I solve it with MKVToolNix
 
Last edited by masterz81,
  • Like
Reactions: Core_2_Extreme
18871.jpg
18875.jpg
18874.jpg







Hi, I've been using this player on my 3DS and wanted to share some feedback and suggestions. Hope these can help improve the experience for everyone!



**1. Top screen UI must never affect video scaling**



This is the most critical issue. I encode videos at 320×240 specifically for pixel-perfect display on the 3DS top screen (which is exactly 240px tall). However, when the UI is triggered — even accidentally by touching the bottom touchscreen — the top screen recalculates scaling to exclude the status bar area, completely ruining the pixel-perfect display. Every single seek operation breaks it too.



The top screen UI elements are largely unnecessary during playback. Please move all overlays, hints, and status indicators to the bottom screen by default, and ensure the top screen video display is never affected by any UI state. A settings toggle for this behavior would be a nice addition.



**2. Tapping blank area on bottom screen should dismiss UI mode**



Currently, touching the bottom screen enters UI mode but there's no way to dismiss it by touch. Please allow tapping an empty area on the bottom screen to exit UI mode — this is standard behavior in essentially every mobile video player and feels very natural.



**3. Remove the controls help button from the playback screen**



The button that shows a controls/shortcut overlay during playback clutters the UI. Please move it to the settings menu instead.



**4. Remove or default-disable the video position/zoom controls**



The analog stick and d-pad video pan/zoom functionality is unnecessary for most use cases, especially for 240p encoded videos where you want pixel-perfect display. Accidental input causes unwanted panning. Please either remove it or add a setting to disable it, defaulting to disabled.



**5. Remove the "Press SELECT to switch modes" hint on the top screen**



The hint that appears on the top screen when a video starts is unnecessary and looks bad. Users can figure this out or find it in the manual. Please remove it entirely.



**6. Fix the file browser toggle button**



Currently X opens the file browser and Y closes it. Please make X toggle it — press once to open, press again to close. This is much more intuitive.



**7. Add a default directory setting**



Please add a setting to lock the file browser to a specific default directory (e.g., `/video` on the SD root). Nobody wants to navigate through system folders every time they want to pick a video file. When a default directory is set, the browser should not be able to navigate above it.



**8. Add RM/RMVB support and broader legacy format support**



Many of us have old video libraries in RM/RMVB format — even the old NDS MoonShell supported these. FFmpeg has full support for RealMedia formats; it just needs to be enabled in the build. Please add RM and RMVB to the supported formats list. More broadly, supporting a wider range of legacy formats would be greatly appreciated and shouldn't introduce any downsides.



---



Thanks for building and maintaining this — it has real potential to be the best video player on 3DS. These changes would make it genuinely great!
 
Thank you for your a lot of feedback!

**1. Top screen UI must never affect video scaling**
This is the most critical issue. I encode videos at 320×240 specifically for pixel-perfect display on the 3DS top screen (which is exactly 240px tall). However, when the UI is triggered — even accidentally by touching the bottom touchscreen — the top screen recalculates scaling to exclude the status bar area, completely ruining the pixel-perfect display. Every single seek operation breaks it too.

The top screen UI elements are largely unnecessary during playback. Please move all overlays, hints, and status indicators to the bottom screen by default, and ensure the top screen video display is never affected by any UI state. A settings toggle for this behavior would be a nice addition.
You can press SELECT to manually enter full-screen mode.
Also, you can press direction pad left and right to seek without leaving full-screen mode.
So I'm not going to change this for now.

**2. Tapping blank area on bottom screen should dismiss UI mode**

Currently, touching the bottom screen enters UI mode but there's no way to dismiss it by touch. Please allow tapping an empty area on the bottom screen to exit UI mode — this is standard behavior in essentially every mobile video player and feels very natural.
I've changed this one just after releasing v1.6.1, it is now always shown (you can still overlay videos) so I completely removed "controls" buttons.

**3. Remove the controls help button from the playback screen**

The button that shows a controls/shortcut overlay during playback clutters the UI. Please move it to the settings menu instead.
Which one do you mean?

**4. Remove or default-disable the video position/zoom controls**

The analog stick and d-pad video pan/zoom functionality is unnecessary for most use cases, especially for 240p encoded videos where you want pixel-perfect display. Accidental input causes unwanted panning. Please either remove it or add a setting to disable it, defaulting to disabled.
ok, I'll disable it by default.

**5. Remove the "Press SELECT to switch modes" hint on the top screen**

The hint that appears on the top screen when a video starts is unnecessary and looks bad. Users can figure this out or find it in the manual. Please remove it entirely.
This is only shown once, and this is seen in web browser as well so I think it is better leave it be.
1773309532746.png


**6. Fix the file browser toggle button**

Currently X opens the file browser and Y closes it. Please make X toggle it — press once to open, press again to close. This is much more intuitive.
I agree with this one, I'll change this.

**7. Add a default directory setting**

Please add a setting to lock the file browser to a specific default directory (e.g., `/video` on the SD root). Nobody wants to navigate through system folders every time they want to pick a video file. When a default directory is set, the browser should not be able to navigate above it.
I will not limit where you can navigate to.
Maybe I can change it to remember last directory.
What do you think?

**8. Add RM/RMVB support and broader legacy format support**

Many of us have old video libraries in RM/RMVB format — even the old NDS MoonShell supported these. FFmpeg has full support for RealMedia formats; it just needs to be enabled in the build. Please add RM and RMVB to the supported formats list. More broadly, supporting a wider range of legacy formats would be greatly appreciated and shouldn't introduce any downsides.
If FFmpeg suports it I can usually add it, however I still need some testing so please be patient until I add it.
Providing me sample files are greatly appreciated, it accelerates testing.
 
Last edited by Core_2_Extreme,
Thank you for your a lot of feedback!


You can press SELECT to manually enter full-screen mode.
Also, you can press direction pad left and right to seek without leaving full-screen mode.
So I'm not going to change this for now.


I've changed this one just after releasing v1.6.1, it is now always shown (you can still overlay videos) so I completely removed "controls" buttons.


Which one do you mean?


ok, I'll disable it by default.


This is only shown once, and this is seen in web browser as well so I think it is better leave it be.
View attachment 561757


I agree with this one, I'll change this.


I will not limit where you can navigate to.
Maybe I can change it to remember last directory.
What do you think?


If FFmpeg suports it I can usually add it, however I still need some testing so please be patient until I add it.
Providing me sample files are greatly appreciated, it accelerates testing.

Thank you for your reply! I want to clarify my point on issue #1, because I think there may have been a misunderstanding — my concern is actually different from what you addressed.


The core issue: video scaling must never be coupled to UI state


I'm fully aware of the SELECT shortcut to enter fullscreen mode — that's not the problem. The problem is this: even while already in fullscreen mode, whenever any UI element appears on the top screen (the status bar, the seek timeline overlay, the "seeking..." notice), the player recalculates the video's render area by subtracting the UI's pixel height from the top screen's total height, then rescales the video to fit the remaining space. This means UI visibility and video scaling are coupled together, and I think that coupling is the root of the issue.


Here's why this matters so much to me specifically: the 3DS top screen is exactly 240 pixels tall. I encode my videos at 320×240 precisely to achieve pixel-perfect 1:1 display — every pixel in the video maps to exactly one pixel on screen. This isn't just a preference; it's a meaningful image quality difference, because any rescaling introduces interpolation and softens the image. Right now, every single seek operation triggers the timeline UI on the top screen, which breaks the pixel-perfect display every time. This is a fundamental issue for my use case.


The fix I'd suggest is straightforward: the top screen video render area should always be fixed to the full 240px height, completely independent of UI state. If UI elements must appear on the top screen, they should be rendered as overlays floating on top of the video — not by carving out space from the render area. Overlay is less ideal visually, but it at least doesn't break scaling.





A follow-up thought: move all UI to the bottom screen


Once the scaling issue is resolved, I'd like to also suggest moving all top screen UI elements to the bottom screen entirely. The bottom screen is a touchscreen designed for interaction — it's the natural home for status bars, seek timelines, and notifications. The top screen should be clean and dedicated entirely to video. This isn't just personal preference; it feels like the natural fit for the 3DS's two-screen hardware design. Even a toggle option in settings would be greatly appreciated.


Thanks again for your work on this — it's a genuinely useful app and these changes would make it excellent.🫡😊
 
  • Like
Reactions: Core_2_Extreme
Thank you for your reply! I want to clarify my point on issue #1, because I think there may have been a misunderstanding — my concern is actually different from what you addressed.


The core issue: video scaling must never be coupled to UI state


I'm fully aware of the SELECT shortcut to enter fullscreen mode — that's not the problem. The problem is this: even while already in fullscreen mode, whenever any UI element appears on the top screen (the status bar, the seek timeline overlay, the "seeking..." notice), the player recalculates the video's render area by subtracting the UI's pixel height from the top screen's total height, then rescales the video to fit the remaining space. This means UI visibility and video scaling are coupled together, and I think that coupling is the root of the issue.


Here's why this matters so much to me specifically: the 3DS top screen is exactly 240 pixels tall. I encode my videos at 320×240 precisely to achieve pixel-perfect 1:1 display — every pixel in the video maps to exactly one pixel on screen. This isn't just a preference; it's a meaningful image quality difference, because any rescaling introduces interpolation and softens the image. Right now, every single seek operation triggers the timeline UI on the top screen, which breaks the pixel-perfect display every time. This is a fundamental issue for my use case.


The fix I'd suggest is straightforward: the top screen video render area should always be fixed to the full 240px height, completely independent of UI state. If UI elements must appear on the top screen, they should be rendered as overlays floating on top of the video — not by carving out space from the render area. Overlay is less ideal visually, but it at least doesn't break scaling.





A follow-up thought: move all UI to the bottom screen


Once the scaling issue is resolved, I'd like to also suggest moving all top screen UI elements to the bottom screen entirely. The bottom screen is a touchscreen designed for interaction — it's the natural home for status bars, seek timelines, and notifications. The top screen should be clean and dedicated entirely to video. This isn't just personal preference; it feels like the natural fit for the 3DS's two-screen hardware design. Even a toggle option in settings would be greatly appreciated.


Thanks again for your work on this — it's a genuinely useful app and these changes would make it excellent.🫡😊

Well, let me check what's going on (I suspect it's sar problem) so can you:
1. Open video player ->
2. Play the video ->
3. Stop the video ->
4. Go back to main menu where you see gear icon on right bottom ->
5. Tap on gear icon ->
6. Tap on Advanced settings ->
7. Tap on Dump logs ->
8. Upload the log (/3ds/Video_player/logs/YYYY_MM_DD_hh_mm_ss.txt) here

Edit: I mean if you are complaining "I encoded my video at 320x240 but it's displayed as if it was 320x225 in full-screen mode", then I think it's sar problem.
 
Last edited by Core_2_Extreme,
  • Like
Reactions: ushsnb
The fix I'd suggest is straightforward: the top screen video render area should always be fixed to the full 240px height, completely independent of UI state. If UI elements must appear on the top screen, they should be rendered as overlays floating on top of the video — not by carving out space from the render area. Overlay is less ideal visually, but it at least doesn't break scaling.
This seems like an unnecessary change to me. If you're seeking or performing some other kind of interaction, then video quality is irrelevant, since you're not actually watching. You're trying to find the spot you want to watch. Resizing the video is a simple approach to ensure the UI is readable. Yes, rendering the UI on top of the video with a black frame to ensure the text is readable would also work, but this would require Core_2_Extreme to spend extra development time accomplishing... nothing. Instead of being able to see the full frame at a lower resolution, now some of the frame is being blocked by the overlay. You're not supposed to watch a video when the UI is open, so just press Select and enjoy your video in full screen? ¯\_(ツ)_/¯
 
  • Like
Reactions: Core_2_Extreme
Well, let me check what's going on (I suspect it's sar problem) so can you:
1. Open video player ->
2. Play the video ->
3. Stop the video ->
4. Go back to main menu where you see gear icon on right bottom ->
5. Tap on gear icon ->
6. Tap on Advanced settings ->
7. Tap on Dump logs ->
8. Upload the log (/3ds/Video_player/logs/YYYY_MM_DD_hh_mm_ss.txt) here

Edit: I mean if you are complaining "I encoded my video at 320x240 but it's displayed as if it was 320x225 in full-screen mode", then I think it's sar problem.

What I mean is, fullscreen playback works fine, but I believe that a film displayed pixel-perfectly on the upper screen should not be scaled just because of UI elements like the clock, WiFi icon, or the green leaf indicator. This is, I think, a natural rule of video playback software — pixel-perfect display should not be arbitrarily disrupted, let alone by non-essential interference like this. This is the issue I care about most. It is the only issue I care about most. Nobody wants a pixel-perfect video to be inexplicably scaled because of a green leaf or WiFi icon — the beautiful pixel-perfect image suddenly becomes blurry. And even if those UI elements overlap and cover part of the image, there's no need to scale it at all.
I also think that if touching the screen can enter UI mode, then touching it again should be able to exit UI mode as well.
There is another issue with this player, though I'm not sure whether you can solve it: it decodes RGB888 video but outputs RGB565, which causes a lot of unnatural color banding (color contour lines). I'd like this to be fixed — specifically, I want the New 3DS to hardware-decode H.264 video and output RGB888, rendered on a video player that also renders in RGB888. Perhaps this problem can be solved. I know that Nintendo apparently defaults to RGB565 output in some situations, including decoding and rendering software, but I think it might be possible to fix this. RGB888 video is far superior to RGB565.
However, I came up with a quirky workaround entirely on my own after thinking about it for a long time. The original goal was to eliminate the color banding I was seeing when playing video on the 3DS — I had assumed for a long time it was a compression issue on my end. My video encoding command is:


ffmpeg -nostdin -y -stats -stats_period 1 ^
-i "%FILE_IN%" ^
-vf "crop='min(iw,ih*400/240)':ih,subtitles='%SUB_ESC%',format=yuv420p16le,zscale=w=-2:h=240:m=bt709:min=bt709:filter=spline36,scale=sws_dither=bayer:in_color_matrix=bt709,format=rgb565le,scale=flags=neighbor:sws_dither=0:out_color_matrix=bt709,format=yuv420p"^
-c:v libx264 -preset slow -crf 15 -profile:v high -level 3.1 -fps_mode cfr ^
-x264-params "aq-mode=3:aq-strength=1.5:qcomp=0.65:ref=5:bframes=5:no-fast-pskip=1" ^
-color_primaries bt709 -color_trc bt709 -colorspace bt709 ^
-c:a aac -b:a 128k -ac 2 -ar 48000 ^
"%FILE_OUT%" || pause


As you can see, I first convert the color to 16-bit, then convert to RGB565 with Bayer dithering applied, and then map it back to the nearest RGB888 colors with no dithering, before encoding. The idea is that by doing this, the colors are already encoded in the RGB565 color space at compression time — and with dithering applied, more colors can be simulated. When played back, there will be no unexpected, unnatural color banding from an RGB888-to-RGB565 conversion, because those color contour lines that would have appeared are identified in advance during the 10-bit source → RGB565 conversion step, and Bayer dithering is used to simulate additional colors. Combined with encoding settings that preserve fine detail without dropping small features (to retain the dither pattern), the unnatural banding disappears entirely.
I'm including image comparisons — the right side is my optimized version with the RGB565 intermediate step to RGB888; the left is the standard version. My player is set to RGB565 pixel-perfect display, so what you see is exactly what the real 3DS shows.
I also recommend this video encoding script to others.
I also want to show you some of the videos I've encoded specifically for the New 3DS — all at 400×240. I've encoded quite a lot of them.

Respect, and keep going!
:D:):bow:


1773673675029.png
1773673588312.png
1773673536004.png


1773673536018.png
 

Attachments

  • Like
Reactions: Core_2_Extreme
What I mean is, fullscreen playback works fine, but I believe that a film displayed pixel-perfectly on the upper screen should not be scaled just because of UI elements like the clock, WiFi icon, or the green leaf indicator. This is, I think, a natural rule of video playback software — pixel-perfect display should not be arbitrarily disrupted, let alone by non-essential interference like this. This is the issue I care about most. It is the only issue I care about most. Nobody wants a pixel-perfect video to be inexplicably scaled because of a green leaf or WiFi icon — the beautiful pixel-perfect image suddenly becomes blurry. And even if those UI elements overlap and cover part of the image, there's no need to scale it at all.
I see, I understand your idea.
I keep it as is for now because no one complained about it until now, I'll reconsider it if I get similar complaints more in the future.

I also think that if touching the screen can enter UI mode, then touching it again should be able to exit UI mode as well.
Exiting UI mode (meaning entering full-screen mode) when you touch where in screen?
Background?

There is another issue with this player, though I'm not sure whether you can solve it: it decodes RGB888 video but outputs RGB565, which causes a lot of unnatural color banding (color contour lines). I'd like this to be fixed — specifically, I want the New 3DS to hardware-decode H.264 video and output RGB888, rendered on a video player that also renders in RGB888. Perhaps this problem can be solved. I know that Nintendo apparently defaults to RGB565 output in some situations, including decoding and rendering software, but I think it might be possible to fix this. RGB888 video is far superior to RGB565.
Well, let me consider it.
I should be able to technically do this (with lower performance compared to RGB565) maybe I can add settings for it like always RGB565, auto, always RGB888.

Thank you for your feedbacks again.
 
  • Like
Reactions: ushsnb
I see, I understand your idea.
I keep it as is for now because no one complained about it until now, I'll reconsider it if I get similar complaints more in the future.


Exiting UI mode (meaning entering full-screen mode) when you touch where in screen?
Background?


Well, let me consider it.
I should be able to technically do this (with lower performance compared to RGB565) maybe I can add settings for it like always RGB565, auto, always RGB888.

Thank you for your feedbacks again.
It's not just a matter of the decoder outputting RGB888. I've tried videos encoded with H.265 and AV1 — those use software decoding and do output RGB888 — but there are still unnatural color banding stripes. The issue is that the entire software is running in RGB565 mode. The whole screen output of this software is RGB565. Even if the software's CPU decoder outputs RGB888, it doesn't matter because the rendering pipeline is still RGB565.


I'd like a developer option to switch between the two rendering modes (RGB565 and RGB888).
:D
Post automatically merged:

I see, I understand your idea.
I keep it as is for now because no one complained about it until now, I'll reconsider it if I get similar complaints more in the future.


Exiting UI mode (meaning entering full-screen mode) when you touch where in screen?
Background?


Well, let me consider it.
I should be able to technically do this (with lower performance compared to RGB565) maybe I can add settings for it like always RGB565, auto, always RGB888.

Thank you for your feedbacks again.
Regarding how to exit UI mode: I believe the best approach is to tap anywhere on the screen that isn't occupied by a UI element. This has become a standard convention in mobile app design; I’ve observed this across various video platforms like YouTube and Bilibili, as well as many mobile media players. It is highly intuitive.

Furthermore, my biggest priority is that the on-screen display remains "point-to-point" (1:1 pixel mapping) and does not change when the UI is toggled. The content should not scale down. Even if the UI overlays the video, it is far better than proportional scaling.

In my opinion, keeping the video content unaffected and stable is the ideal approach. I firmly believe that protecting the maximum, complete, and stable display of the content is of the utmost importance.

Thank you! :D
 
Last edited by ushsnb,
  • Like
Reactions: Core_2_Extreme
It's not just a matter of the decoder outputting RGB888. I've tried videos encoded with H.265 and AV1 — those use software decoding and do output RGB888 — but there are still unnatural color banding stripes. The issue is that the entire software is running in RGB565 mode. The whole screen output of this software is RGB565. Even if the software's CPU decoder outputs RGB888, it doesn't matter because the rendering pipeline is still RGB565.


I'd like a developer option to switch between the two rendering modes (RGB565 and RGB888).
:D
After some investigation, I noticed using HW color converter outputs unusual color.
Can you try disabling HW color converter by:
  • Press Y
  • Select second tab
  • Tap on Use hardware color conversion
  • (And play video to see if you notice difference)

Regarding how to exit UI mode: I believe the best approach is to tap anywhere on the screen that isn't occupied by a UI element. This has become a standard convention in mobile app design; I’ve observed this across various video platforms like YouTube and Bilibili, as well as many mobile media players. It is highly intuitive.
Ok let me consider it.

Furthermore, my biggest priority is that the on-screen display remains "point-to-point" (1:1 pixel mapping) and does not change when the UI is toggled. The content should not scale down. Even if the UI overlays the video, it is far better than proportional scaling.

In my opinion, keeping the video content unaffected and stable is the ideal approach. I firmly believe that protecting the maximum, complete, and stable display of the content is of the utmost importance.
I won't change it right now.
If you really want to do it, you can fork my repository and modify code to make your own version.
 
The 20260401/v1.6.2641 is here!!!!!

Changes
Added mandatory education.

Known issues
Font rendering is broken until you finish the education (you can start education program by clicking video player icon ()).
It's not possible to watch other videos until you finish the education.
It's not possible to pause education once it starts.

About high RAM cia
`..._high_ram.cia` can use more RAM than normal `.cia` and `.3dsx`, this can reduce chance of getting `out of (linear) memory` errors.
When you open/close it your 3DS will reboot so it may take a while to open/close the app, and you can't use the Internet browser while you are using it.

https://github.com/Core-2-Extreme/Video_player_for_3DS/releases/tag/20260401/v1.6.2641
 
  • Like
Reactions: ber71
After some investigation, I noticed using HW color converter outputs unusual color.
Can you try disabling HW color converter by:
  • Press Y
  • Select second tab
  • Tap on Use hardware color conversion
  • (And play video to see if you notice difference)


Ok let me consider it.


I won't change it right now.
If you really want to do it, you can fork my repository and modify code to make your own version.
here you go !
https://github.com/mockmodular/topos_3ds-video-player/releases/tag/topos_v0.1
😀
 
  • Like
Reactions: Core_2_Extreme


Hey, I've been working on a heavily modified version of this player focused on SBS 3D. If anyone's interested:


  • New 3DS: H.264 MVD hardware decode, 800×240 SBS 24fps, near-zero CPU
  • Old 3DS: MPEG-2 software decode, 800×240 SBS 24fps, smooth
  • Full RGB888 pipeline (vs RGB565 in the original)

Includes sample Avatar: Fire and Ash trailer encoded in both formats, plus what I believe are the best FFmpeg scripts for encoding SBS video for 3DS:

h264:
"%FFMPEG%" -y -stats -stats_period 1 -i "%FILE_IN%" -filter_complex "[0:v]scale=iw*sar:ih,setsar=1,split[L][R];[L]crop=iw/2:ih:0:0[Lh];[R]crop=iw/2:ih:iw/2:0[Rh];[Lh]crop=min(iw\,ih*400/240):ih[Lc];[Rh]crop=min(iw\,ih*400/240):ih[Rc];[Lc][Rc]hstack[Vs];[Vs]format=yuv420p16le,zscale=w=800:h=240:m=bt709:min=bt709:filter=spline36,format=yuv420p,setsar=1[V]" -map "[V]" -map "0:a?" -sws_dither ed -c:v libx264 -preset slow -crf 14 -profile:v high -level 3.1 -fps_mode cfr -x264-params "aq-mode=3:aq-strength=1.0:qcomp=0.65:ref=4:bframes=4:no-fast-pskip=1" -color_primaries bt709 -color_trc bt709 -colorspace bt709 -c:a aac -b:a 128k -ac 2 -ar 48000 "%FILE_OUT%"

mepg2:
"%FFMPEG%" -y -stats -stats_period 1 -i "%FILE_IN%" -filter_complex "[0:v]split[L][R];[L]crop=iw/2:ih:0:0[Lh];[R]crop=iw/2:ih:iw/2:0[Rh];[Lh]crop=min(iw\,ih*400/240):ih[Lc];[Rh]crop=min(iw\,ih*400/240):ih[Rc];[Lc][Rc]hstack[Vs];[Vs]format=yuv420p16le,zscale=w=800:h=240:m=bt709:min=bt709:filter=spline36,format=yuv420p[V]" -map "[V]" -map "0:a?" -c:v mpeg2video -b:v 2000k -maxrate 2000k -bufsize 4000k -g 30 -bf 0 -profile:v main -level:v main -fps_mode cfr -color_primaries bt709 -color_trc bt709 -colorspace bt709 -c:a mp2 -b:a 96k -ac 2 -ar 48000 "%FILE_OUT%"

GitHub: https://github.com/mockmodular/topos_3ds-video-player/releases/tag/topos_v0.1
 
  • Like
Reactions: Core_2_Extreme
Last edited by Core_2_Extreme,
  • Like
Reactions: Core_2_Extreme
Based on the README, it seems you are detecting SBS video via the resolution, so if the width is > 640 px, you assume it's SBS. This would suggest that it's not possible to play 800x240 2D double-resolution videos on this fork, right? Although the quality jump isn't massive compared to using 400x240, perhaps you could read the video metadata to detect the picture mode, so that both 2D and 3D videos would work?
 
  • Like
Reactions: Core_2_Extreme
Based on the README, it seems you are detecting SBS video via the resolution, so if the width is > 640 px, you assume it's SBS. This would suggest that it's not possible to play 800x240 2D double-resolution videos on this fork, right? Although the quality jump isn't massive compared to using 400x240, perhaps you could read the video metadata to detect the picture mode, so that both 2D and 3D videos would work?
I have not added the feature to play videos with a resolution of 800×240 but displayed at a 400:240 aspect ratio. This is because I personally find it absurd and strange to have an 800×240 resolution video displayed at a 400×240 resolution (just my personal opinion, haha...). Regarding the SBS video detection feature, that detection logic only applies when the SBS setting in the options is set to Auto mode. The other two modes are force 2D display and force 3D SBS display, respectively.
and discussions and replies can be found here.
and please just download it and try it. i like this 3d sbs videoplayer for 3ds, named topos. 😊

last version is
https://github.com/mockmodular/topos_3ds-video-player/tree/v0.12.0
https://github.com/mockmodular/topos_3ds-video-player/releases/tag/v0.12.0
 
Last edited by ushsnb,
  • Like
Reactions: Core_2_Extreme

Site & Scene News

Popular threads in this forum