Homebrew Homebrew app [Release] Video player for 3DS

Core_2_Extreme

Well-Known Member
OP
Member
Joined
Feb 11, 2019
Messages
102
Trophies
0
Age
20
XP
664
Country
Japan
Well, the fake model option is definitely working, because performance is terrible in O3DS mode. :lol:

I am a little confused though... I tried XviD 240x144p @ 24 fps, and the average fps is 51, and the recent average is always above 40, but the video is still playing in slow motion with skipping audio. If the decoding speed is > 40 fps on a 24 fps clip, shouldn't it play at full speed? Based on your benchmarks, H.261 is only ~6 fps faster than H.263+ (not quite the same as XviD, but close enough), so it seems like you'd need to use 160x96 or even 80x48 to get full speed on O3DS...

On the N3DS front, the larger buffer for MVD_Serivces is working. Clips with 5-9 reference frames no longer crash the system. :)
The key point is average fps, let's say you are playing 30fps video and O3DS decoded
frame[0] at 20ms
frame[1] at 25ms
frame[2] at 16ms
frame[3] at 38ms
frame[4] at 22ms

The average decoding time is 24.2ms and fps is 41.3, but you'll likely to hear sound stutter at frame[3] because it over 33.3ms(1000ms / 30fps = 33.3ms per frame)

Although average fps is 53, You'll hear sound stutter at black arrow
old.jpg


