View Issue Details

IDProjectCategoryView StatusLast Update
0000614Cinelerra-GG[All Projects] Bugpublic2023-06-27 17:15
ReporterAndrew-R Assigned ToPhyllisSmith  
Status closedResolutionfixed 
PlatformLinux i586OSSlackwareOS Version15.0
Product Version 
Target VersionFixed in Version 
Summary0000614: bitstream filtering in encoder segfault?
DescriptionI 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 Reproducetry to put this profile in ffmpeg/video and use it.
Additional Informationnot sure when this mode was tested last time, in ffmpeg 4.2 times?
TagsNo tags attached.




2023-06-27 17:15

manager   ~0005519

Now working so closing.


2023-06-22 15:30

manager   ~0005516

The update of FFmpeg library at some time, fixed this issue for CinGG. Will close soon.


2023-06-14 23:42

manager   ~0005506

> 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.


2023-06-14 18:16

reporter   ~0005505


> 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 ..


2023-06-14 16:35

manager   ~0005504

Last edited: 2023-06-14 16:43

View 3 revisions

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.



2023-06-13 19:56

reporter   ~0005502


> 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 ...


2023-06-13 17:23

manager   ~0005501

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?


2023-06-06 17:32

reporter   ~0005496

@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 ..


2022-06-19 13:52

manager   ~0005333

I hated to do it, but I added a short phrase in the Manual to say that the "bitstream option is currently not working".


2022-06-15 21:36

manager   ~0005332

Last edited: 2022-06-15 21:42

View 2 revisions

Will have to leave this open until some expert in ffmpeg comes around. But 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.



2022-06-13 18:43

manager   ~0005329

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.


2022-06-11 18:40

manager   ~0005328

Yes, sadly it crashed for me too but I am going to look at it to see if the parameters make sense to me.


2022-05-26 20:23


h264_metadata.mp4 (146 bytes)
cinelerra_11667.dmp (52,260 bytes)
cinelerra_12020.dmp (62,936 bytes)

Issue History

Date Modified Username Field Change
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
2023-06-06 17:32 Andrew-R Note Added: 0005496
2023-06-13 17:23 PhyllisSmith Note Added: 0005501
2023-06-13 19:56 Andrew-R Note Added: 0005502
2023-06-14 16:35 PhyllisSmith Note Added: 0005504
2023-06-14 16:39 PhyllisSmith Note Edited: 0005504 View Revisions
2023-06-14 16:43 PhyllisSmith Note Edited: 0005504 View Revisions
2023-06-14 18:16 Andrew-R Note Added: 0005505
2023-06-14 23:42 PhyllisSmith Note Added: 0005506
2023-06-22 15:30 PhyllisSmith Status confirmed => resolved
2023-06-22 15:30 PhyllisSmith Resolution open => fixed
2023-06-22 15:30 PhyllisSmith Note Added: 0005516
2023-06-27 17:15 PhyllisSmith Status resolved => closed
2023-06-27 17:15 PhyllisSmith Note Added: 0005519