RipBot264 video transcoding loses more than 4 minutes of video

[mwalimu]

While trying to transcode a rip with RipBot264 I'm encountering some problems that seem to have to do with the frame counts. The problem was initially discovered with an .m2ts file that was output from tsMuxeR (to downconvert the audio to .ac3) but I get the same result if I load the .m2ts file directly from the BD rip.

Video is H.264. The encoding settings window in RipBot264 shows FPS 29.97, Frames 45181, Duration 0:25:7.541, but if I look in the temp folder in the file 'video - Log.txt' it includes the line 'Video track 2 contains 37178 frames.', a difference of 8003 frames. Other files in this folder have the 45181 frame count. One of the 'video - Log.txt' files (the one from txMuxeR) has more than a thousand '[v02] Video overlaps for 28 frames at playtime 0:00:08. <WARNING>' messages (with varying frame counts and playtimes). The other (the one directly from the rip) has none of these but has the same 37178 frame count (and the same result described below).

When I play the resulting transcoded file, the entire video track has been compressed down to about 20:40 (37178/29.97 = 20:40.507), followed by more than 4 minutes of repeated content, while the audio and subtitles both play for the original 25:08 length, meaning that both quickly get way out of sync with the video, on the order of minutes by the end of the program.

I can play either of the aforementioned .m2ts files in VLC and both play the video content for the correct 25:07 length. Even the 'video.mkv' files in the RipBot temp folders play for 25:07. It seems only the transcoded output plays as 20:40. The issue seems to be that the transcoding process uses the 37178 as gospel rather than the 45181, losing more than four minutes of video. (I'm not having any issues with audio, subtitles, or chapter marks.)

Any suggestions what to do to get a transcoded video that plays for the correct length?

[mwalimu]

No ideas? Are there any reports I could run on the original .m2ts file and post here that might be helpful?

Maybe what's needed is to somehow "minimally repair" (but mostly just copy) the h264 video stream so that RipBot will recognize it as having all 25+ minutes of video content instead of losing nearly 4.5 minutes worth.

[davexnet]

You could post the mediainfo (text view) of the source.
Have you tried encoding in something else, such as Vidcoder?

[mwalimu]

For reasons I can't go into here, it has to be RipBot. I thought about trying another encoder as a matter of curiosity just to see if they encounter essentially the same issue. Also, I've successfully ripped and transcoded dozens of BDs and this is the first time I've encountered this particular issue. The ones I've encoded in the last week and a half since the original post here, I checked the frame counts in 'video - Log.txt' vs. 'info.txt' and they matched exactly.

Mediainfo:
General
ID : 0 (0x0)
Complete name : G:\BDCopy\GSG_S2_D1\BDMV\STREAM\00101.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 5.37 GiB
Duration : 25 min 10 s
Overall bit rate mode : Variable
Overall bit rate : 30.6 Mb/s
Maximum Overall bit rate : 48.0 Mb/s

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : 27
Duration : 25 min 7 s
Bit rate mode : Variable
Bit rate : 28.0 Mb/s
Maximum bit rate : 39.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Scan type, store method : Interleaved fields
Scan order : Bottom Field First
Bits/(Pixel*Frame) : 0.451
Stream size : 4.92 GiB (92%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Muxing mode : Stream extension
Codec ID : 131
Duration : 25 min 6 s
Bit rate mode : Variable
Bit rate : 640 kb/s
Maximum bit rate : 4 569 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 115 MiB (2%)
Service kind : Complete Main

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Muxing mode : Stream extension
Codec ID : 131
Duration : 25 min 9 s
Bit rate mode : Variable
Bit rate : 640 kb/s
Maximum bit rate : 2 805 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 115 MiB (2%)
Service kind : Complete Main

Text #1
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Delay relative to video : 10 s 944 ms

Text #2
ID : 4609 (0x1201)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144

[davexnet]

I have seen in the past files with scan type MBAFF can cause this kind of problem.
I'm not sure what mechanism Ripbot32 uses to open files if you open them directly;
I've only ever used it when feeding it an AVIsynth script and have the script open the file -
that way, I can control the source file filter
Perhaps somebody who knows will chime in