 |
Now working so closing. |
|
|
The update of FFmpeg library at some time, fixed this issue for CinGG. Will close soon. |
|
|
@Andrew-R > Also, does h264_vaapi/mkv + global_headers bitsteam filter works on AMD now? Yes, as far as I can tell, everything is working on both AMD and Intel/HP laptops. No, CinGG is NOT broken in TV recording -- the laptop I use next to the TV has an older Graphics Board that does not work with newer Fedora Operating Systems so it has been left with the old O/S and no upgrades on any software. Thus, just leave CinGG at the old version. But I routinely build the latest CinGG on /tmp just for testing. |
 |
@PhyllisSmith > it works for recording from the TV to CinGG so I can watch later. Does this mean new cingg somewhat broken in this area? I have no tuner card/box for testing this functionality, and testing device in kernel does not behave exactly like tv card ... at least with my incompetent tuning. Also, does h264_vaapi/mkv + global_headers bitsteam filter works on AMD now? Sorry for keeping you busy with so many testing requests - I hope to make new boot flash drive with my current system on it "soon" (next week?) and boot on intel/amd laptop .. |
|
|
@Andrew-R @Andrea_Paz I get the "bozo award" of the year this year. The bitstream DOES work on Intel chip/HP laptop with using ffmpeg 5.1. I was using an old CinGG binary which was compiled with an old ffmpeg, but I have good reasons for leaving that version on that laptop -- it works for recording from the TV to CinGG so I can watch later. I will update the manual and delete the 1 line there and checkin h264_metadata.mp4 ffmpeg/video render format soon. (And, yes, the standard vaapi encoding profile still works but I did not bother testing standalone ffmpeg once I discovered my error. Glad you check up on me!) Also, will mark this Resolved in a couple of days and then next time new AppImages are made will close. |
|
|
@PhyllisSmith > standard Intel chip on an HP laptop crashes in all 3 cases quite quickly. ow! Does standard vaapi encoding profile still works? Does standalone ffmpeg still works with vaapi encoder but without bitstream filtering there? I think if it still crashes on Intel only in cingg we still can't call it working .. My goal was making mkv videos with h264 out of AMD encoder, but having this work in generic case sounds like useful improvements ... |
|
|
@Andrew-R @Andrea_Paz Interesting results. No more crashes on AMD chip laptop computer (running ffmpeg 6.0 / did not try 5.1) either with No hardware device or with Vaapi or fake Vdpau. So that is a win. BUT standard Intel chip on an HP laptop crashes in all 3 cases quite quickly. Do you recommend I do more tests on other AMD computers and Operating Systems? For example, ubuntu 16 on AMD and Debian 11.0 on different laptop (can not remember of AMD or Intel)? If it works on several of the AMD computers, should I change the manual to say it will work on some but maybe not others? |
|
|
@PhyllisSmith can you re-try on AMD vaapi platform? I think we fixed one type of such crashes but not sure if original crash still here .. |
|
|
@Andrea_Paz I hated to do it, but I added a short phrase in the Manual to say that the "bitstream option is currently not working". |
|
|
@Andrew_R Will have to leave this open until some expert in ffmpeg comes around. But anyway...got your last email on this subject and with the references to GIT that you provided, I couldn't resist testing some more. Some interesting results. 1) Testing the following older versions, I immediately get the error "check_frame_rate failed" on a file that has creation time metadata because older CinGG code did not allow that file's framerate yet. 2) But on 2 files that don't have metadata on these 2 versions, it starts working and then Segv-s. 3) And the interesting thing is that if I purposely misspell "display_orientation=insert", it ALSO starts working and then fails. Jun 21 2019 ffmpeg 4.1 Feb 14 2018 ffmpeg 3.4.1 Apr 11 2017 ffmpeg 3.1.4 Testing the current Jun 9 2022 ffmpeg 4.4 for the numbered lines above, I get 1) None of the 3 test videos produced the "check_frame_rate" error -- so this is irrelevant 2) Segv's on all files after starting to work 3) And interesting, misspelling CORRECTLY provide the error messages in Verbose mode: FFMPEG::open_encoder err: Option not found int FFMPEG::open_encoder(const char*, const char*): bitstream filter failed /tmp/junk.mp4: h264_metadata=displau_orientation=insert So bottom line is that this may never have been fully tested in earlier ffmpeg versions so is actually working the same as it did then, except a little better because at least you can tell it is trying to do something with metadata because of 3) error message. |
|
|
@Andrew-R Looks like this will require some serious analyzing. In checking other render formats, there are zero that have any parameters like: ... | h264_metadata=crop_left=20:crop_right=20 on the first line next to only the 2 parameters like: mp4 libx264 And this is really interesting because to quote the manual (which I did not even know was there and do not remember ever having discussed this): "In typ.ext encoder parameter files, the first line is defined as: muxer codec (or) muxer codec | bitstream filter [ bitstream filter options ] where the | represents piping the codec data through the bitstream filter." If I can find the original email where this came from, perhaps it will become clearer. |
|
|
@Andrew-R Yes, sadly it crashed for me too but I am going to look at it to see if the parameters make sense to me. |
|
|
h264_metadata.mp4 (146 bytes) cinelerra_11667.dmp (52,260 bytes) cinelerra_12020.dmp (62,936 bytes) |
- Anonymous
