9/11/2023 0 Comments Avidemux 32bit![]() Your predicate was correct a few years ago, when (some) people burned their video to CDs. XVID/AVI is definitely not the latest and greatest, but it is the most accepted combination across media players.Your are talking about (old) standalone players. Obsolete, low-quality, and unmaintained container and codec interfaces will be dropped, including AVI, OGM, and Xvid." source Quote"0.9.4 will also include a drive towards refocusing on the project's core strengths and pruning dead weight. Why focusing development on old technics? MPEG-4 Part 2 producing encoders (like Xvid) are indeed rather old. Maybe this is one of the reasons why they dropped support for xvid in handbrake?No, it's not. Media info for the second video (XVID/AVI):įormat profile : Advanced settings, BVOP : 2įormat settings, Matrix : Default (H.263) Transfer characteristics : BT.709-5, BT.1361 Media info for the original AVC/AVI Video:Ĭolor primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M XVID/AVI is definitely not the latest and greatest, but it is the most accepted combination across media players. Maybe this is one of the reasons why they dropped support for xvid in handbrake?Īvidemux 2.6.4 would be a standout if it could transcode VFR AVC/MKV into XVID/AVI. ![]() So it seems that most frames are being recoded with the older library. With XviD63 (avidemux 2.5.6) the video stream size is only slightly undersized but more than double that with XviD64. I'll try another sample (xvid without a packed bitstream this time) but think the result will be the same. Its possible both video's are problematic for "XviD64" causing frames to be dropped. Recoded to XVID in AVI and it also undersized a lot: Then I took another video with XVID in AVI. I created 2 remuxed MKV versions: An avidemux copy into MKV and a remux with MKVMerge.Īfter that both MKV versions are "editable"įrom those MKV's I cut edit a sample and both undersized with XVID. Must admit I didn't see that from looking at the video.Īre the frames being dropped at the decoding stage or recoding stage?Īvidemux could play it fine but not edit it. I guess these dropped frames are replaced with duplicates since the frame rate / video duration remains the same. Interesting that as much as half the frames are being dropped. I noticed the r8887 change log for xvid to allow setting min & max Q. ![]() Not sure if this issue is isolated to my particular setup (just a normal windows 7 - 64 bit - clean install). Recoding with single pass constant bit rate also produces unpredictable end results. Setting the video size on recoding this sample with MPEG4 ASP (xvid4) produces an unpredicatable result.Ģ pass - video size at 10 MB gives video bit rate of 766 KbpsĢ pass - video size at 30 MB gives video bit rate of 1800 Kbps - about 18MB file sizeĢ pass - video size at 50 MB also gives video bit rate of 1800 Kbps - identical 18MB file size as for "30 MB" case. everything works out as expected but not so with Avidemux 2.6.4. In turn this defines a certain video stream size. Normally I encode to achieve a certain bits per pixel value (video qualiy). Hence this new thread to discuss these observations seperately. That thread is about an oversizing issue on Mpeg4 AVC rather than an undersizing issue with Mpeg4 ASP. I mentioned this issue in another thread "Avidemux 2.6.4 - H.264 encode by video size is massively broken". ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |