possible cinepack profile speedup
I basically added max_extra_cb_iterations=0 min_strips=3 this speedups encoder but quality is lower (not sure how much, was too inpatient to wait for 1 min clip encode at 352*144 25 fps! with those parameters ffmpeg encodes at nearly 3 fps, yay! In theory one can try to set up renderfarm + number parallel ffmpeg encoders, because encoder is single threaded - but I haven't tested this) also added two old (1996/8) h263 codecs - it theory they should be good for low-cpu decoding (on emulated computers for example), but apparently h263 without 'p' only good at few pre-defined resolutions? there is also speedhq.qt - for ffmpeg 4.4 (sadly ffmpeg can't encode video with alpha, as this mpeg2-like format supports...) sorry for not making progress on more important issues - I fiddled around with overlayframe.h - but I can't see my addons working? Either bug in code or I translated those blend modes wrongly.. there also two ffmpeg-4.4 patches recently added to git - they apply with patch -p1 yet not with git apply patch (misformatted patch).. Adds avc intra 300/480 if compiled against last x264 (15 june 2021)
Andrew, ok thank you. It does not look like ffmpeg 4.4 is going to make it in this month. I am going to create new AppImages tomorrow because of the gang bug which is too serious and has no workaround. also added two old (1996/8) h263 codecs - it theory they should be good for
low-cpu decoding (on emulated computers for example), but apparently h263 without 'p' only good at few pre-defined resolutions?
Did not even know h263 existed. I will test today since it is something I can actually do!
sorry for not making progress on more important issues - I fiddled around with overlayframe.h - but I can't see my addons working? Either bug in code or I translated those blend modes wrongly..
No problem, everyone should just work on what is fun and interesting for them. This bug has workarounds that are usable but tedious so we will have to tolerate that and it has existed for a long time.
there also two ffmpeg-4.4 patches recently added to git - they apply with patch -p1 yet not with git apply patch (misformatted patch).. Adds avc intra 300/480 if compiled against last x264 (15 june 2021)
For some reason, I did not make the connection that the new x264 required ffmpeg 4.4 and I tried to upgrade to it yesterday. But IMPORTANT QUESTION, the "stable" version, which is what we have always used in the past is dated around June 13th. Would it not be better to continue that policy instead of using June 15? See attached and note the box in upper left hand corner saying "stable".
On Tuesday, June 29, 2021, Phyllis Smith via Cin <[email protected]> wrote:
Andrew, ok thank you. It does not look like ffmpeg 4.4 is going to make it in this month. I am going to create new AppImages tomorrow because of the gang bug which is too serious and has no workaround.
no problems, I looked at bdwrite but it demands root and I am not yet root on this tablet. m2ts was created still... so, does this 'cut tail with ff 4.4 bug' exist for you in all resolutions/framerates as allowed by bd creation window?
also added two old (1996/8) h263 codecs - it theory they should be good
for low-cpu decoding (on emulated computers for example), but apparently h263 without 'p' only good at few pre-defined resolutions?
Did not even know h263 existed. I will test today since it is something I can actually do!
sorry for not making progress on more important issues - I fiddled around with overlayframe.h - but I can't see my addons working? Either bug in code or I translated those blend modes wrongly..
No problem, everyone should just work on what is fun and interesting for them. This bug has workarounds that are usable but tedious so we will have to tolerate that and it has existed for a long time.
there also two ffmpeg-4.4 patches recently added to git - they apply with patch -p1 yet not with git apply patch (misformatted patch).. Adds avc intra 300/480 if compiled against last x264 (15 june 2021)
For some reason, I did not make the connection that the new x264 required ffmpeg 4.4 and I tried to upgrade to it yesterday. But IMPORTANT QUESTION, the "stable" version, which is what we have always used in the past is dated around June 13th. Would it not be better to continue that policy instead of using June 15? See attached and note the box in upper left hand corner saying "stable".
in theory stable should provide stable(ish) api, but I just wanted to see if I can make this feature (new avcintra modes) works here.. I think even ff-4.3 should be compatible with new x264, but w/o new features... of course you can check out stable branch of x264... and test with this/ff-4.3 instead... I just jump ahead of locomotive sometimes
Andrew, Will check these in. cinepak changes make it run twice as fast and the mediainfo is the same except for sizes. Results from running before and after: Old: 2713 frames in 777.079 seconds / size = 34935959 New: 2713 frames in 337.795 seconds / size = 36845828 Since the new is bigger in size, it is probably better. I ran ydiff on the 2 files and although they were not a perfect match, I could not see any anomalies and they looked the same to me. I basically added
max_extra_cb_iterations=0 min_strips=3
this speedups encoder but quality is lower (not sure how much, was too inpatient to wait for 1 min clip encode at 352*144 25 fps! with those parameters ffmpeg encodes at nearly 3 fps, yay! In theory one can try to set up renderfarm + number parallel ffmpeg encoders, because encoder is single threaded - but I haven't tested this)
participants (2)
-
Andrew Randrianasulu -
Phyllis Smith