OLD3DS uses same core for decoding and drawing so using full screen mode may increase decoding speed a little(because it won't draw bottom screen during full screen mode).
 

P34ch

Active Member
Newcomer
Joined
Apr 11, 2019
Messages
29
Trophies
0
Age
45
XP
57
Country
United Kingdom
Thank you Core-2 for overlaying the video in windowed mode, such a simple but perfect solution. The 1.3.4 dev is very unstable for me with frequent crashes, obviously due to it being unfinished, just thought I’d mention it incase I’m the only one.
BTW what is fake model, I can‘t work it out?
 
  • Like
Reactions: Core_2_Extreme

AleronIves

Well-Known Member
Member
Joined
Nov 17, 2016
Messages
164
Trophies
0
Age
33
Location
California
XP
1,102
Country
United States
You'll hear sound stutter at black arrow
Oh, I see. I was reading the graph wrong. I thought the purple line was the point of slowdown, but it's actually the cyan line. :blush:

I ran some more tests with different frame rates. [email protected] runs at full speed, but the animation is of course very choppy. [email protected] also runs at full speed and looks significantly better, since the fps is 33% higher. So far, I think it's the best compromise I've found, as [email protected] is very blurry, and it still has slowdown more often than [email protected] Making the resolution even lower would be pretty hard to watch.

The video player crashed in the middle of a video after I watched 6+ videos, though. Maybe there is a memory leak?

BTW what is fake model, I can‘t work it out?
Did you read the above conversation? It lets you benchmark O3DS performance using a N3DS.
 
  • Like
Reactions: Core_2_Extreme

P34ch

Active Member
Newcomer
Joined
Apr 11, 2019
Messages
29
Trophies
0
Age
45
XP
57
Country
United Kingdom
Ahh thank you AleronIves, I’d realised it was to do with benchmarking but I didn’t get what the “fake” thing was. Again another really useful addition, awesome stuff Core_2_Extreme. 👍
 
  • Like
Reactions: Core_2_Extreme

Core_2_Extreme

Well-Known Member
OP
Member
Joined
Feb 11, 2019
Messages
102
Trophies
0
Age
20
XP
664
Country
Japan
Thank you Core-2 for overlaying the video in windowed mode, such a simple but perfect solution. The 1.3.4 dev is very unstable for me with frequent crashes, obviously due to it being unfinished, just thought I’d mention it incase I’m the only one.
BTW what is fake model, I can‘t work it out?
What video and audio codec and video resolution did you use?
Also how big is your file?

Oh, I see. I was reading the graph wrong. I thought the purple line was the point of slowdown, but it's actually the cyan line. :blush:

I ran some more tests with different frame rates. [email protected] runs at full speed, but the animation is of course very choppy. [email protected] also runs at full speed and looks significantly better, since the fps is 33% higher. So far, I think it's the best compromise I've found, as [email protected] is very blurry, and it still has slowdown more often than [email protected] Making the resolution even lower would be pretty hard to watch.

The video player crashed in the middle of a video after I watched 6+ videos, though. Maybe there is a memory leak?


Did you read the above conversation? It lets you benchmark O3DS performance using a N3DS.
The purple graph shows how many compressed frame data(audio and video) is loaded into RAM if it fall down to 0 during playback you'll also likely to hear sound stutter for buffering(same thing with watching youtube on bad Internet connection).
Maybe I should add buffering for decoded data, but I don't know if it possible especially on O3DS because of low memory.

About crash, what video and audio codec and video resolution did you use?
Also how big is your file?
 

AleronIves

Well-Known Member
Member
Joined
Nov 17, 2016
Messages
164
Trophies
0
Age
33
Location
California
XP
1,102
Country
United States
Maybe I should add buffering for decoded data, but I don't know if it possible especially on O3DS because of low memory.
Well, you could add an option for that: if you want the extra buffer on O3DS, you can make the video player an "extended memory" game like Monster Hunter 4 and Super Smash Bros. You have to reboot the 3DS when launching and closing the game, but you get 96MiB instead of the usual 64MiB to work with.

If a buffer would improve choppy playback on O3DS, O3DS users would probably be willing to deal with the inconvenience of extended memory mode. In theory, if the average decoding fps is around 40, a buffer of a few seconds would be enough to fix the audio glitches when a frame takes longer than the deadline to be decoded, right?

About crash, what video and audio codec and video resolution did you use?
Also how big is your file?
I was testing 320x192 and 240x144 XviD + AAC videos using the MKV container. Each video is 10 - 15 MiB, and I was using the fake O3DS XL mode to test playback performance.
 
Last edited by AleronIves,
  • Like
Reactions: Core_2_Extreme

P34ch

Active Member
Newcomer
Joined
Apr 11, 2019
Messages
29
Trophies
0
Age
45
XP
57
Country
United Kingdom
Core_2 I’m sorry I don’t know the exact codec used, I’m using an old program for a Sony Walkman oled called Wondershare Video to Walkman Converter. Which uses an older version of h264 .mp4, Audio it just lists as AAC .mp3. Most videos I’m encoding at 800x480 and are mainly tv series around 45mins per episode, I’ve never had a problem until now. I’ve had the very occasional crash before, but it’s very frequent with this version you’re working on.
Hope this helps in some way, if I can help with anything else you want to know just ask.
 
  • Like
Reactions: Core_2_Extreme

AleronIves

Well-Known Member
Member
Joined
Nov 17, 2016
Messages
164
Trophies
0
Age
33
Location
California
XP
1,102
Country
United States
I got another crash. This time I was playing H.264 848x480 + AAC in MKV using the hardware decoder. First, I played the whole video in full screen mode, and it played fine (except it has B-frames, so the video is choppy, as expected). I played the video a second time and used the dpad + L/R to move and resize the video, and the 3DS crashed during playback with a data abort exception, translation - page fault.

Since P34ch uses the dpad + L/R to move the video a lot instead of using full screen, this may be why the player is crashing so much. I usually use full screen mode, which is apparently more stable.
 
  • Like
Reactions: Core_2_Extreme

P34ch

Active Member
Newcomer
Joined
Apr 11, 2019
Messages
29
Trophies
0
Age
45
XP
57
Country
United Kingdom
Funnily enough I haven’t really watched anything windowed on this version, I resize videos that aren’t wide/fullscreen mainly. I’ve found most crashes occur using the dpad/buttons to fast forward or change videos, but I get many random crashes whatever I do. Once anything is playing though it rarely crashes.
 
  • Like
Reactions: Core_2_Extreme

AleronIves

Well-Known Member
Member
Joined
Nov 17, 2016
Messages
164
Trophies
0
Age
33
Location
California
XP
1,102
Country
United States
Yeah, I try to avoid seeking, since it only works about half of the time. The other half of the time, it just says "Seeking" forever, and I have to press Home to exit the video player, because it won't respond to any buttons or the touch screen; however, pressing Home will sometimes cause the 3DS to crash, instead of exiting to the home menu.
 
  • Like
Reactions: Core_2_Extreme

Core_2_Extreme

Well-Known Member
OP
Member
Joined
Feb 11, 2019
Messages
102
Trophies
0
Age
20
XP
664
Country
Japan
Core_2 I’m sorry I don’t know the exact codec used, I’m using an old program for a Sony Walkman oled called Wondershare Video to Walkman Converter. Which uses an older version of h264 .mp4, Audio it just lists as AAC .mp3. Most videos I’m encoding at 800x480 and are mainly tv series around 45mins per episode, I’ve never had a problem until now. I’ve had the very occasional crash before, but it’s very frequent with this version you’re working on.
Hope this helps in some way, if I can help with anything else you want to know just ask.
I got another crash. This time I was playing H.264 848x480 + AAC in MKV using the hardware decoder. First, I played the whole video in full screen mode, and it played fine (except it has B-frames, so the video is choppy, as expected). I played the video a second time and used the dpad + L/R to move and resize the video, and the 3DS crashed during playback with a data abort exception, translation - page fault.

Since P34ch uses the dpad + L/R to move the video a lot instead of using full screen, this may be why the player is crashing so much. I usually use full screen mode, which is apparently more stable.
Funnily enough I haven’t really watched anything windowed on this version, I resize videos that aren’t wide/fullscreen mainly. I’ve found most crashes occur using the dpad/buttons to fast forward or change videos, but I get many random crashes whatever I do. Once anything is playing though it rarely crashes.

hmm, I couldn't reproduce any crash.

Yeah, I try to avoid seeking, since it only works about half of the time. The other half of the time, it just says "Seeking" forever, and I have to press Home to exit the video player, because it won't respond to any buttons or the touch screen; however, pressing Home will sometimes cause the 3DS to crash, instead of exiting to the home menu.
for forever seeking, does the app always still drawing?(e.g. can you select audio track or open explorer by pressing X button?)
if you can back to home menu I think app didn't freeze completely but some deadlock is happening in decoding thread.
 

P34ch

Active Member
Newcomer
Joined
Apr 11, 2019
Messages
29
Trophies
0
Age
45
XP
57
Country
United Kingdom
Core_2 I’ve noticed sometimes it freezes the UI pressing X, then works again after a few seconds. This is different however, frequent crashes from doing various things, as if something is being triggered in the code somewhere. Maybe something to do with adding fake mode?
The videos play through with no crashes when playing though, it’s when doing anything with the buttons it randomly crashes the system with crash dump msg.
I‘ve uninstalled and deleted the folder, then put 1.3.3 back on, and so far it seems fine, no crashes as yet.
 
Last edited by P34ch,
  • Like
Reactions: Core_2_Extreme

Core_2_Extreme

Well-Known Member
OP
Member
Joined
Feb 11, 2019
Messages
102
Trophies
0
Age
20
XP
664
Country
Japan
Well, you could add an option for that: if you want the extra buffer on O3DS, you can make the video player an "extended memory" game like Monster Hunter 4 and Super Smash Bros. You have to reboot the 3DS when launching and closing the game, but you get 96MiB instead of the usual 64MiB to work with.

If a buffer would improve choppy playback on O3DS, O3DS users would probably be willing to deal with the inconvenience of extended memory mode. In theory, if the average decoding fps is around 40, a buffer of a few seconds would be enough to fix the audio glitches when a frame takes longer than the deadline to be decoded, right?
After adding raw image buffer, playback is much much much much much much much better on O3DS.
3dsx cia
This dev version allocate up to 16 raw image buffers, still no mode changes.

And then, hw decoder behave strangely if video contain B-frames.
Difference between dev version and v1.3.3 is that dev version outputs to the different buffer every time (for raw image buffering) while v1.3.3 always outputs to the same buffer.
It seems hw decoder does process B-frames, but packet order that returned by ffmpeg is not correct for Nintendo's hw decoder???

Core_2 I’ve noticed sometimes it freezes the UI pressing X, then works again after a few seconds. This is different however, frequent crashes from doing various things, as if something is being triggered in the code somewhere. Maybe something to do with adding fake mode?
The videos play through with no crashes when playing though, it’s when doing anything with the buttons it randomly crashes the system with crash dump msg.
I‘ve uninstalled and deleted the folder, then put 1.3.3 back on, and so far it seems fine, no crashes as yet.

If it still occur in the newest dev version, could you send me a crash dump and tell me what you exactly did(e.g. pressed B button to stop playback) before crash happen?
 
Last edited by Core_2_Extreme,

P34ch

Active Member
Newcomer
Joined
Apr 11, 2019
Messages
29
Trophies
0
Age
45
XP
57
Country
United Kingdom
So far Core_2 after clean installing the new dev version stability seems improved, hopefully it won‘t start crashing now I’ve said it‘s better.
However I’ve noticed if I open the ‘Y’ menu and alter anything such as volume boost, the sound goes completely out of sync. I don’t think I noticed this before in earlier versions.
Edit: hmmm even if I pause a video the sound starts going out of sync. Then if I press ‘X’ and restart or choose another file it starts completely lagging the player, it seems there’s maybe a memory leak somewhere.
Now I’m getting crashes again, I saved the crash dump.
How do I view it to copy/paste it here, or do you want me to send it?
 
Last edited by P34ch,
  • Like
Reactions: Core_2_Extreme

AleronIves

Well-Known Member
Member
Joined
Nov 17, 2016
Messages
164
Trophies
0
Age
33
Location
California
XP
1,102
Country
United States
This dev version allocate up to 16 raw image buffers, still no mode changes.
Wow! I can play [email protected] XviD + AAC at full speed now in fake O3DS XL mode! This is a massive improvement. The average FPS is ~40 in full screen mode. If I look at the graph during playback, the stuttering comes back as expected, since O3DS doesn't have enough CPU power to decode the video and draw the graph at the same time.

Your buffer is 16 frames using O3DS 64MiB of RAM? That's pretty impressive. How much memory is the video player using now? Is this the biggest buffer you can make without using extended memory mode?

It seems hw decoder does process B-frames, but packet order that returned by ffmpeg is not correct for Nintendo's hw decoder???
I've been thinking about this. We do know that MVD_Services supports B-frames, because the video is decoded correctly. If B-frames were not supported, the picture should be completely corrupted or black until the next I-frame, because you can't skip B-frames and still be able to decode P-frames. Maybe B-frames are making MVD_Services detect the wrong FPS?

AFAIK H.264 frames are not stored in display order; they're stored out of order in a way that makes compression more efficient. If ffmpeg is putting the frames in playback order, maybe you need to send the frames in the original order to MVD_Services, and it will put them in the correct order for you? I don't know...

This build has some serious bugs, though. First, I found a new crashing problem in fake O3DS mode. Here are the steps to reproduce it:

  1. Press Y to open the debug menu and select the tab with the FPS graph.
  2. Press X to open the file menu and play a video. The player enters full screen mode automatically.
  3. Play 10+ seconds of video, then press A to pause.
  4. Press Select to exit full screen.
  5. Press B to close the video.
  6. Press X to open the file menu and pick a different video.
  7. The new video will not play when you select it.
  8. Press B to "stop" the phantom video that is not playing.
  9. Tap the down arrow twice to reach the "Press A to close the program, press B to go back" menu.
  10. Press A to close the program, but it won't close. Wait 5-10 seconds, and the 3DS will crash.

I tried both H.264 + AAC in MKV and XviD +AAC in MKV, and the crash is exactly the same. I can't run many O3DS tests with this version, because I can only play 1 video before I have to reboot the 3DS. :lol:

MVD_Services is also completely broken when I switch back to N3DS mode. I tried playing the same [email protected] H.264 video I played in the last development version, and... yikes! A person will be on the left side of the screen, and suddenly she will warp to the right side of the screen for 2 frames, and then she will warp back to the left! The screen also "throbs" in and out: it looks like the video is zooming in (everything gets bigger) and then the video zooms out again all by itself over and over! :lol:

HOWEVER! Even though the video playback is totally broken.. it looks like the B-frame stutter is gone! XD Whatever the problem is with this release, it looks like it's related to MVD_Services and B-frame support.

*edit*

I think the zooming effect is caused by frames being displayed out of order. The video has a camera zooming in, so when the frames are shown out of order, it looks like the camera is zooming in and out repeatedly.

Another scene cuts from the sky to a grassy field, so with the current MVD_Services bug, I see sky sky sky grass grass sky grass grass sky sky sky grass grass as the video player displays the frames out of order.
 
Last edited by AleronIves,

Core_2_Extreme

Well-Known Member
OP
Member
Joined
Feb 11, 2019
Messages
102
Trophies
0
Age
20
XP
664
Country
Japan
This build has some serious bugs, though. First, I found a new crashing problem in fake O3DS mode. Here are the steps to reproduce it:

  1. Press Y to open the debug menu and select the tab with the FPS graph.
  2. Press X to open the file menu and play a video. The player enters full screen mode automatically.
  3. Play 10+ seconds of video, then press A to pause.
  4. Press Select to exit full screen.
  5. Press B to close the video.
  6. Press X to open the file menu and pick a different video.
  7. The new video will not play when you select it.
  8. Press B to "stop" the phantom video that is not playing.
  9. Tap the down arrow twice to reach the "Press A to close the program, press B to go back" menu.
  10. Press A to close the program, but it won't close. Wait 5-10 seconds, and the 3DS will crash.

I tried both H.264 + AAC in MKV and XviD +AAC in MKV, and the crash is exactly the same. I can't run many O3DS tests with this version, because I can only play 1 video before I have to reboot the 3DS. :lol:
Reproduced and fixed it.

Wow! I can play [email protected] XviD + AAC at full speed now in fake O3DS XL mode! This is a massive improvement. The average FPS is ~40 in full screen mode. If I look at the graph during playback, the stuttering comes back as expected, since O3DS doesn't have enough CPU power to decode the video and draw the graph at the same time.

Your buffer is 16 frames using O3DS 64MiB of RAM? That's pretty impressive. How much memory is the video player using now? Is this the biggest buffer you can make without using extended memory mode?
I changed buffer limit to 128.
New3DS can create 120+ buffer H264 800*240 video in software decoding mode(In hw decoding mode, it will decrease since hw decoder constantly allocate 18MB and it return RGB565(2bytes per pixel) instead of yuv420p(1.5bytes per pixel)).
Old3DS can create 95+ buffer MPEG1 400*240 video.

I couldn't touch MVD service B-frame support, because I encountered a lot of unknown crash, I fixed some of them but still some crash isn't gone(maybe related to forever seeking?).

newest dev version : 3dsx cia
 

AleronIves

Well-Known Member
Member
Joined
Nov 17, 2016
Messages
164
Trophies
0
Age
33
Location
California
XP
1,102
Country
United States
So far, it seems the O3DS crashing is fixed. :)

