- Decoupled SEQ event from GOP event.
Now behaves like real VMPEG hardware
- Fixes Lost Ride gameplay after vehicle charge intro
- Fixes timing accuracy of temp ref and time code
Measurable with mv_status()
- Replaced stub with actual data from stream
- Fixes value of MAS_Head as returned by ma_status()
- Stereo and Mono are correctly detected by VCD bridge
- Added slow motion mode
- Added support for single step
- Fixes playback control problems with "Imagination in Motion - A New Era in 3D Chill Out Video"
This commit introduces technical debt
- The stepping mechanism is not fully understood
- Slow motion seems to desync audio and video when resuming normal playback
With the current state, the playback speed is still dictated
by the MPEG decoder. It might be possible, that this is wrong.
- Fixes data corruption when output
buffer is full with 26 frames
I was able to prove that 30 framebuffers
are not enough when allowing 26 of them
to be queued for viewing.
There is a certain distance between
allocation and actually offering the framebuffer
to the queue of ready frames.
It can reach up to 5 frames, it seems.
This is probably the result of B and P frames?
- Fixes long videos with even smaller frame size
- Fixes even more videos in "Les Guignols de l’Info"
This is the change of b8e3bac amplified.
The failing video this time is at seek position 0xB278800.
The previous one failing was 208x128, this one is
even smaller with 160x112.
It reaches a FIFO level of 21 until playback is started
even on real hardware.
- Fixes long videos with small frame size
- Fixes videos in "Les Guignols de l’Info"
A user has mentioned that "Les Guignols de l’Info" sometimes has problems with videos.
After analysis of "/cd/rtf/application.rtf" from said disc,
starting at byte position 0x11DEA000, it turns out that the
pictures in FIFO (0x0E040A4) can go up to 17 even on real hardware.
This has never happened before and I've assumed that 8 is the maximum.
This is an issue because DecodTS of fdrvs1 calculates the DTS of the next picture with
the formula GEN_DEC_TIM1 (0x0E040A0) - GEN_PINF (0x0E040A4) * GEN_PICT_RATE (0x0E040A8).
This means that GEN_DEC_TIM1 is constantly increasing but GEN_PINF was limited to 8
before. This resulted in having the next picture to show getting more and more out of reach
of V_SCR.
On real hardware, the FIFO reaches 14 until playback starts.
This library is not suited for playback of short MPEG files and
pauses in stream delivery at the same time.
If the stream has not enough data, frame generation is aborted.
So one would assume to just always wait until enough data
is there to decode. But that is trap, because short MPEG files
are never decoded on time.
This fix does 2 things
- If enough data for one frame to decode is available, communicate
at least 1 frame in the FIFO to the driver even so it is not yet
fully commited by pl_mpeg.
- Don't wait for data as soon as the driver has
instructed VMPEG to decode and play. I would guess that the buffer is
filled enough at that point to not underflow.
- Since my guess was wrong as underflows can still occur,
to abort the wait, the output buffer must be empty too.
There is also another fix here. The worker descriptor must now
be manually committed to increment the command counter.
Since waiting for data can now be aborted, it is possible
that a requested buffer for a worker descriptor needs to be thrown away,
which resulted into a wrong increment and an assertion failure ont the worker side.
- Increases computing power for pixel operations
- Fixes freeze at timecode 04:32 of
"Star Trek VI - Terre Inconnue (France) (Disc 1)"
during the shock wave scene
- Reduces CPU load of decoder core
- Fixes playback of "Secret of Nimh (VCD)"
- Fixes freeze in the early minutes of
"Star Trek VI - Terre Inconnue (France) (Disc 1)"
There is no evidence yet for an indication by VMPEG driver code,
that the sequence header cache needs to be discarded.
The FMV bitstream decoder firmware will now check whether a header
exists during the startup of the decoding process.
If one exists, the cache is not used.
- Fixes regression between CDi_dvc_rc2 and CDi_dvc_rc3
caused by using a cached but wrong SEQ HDR
in an attempt to fix memory errors after resets.
The error is no longer occuring
- .bss segment erase no longer overwrites first word of .noinit
- .data segment no longer overwritten by itself
Also added an endurance test which scans through the video
and tries to encourage this issue
- Frame buffer indexes kept between resets
- Avoids display of not committed buffers
- Discard frames until first I frame
- Avoids corrupted graphics during scanning
- Sequence header configuration protected from restart
- Configuration validity stored outside of soft core
- Fixes continuing playback of "Coneheads" which
only has one SEQ header at the start of whole stream
- Fixes scanning through Top Gun
- Added EOI - ISO 11172 End Code detection in demuxer
- Added EOS - Sequence End Code detection in decoder firmware
- SEQ, GOP and PIC no longer generated by bitstream decoder
- PIC now aligned to vblank before a new picture is shown
- SEQ and GOP now aligned to PIC when its the first I frame of a GOP
- LPD now aligned to PIC when it was the last picture
- BUF - Buffer underflow now detected by firmware
- Added pictures in FIFO register (00E040A4)
- Added DTS register (00E040A0)
- Added VDI register for DTS updates (0E0408C)
- FMV Playback start no longer decided by demuxer but by VMPEG ROM
- Added pixel width calculation for later use
- Fixes hang at the end of the Space Ace Intro
Names of events to according
https://github.com/TwBurn/cdi-docs/blob/main/mv_cbnd.md#mv_trigger-define-mpeg-video-events-to-signal
Removes dependence to https://github.com/Slamy/fpga_soft_mpeg
to ease change management.
Matching git hashes from said repo:
Audio 2fd79f6ff5445baaa5634f66cd0ef83643db4704
Video 8d0abb4b85d0626d35263aa5facc387123e36f2a
Expected md5sums with this commit
0489b54f46a11e1ded36e4a2d51d0e9f ./rtl/mpeg/fma/firmware.mem
8673facd20983f1dfa4c4d301a374338 ./rtl/mpeg/fmv/firmware2.mem
c16c0dfde857b47c6fe251d4e8deb5ab ./rtl/mpeg/fmv/firmware.mem
