I either can't figure out how to use this patch or the patch will not work due to the difference in checksum when creating a bat file.
If possible could you provide the patch for the fixed m2ts file itself.
So what I mean is your extracted raw h264 from this m2ts file and muxed back into .m2ts and creating a patch from that.
> I either can’t figure out how to use this patch or the patch will not work due to the difference in checksum when creating a bat file.
> If possible could you provide the patch for the fixed m2ts file itself.
>
> So what I mean is your extracted raw h264 from this m2ts file and muxed back into .m2ts and creating a patch from that.
It's a xdelta3 patch.
I try my best to re-encapsulate the 264 and wav files but either tsMuxer or ffmpeg or other open-source tools can't generate the exactly same(except the fixed part) M2TS file. Every packet in M2TS is slightly different from the original one, causing the whole patch file very huge, if you know what I mean.
For using this patch, prepare xdelta3(to apply the patch) and ffmpeg(to extract the raw 264 stream, tsMuxer should also work), do the following instructions:
```bash
$ ffmpeg -i 00006.m2ts -an -vcodec copy 00006.264
$ xdelta3 -v -d -s 00006.264 00006_fixed.track_4113.264-00006.track_4113.264.delta 00006_fixed.264
```
And mix them with ffmpeg or mkvtoolkit or tsMuxer or any other format/tool you like, for example:
```bash
$ ffmpeg -i 00006_fixed.264 -i 00006.m2ts \
-c:v copy -c:a copy -strict experimental \
-map 0:v:0 -map 1:a:0 -map 1:a:1 00006_fixed.m2ts
```
Are you on linux? I'm on Windows.
The patch will not work at all because the checksum does not match what your patch is asking for due to different CRC values. It's pointless for me to get a raw .264 file if the CRC is going to be different. I dunno how it is on linux but on Windows it requires the checksum match as I keep getting XD3_INVALID_INPUT
Indicating the source file is incorrect.
So if you don't mind could you provide a patch using your muxed and fixed m2ts file. Preferably in .vcdiff
Otherwise this is pointless.
Also, I use megui to obtain a raw file however its in .h264 format not .264 using HD Stream Extractor via eac3to. I can rename the file to .264 and it'll play it just as it would if it was in .h264.
> I use megui to obtain a raw file however its in .h264 format not .264 using HD Stream Extractor via eac3to.
I get the point. Different tools may extract different 264 files since some units in 264 stream are useless so some of those may be abandoned, causing the different CRC. Actually I used tsMuxer for extration. The 264 files are slightly different in size.
Here's the patch for MeGUI extracted one:
http://s000.tinyupload.com/index.php?file_id=84644978865689881526
The CRC32 of extrated h264 :
> 00006_T1_Video - .h264
> Size: 4962405004 Bytes
> CRC32: 1FBC2A7E
And here's the fixed 264 clips, the exact frame sequence number are indicated by file name (counting from 0), so you may fix with these:
http://s000.tinyupload.com/index.php?file_id=03220572578022952531
http://s000.tinyupload.com/index.php?file_id=00428693915629673945
Good luck.
Thanks. The http://s000.tinyupload.com/index.php?file_id=84644978865689881526 seems to work. Surprised that it gave me the same CRC 1FBC2A7E as yours did.
However, attempting to putting it into a m2ts container using megui's txmuxer has given issues.
https://pastebin.com/MjSF1wcb
Do you know what the log means? As after it gives the error and I play it back the frame gets stuck on the problematic frames on MPC.
Have you attempted to put it into a m2ts container?
Everything works fine in the mkv container tho with no issues of both muxing and playback. Should I just settle on this?
> However, attempting to putting it into a m2ts container using megui’s txmuxer has given issues.
> https://pastebin.com/MjSF1wcb
```
---[Error] [3/6/2020 8:14:23 AM] Bad SEI detected. SEI too short
---[Error] [3/6/2020 8:14:23 AM] H264 warn: Unexpected pic_order_cnt_lsb value 205. FrameNum: 21449 slice type: I_TYPE
```
`SEI` refers to *Supplement Encoding Information* unit defined in H264/AVC standard, and it's not essential for decoding process. And the exact `pic_order_cnt_lsb` of the logged frames I found in stream analyzer are actually correct, maybe something happened while concatenating the splited streams using ffmpeg. The M2TS muxer may report warning (not error actually, `H264 warn`) since they are strict to the standard, which requires SEI between every frames. Actually all my efforts on re-pack the streams into the bitwise M2TS file are vain as the business Blu-ray authoring software are so strict to the standard, for which x264 fails to generate adequate SEI unit between frames.
Regarding to mkv container, the mkv muxer itself will abandon some unit like SEI or AUD (delimiter between frames in 264 stream) and etc, in other word, not so "strict" as M2TS.
They are both of little importance for playback or re-encoding, no big deal.
Alright, thanks a lot for your patience and supplying a patch for those interested in fixing the frame problem.
Sucks for BDMV users who wanna burn this and sucks even more the uploader hasn't replied back nor offered another share of this with corrected frames (or maybe he/she can't).
Haven't tested out encoding the fix yet hopefully it won't cause issues. Thanks again for your time and help.
Comments - 13
tsumo
bellotax
Arsy
zatanico21
warui
gyakkun
warui
gyakkun
warui
gyakkun
warui
gyakkun
warui