View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000614||Cinelerra-GG||[All Projects] Bug||public||2022-05-26 20:23||2022-06-19 13:52|
|Platform||Linux i586||OS||Slackware||OS Version||15.0|
|Target Version||Fixed in Version|
|Summary||0000614: bitstream filtering in encoder segfault?|
|Description||I tried to add bitstream filtering to h264 encoder, as advised by documentation.|
Sadly cingg crashed on termux and on my intel i3 desktop.
Attached are experimental profile and two dumps.
|Steps To Reproduce||try to put this profile in ffmpeg/video and use it.|
|Additional Information||not sure when this mode was tested last time, in ffmpeg 4.2 times?|
|Tags||No tags attached.|
I hated to do it, but I added a short phrase in the Manual to say that the "bitstream option is currently not working".
Last edited: 2022-06-15 21:42
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:
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.
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):
encoder parameter ﬁles, the ﬁrst line is deﬁned as:
(or) muxer codec | bitstream ﬁlter [ bitstream ﬁlter options ]
where the | represents piping the codec data through the bitstream ﬁlter."
If I can find the original email where this came from, perhaps it will become clearer.
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)
|2022-05-26 20:23||Andrew-R||New Issue|
|2022-05-26 20:23||Andrew-R||File Added: h264_metadata.mp4|
|2022-05-26 20:23||Andrew-R||File Added: cinelerra_11667.dmp|
|2022-05-26 20:23||Andrew-R||File Added: cinelerra_12020.dmp|
|2022-06-11 18:40||PhyllisSmith||Assigned To||=> PhyllisSmith|
|2022-06-11 18:40||PhyllisSmith||Status||new => confirmed|
|2022-06-11 18:40||PhyllisSmith||Note Added: 0005328|
|2022-06-13 18:43||PhyllisSmith||Note Added: 0005329|
|2022-06-15 21:36||PhyllisSmith||Note Added: 0005332|
|2022-06-15 21:42||PhyllisSmith||Note Edited: 0005332||View Revisions|
|2022-06-19 13:52||PhyllisSmith||Note Added: 0005333|