In this case your Xvid seemed to be unpacked though, so that can’t be the problem.
When in doubt, always test avi files with the application ‘mpeg4 modifier’ before muxing it, and if it has ‘packed bitstream’, unpack it. * two: never put an Xvid stream that has the ‘packed bitstream’ hack inside a matroska container. With these command line options it becomes simply “Version 2”, as it were with versions of mkvtoolnix prior to v6. It shows up in the field “Format Version” as “Version 4 / Version 2”. Videos that skip forward 10 mins almost instantly without that extra data, take almost forever to do the same with it. In my experience, that data messes up the navigation of matroska files played on the WDTV, badly.
The last one probably doesn’t have any bearing in your issue, but the first two combined ( " -engage no_cue_duration -engage no_cue_relative_position") disable the addition of cue data related to the ‘version 4’ of the Matroska format. Unlike the option you mentioned (–engage native_mpeg4) these are perfectly safe, they just remove things that were added in versions 6 and 7 of MMG. *one: I would remux all Matroska files with the " -engage no_cue_duration -engage no_cue_relative_position -disable-track-statistics-tags" options as a permanent part of mmg. Only with the family of MPEG-4 / ASP codecs.Įven though the video you labeled “bad” seems to play well for me I would recommend a couple of generic things to help solve this issue: None of these happen with other codecs, thankfully.
#Avidemux 32bit mp4
AVIs seem to make pretty long pauses when you start/skip the video, sometimes mp4 reproduction stops when you rw/ff, and some matroska files seem to have ‘micro-stutters’. DivX, XviD, etc…) regardless of the container in which they are muxed has been very poor with the last few firmware versions. My experience all around with Mpeg4 ASP (e.g. * In the mmg-window under “Muxing” / “Add command line options” / “# Development hacks #”. Playback is without stuttering or jerkiness after doing this, which suggests that there’s nothing wrong with the file, but with how the SMP is handling it. Native.mkv hack: DURATION : 00:00:32.241000000Īnother workaround is to start playing the stuttering file, pause and skip back to timecode 00:00. Note the differences in the logs of the two MKVs.ĭefault.mkv: DURATION : 00:00:32.283000000Ĭodec ID : V_MS/VFW/FOURCC / XVIDCodec ID/Hint : XviD If something is considered to be an officially supported option then it’s NOT in this list!Īnalyze MPEG4 bitstreams, put each frame into one Matroska block, use proper timestamping (I P B B = 0 120 40 80), use V_MPEG4/ISO/… CodecIDs. This option is NOT supported and its usage is NOT recommended by the Matroska-developers (from mmg): Test-native.mkv : Remuxing of test.avi using mmg.exe 7.1.0 with the commandline option* “–engage native_mpeg4” enabled. _STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTESįormat profile : Advanced settings, BVOP : Yes _STATISTICS_WRITING_APP : mkvmerge v7.1.0 (‘Good Love’) 32bit built on 12:59:18 Writing library : libebml v1.3.0 + libmatroska v1.4.1 Writing application : mkvmerge v7.1.0 (‘Good Love’) 32bit built on 12:59:18 Playback is jerky (looks like 10fps) or has microstutters every other second, depending on the setting of “match framerate”. Test-default.mkv : Remuxing of test.avi using mmg.exe 7.1.0 with its default settings. Writing library : VirtualDub build 35491/releaseįormat profile : Advanced settings, BVOP : 1įormat settings, Matrix : Default (H.263) Test.avi : Reference file, playback is fine. Remuxing any Xvid-videostream into MKV is being played with microstutters or jerkiness in general on the SMP.
0 kommentar(er)