I changed buffer limit to 128.
Does the buffer size impact decoding speed? The previous version with a buffer of 16 gave me a 40 FPS average in O3DS mode, but the new version with a buffer of 128 has decreased to 33 FPS on average. That's a pretty big drop, so maybe a buffer of 32 or 64 would be better? Unless you made another change that impacts speed, it seems like having a really big buffer is potentially worse than having a small or medium buffer.

I couldn't touch MVD service B-frame support, because I encountered a lot of unknown crash, I fixed some of them but still some crash isn't gone(maybe related to forever seeking?).
I think seeking is a separate problem. I tested MVD_Services without doing any seeking at all, and the results are a bit different from last time. Some videos play fine, but others still have major glitches, including showing frames out of order and displaying static on the screen (big bands of grey pixels that look like I tuned my old analogue TV to a channel that doesn't exist).

So far, I'm not sure what makes some videos play normally and others play with major glitches. In any event, hardware decoding is basically unusable in this version. After playing half a dozen videos, I tried to exit the player, but the system froze. I had to hold the power button to turn it off.

I also found a new bug in hardware decoding: I played an H.264 video that didn't have any video glitches, but when I pressed A to pause, the video stopped, and the audio continued to play.

The good news is the glitching isn't quite as bad as it was in the previous version, so it's possible to see half a second of clean video before the next glitch shows up. During that time, it looks like MVD_Services is handling B-frames correctly and playing the video smoothly. Sadly, the glitches make the video unwatchable.

It looks like there are some problems in N3DS software decoding, too. I can play a [email protected] H.264 + AAC in MKV video in hardware mode, but the glitchy playback is present. If I try to play the same video in software mode, it doesn't play at all. The graphs on the bottom screen don't move, as if the player tried to play frame 1 and then paused itself. [email protected] seems to work in software mode, so maybe the N3DS runs out of RAM if the buffer gets too big when you play a high resolution video?
 
  • Like
Reactions: Core_2_Extreme

Core_2_Extreme

Well-Known Member
OP
Member
Joined
Feb 11, 2019
Messages
102
Trophies
0
Age
20
XP
664
Country
Japan
Does the buffer size impact decoding speed? The previous version with a buffer of 16 gave me a 40 FPS average in O3DS mode, but the new version with a buffer of 128 has decreased to 33 FPS on average. That's a pretty big drop, so maybe a buffer of 32 or 64 would be better? Unless you made another change that impacts speed, it seems like having a really big buffer is potentially worse than having a small or medium buffer.
It was not because buffer size, but it was because linearalloc() function.
I used linearalloc() instead of malloc() in this dev version linearalloc() is not thread-safe so I manually applied mutex but that cause slowdown.
Now, I changed back to malloc() so decoding speed should same as previous dev version.
(Because of that num of buffer will drop)

Also I changed mvd work buf size from about 18MB to about 13.5MB.
if it makes crash in some video, let me know.

I think seeking is a separate problem. I tested MVD_Services without doing any seeking at all, and the results are a bit different from last time. Some videos play fine, but others still have major glitches, including showing frames out of order and displaying static on the screen (big bands of grey pixels that look like I tuned my old analogue TV to a channel that doesn't exist).
I reproduced grey pixels and it actually returned by MVD service also I can see grey pixels only first a few seconds so I though it's because MVD service received B-frame but no reference frame available(because beginning of video) so garbage image data was returned.
I don't know much about inside of H264 so it may wrong.

I also found a new bug in hardware decoding: I played an H.264 video that didn't have any video glitches, but when I pressed A to pause, the video stopped, and the audio continued to play.
However I’ve noticed if I open the ‘Y’ menu and alter anything such as volume boost, the sound goes completely out of sync. I don’t think I noticed this before in earlier versions.
I fixed sound desync.

How do I view it to copy/paste it here, or do you want me to send it?
Sorry I missed it, use the newest dev version and if crash happen, send crash dump itself or tell me what PC and Processor number says.

The newest dev version : 3dsx cia
 
  • Like
Reactions: AleronIves

AleronIves

Well-Known Member
Member
Joined
Nov 17, 2016
Messages
164
Trophies
0
Age
33
Location
California
XP
1,102
Country
United States
Now, I changed back to malloc() so decoding speed should same as previous dev version.
Yes, O3DS speed is even a little better now. It went from 33 to 42 FPS (vs 40 FPS in the previous version), and my clip no longer has any stuttering. :)

Also I changed mvd work buf size from about 18MB to about 13.5MB.
if it makes crash in some video, let me know.
Videos with 9 reference frames are still working, and the sound desync when pausing is also fixed.

I think I made some progress with MVD_Services. It looks like you have a problem with clearing the buffers somewhere. I have 2 copies of the same video. Video A has no B-frames, and video B does have B-frames. If I play video A, it works fine. I tried playing 10+ seconds into the video, and then I pressed A to pause, Select to exit full screen, and B to close the video.

Now when I play video B, I see the out of order frames, BUT the out of order frames are from the place where I stopped in video A! It looks like when you close one video and then start another video, you need to "clean up" MVD_Services, because frames from the old video are still in memory somewhere. When you play a second video, you get frames from the start of video B, AND you get leftover frames from wherever you stopped playing video A!

I also have a totally different video C that has B-frames. If I play that video as the first video after I launch the video player, the grey "static" effect is missing, but the frames are still shown out of order. If I play video B and then video C, the grey static is present. It appears the grey static is a result of trying to display frames from 2 different videos at once, and since the new video doesn't have valid references for the old video, you get garbage pixels. The grey static is missing when I play video A and video B, because they're the same clip, so the leftover frames of video A can still reference frames in video B.

I think we can draw 2 conclusions from this:

1) MVD_Services requires more cleanup when you close a video to make sure there are no leftover frames in memory before you start a new video. This should fix the grey static problem, and it may fix some of the crashing, too.

