justdan96
“Not enough buffer to parse video frame” occurred constantly when encoding a large UHD MP4 file to AVCHD-FOLDER
I have made a large UHD 3840x2160 original MP4 file from something like Adobe Premiere Pro CC 2019. When I extract the MPEG4-ISO-AVC-H264 Track from the video clip with FFMPEG and re-encode to AVCHD-FOLDER via TSMUXERGUI-git-ac9b47c, it continuously report an issue called "Not enough buffer to parse video frame" This annoyed me much because I don't want to downgrade and smaller my original video clip with any third-party encoders like FFMPEG or the others
@xingchenli1996 please give a link to a <50MB sample -you can cut the ta e.g. with an hex editor.
@xingchenli1996 please give a link to a <50MB sample -you can cut the ta e.g. with an hex editor.
I wonder which kind of file type is the one I should give you. For example a file copied from my hex editor or one of any 50MB part of my original file or something else？
@xingchenli1996 you can give sample of either your .h264 or the remuxed .ts; as long as I can reproduce the bug it is fine.
@xingchenli1996 you can give sample of either your .h264 or the remuxed .ts; as long as I can reproduce the bug it is fine.
OK, later I will upload several h264 frames from the middle of the original MP4 where errors has occurred to my webdisk
@xingchenli1996 you can give sample of either your .h264 or the remuxed .ts; as long as I can reproduce the bug it is fine.
https://1drv.ms/u/s!Agvg88mocIyRhkvP6wk36lEze2Cj?e=xe5hQQ
Here is the H264 File from the middle part of the video at the point TSMUXER start to show me "not enough buffer" errors
@xingchenli1996 you can give sample of either your .h264 or the remuxed .ts; as long as I can reproduce the bug it is fine.
when can this problem be solved? It annoyed me so much when dealing with large MP4/MOV Files produced by DaVinci Resolve 16.2 or Adobe Premiere Pro CC 2019 without a downgrade-second-time-transcoding.
@xingchenli1996 tsMuxer is open source, you just have to wait for somebody volonteering to solve this on his free time. I've had a look at your sample: 18 successive large I-frames, so whatever the size of the video buffer it is likely to overload it. What is the aim of having no B or P-frame ?
@xingchenli1996 tsMuxer is open source, you just have to wait for somebody volonteering to solve this on his free time. I've had a look at your sample: 18 successive large I-frames, so whatever the size of the video buffer it is likely to overload it. What is the aim of having no B or P-frame ? Thanks a lot.
but if any B or P frame exist in a large video, they can cause my re-encode Video to become a picture of mosaic. the only way currently I can do is that I have navigated to the error point where TSMUXER continuously showed me that annoying message and I am about to insert some number to the line 10 of the Source File /mpegStreamReader.h/ as a HACK large enough to block the error message and bypass its Bitrate Limit. I think it should take effect.
@jcdr428 This is overflowing the temporary buffer, then? Can we see what the overall impact is of changing that number? I am just thinking if the only impact is (say) memory usage then we might be able to add an option for the user to override the value on the command-line or something like that.
@justdan96 I'm not too sure of the impacts of changing the temp buffer size. The situation here (succession of large I-frames) is uncommon, not sure it is worth taking the risk.