2) The B-frame stutter and out-of-order frames are both related to the new raw image buffer code. Before you added the original 16 frame buffer, the out-of-order frame problem did not exist, and we had B-frame stutter. With the buffer, B-frame stutter seems a little better, but frames are played out of order. It seems like MVD_Services is very picky about how you pass frames to it.
 
  • Like
Reactions: Core_2_Extreme

Core_2_Extreme

Well-Known Member
OP
Member
Joined
Feb 11, 2019
Messages
102
Trophies
0
Age
20
XP
664
Country
Japan
1) MVD_Services requires more cleanup when you close a video to make sure there are no leftover frames in memory before you start a new video. This should fix the grey static problem, and it may fix some of the crashing, too.

I checked libctru source code and found following code in mvdstdInit() :
C:
    mvdstd_workbuf = linearAlloc(mvdstd_workbufsize);
    if(mvdstd_workbuf==NULL)
    {
        ret = -1;
        goto cleanup1;
    }
    memset(mvdstd_workbuf, 0, mvdstd_workbufsize);
It does clean up entire mvd buffer by memset() every time I call mvdstdInit().
I call mvdstdInit() before play video and mvdstdExit() after play video, it means I already clean up entire mvd buffer every time.

2) The B-frame stutter and out-of-order frames are both related to the new raw image buffer code. Before you added the original 16 frame buffer, the out-of-order frame problem did not exist, and we had B-frame stutter. With the buffer, B-frame stutter seems a little better, but frames are played out of order. It seems like MVD_Services is very picky about how you pass frames to it.

I did some research, according to ffmpeg documentation ffmpeg returns original order not display order.
And there are two value related to packet order : pts and dts.
The video that does not contain B-frames, pts and dts are always same value.
e.g.
Code:
//one line per one video frame
//this dts and pts value are simplified in order to easy understand
dts : 0 pts : 0
dts : 1 pts : 1
dts : 2 pts : 2
dts : 3 pts : 3
dts : 4 pts : 4
dts : 5 pts : 5
dts : 6 pts : 6
dts : 7 pts : 7
dts : 8 pts : 8

Then if video contains B-frames pts and dts are not same value and it seems dts is stored order because dts is always increasing same amount per frame, but pts isn't.
e.g.
Code:
//one line per one video frame
//this dts and pts value are simplified in order to easy understand
dts : -2 pts : 0
dts : -1 pts : 17
dts : 0 pts : 8
dts : 1 pts : 1
dts : 2 pts : 2
dts : 3 pts : 3
dts : 4 pts : 4
dts : 5 pts : 5
dts : 6 pts : 6
dts : 7 pts : 7
dts : 8 pts : 9

So I suspected Nintendo's hw decoder needs to be passed pts order instead of dts.
like :
Code:
//one line per one video frame
//this dts and pts value are simplified in order to easy understand
dts : -2 pts : 0
dts : 1 pts : 1
dts : 2 pts : 2
dts : 3 pts : 3
dts : 4 pts : 4
dts : 5 pts : 5
dts : 6 pts : 6
dts : 7 pts : 7
dts : 0 pts : 8
dts : 8 pts : 9
Unfortunately it didn't work or even make situation worse.
I got out of order image + corrupt image, so out of order is not because of packet order????? idk....

I just want to share my experience : 3dsx cia
If you got different result, let me know.
Press Select button in home menu (not Nintendo's home menu) to open log.
Press ZR button to toggle reordered mode(pts order) and normal mode(same as previous dev version)
Do NOT toggle the mode during playback or it will likely to crash or freeze
Do NOT seek the video in this dev version or it will likely to crash or freeze
 
Last edited by Core_2_Extreme,
  • Like
Reactions: AleronIves
General chit-chat
Help Users
    KennieDaMeanie @ KennieDaMeanie: https://youtu.be/0e3GPea1Tyg lol dumbed down americanized squidgames