the log messages for dev type are a bug, but it does not fail the render. The function: AVHWDeviceType FFVideoStream::decode_hw_activate() is using the translation for "none" to detect the intent not to use the hw. if( hw_dev && *hw_dev && strcmp(_("none"), hw_dev) ) { Apparently your init is applying the english version, as it is in the log msg. The result of the hw probe is the same in both cases, and is not a fail. *I will change this to check both with and without get_text() so that it* *will not report if LANG is not applied.*
"Warning: Do not use the option x264opts, as it will eventually be removed. Use x264-params instead." *ok. we will change that.* f*or bluray_format, mpegts_m2ts_mode=1 *(changed to 2 by me) causes the transport stream to set the transport_priority flag if the packet is audio ac3, which is sort of a kludge... but this is necessary to get audio to reproduce on my home bluray player (samsung ubd-k8500). This was discovered by checking the diff between the ffmpeg output (which fails on player) and the "sintel" iso file from blender site (which works on player). The mode=2 triggers mode=1 and add the transport_priority flag for ac3 audio. It definitely helps here at home. Similarly, *sdt_period=-1* turns off the service descriptor table output, since this is not a broadcast stream. I am not an expert on mpegts and these changes work for me. If you have better information, let me know. *for bluray.m2ts*, you have added fake-interlaced=1 bitrate=40000 slices=4 sar=1:1 # vbv-maxrate=40000 # vbv-bufsize=30000 cin_pix_fmt=yuv420p x264opts ... vbv-maxrate=40000:vbv-bufsize=30000 These are all good, except that bitrate is computed in bdcreate.C and set in the codec parameters for avcodec_open2 call (of open_encoder). Recently we discovered that the "bitrate" param does not always work (change applied 20190922 git e620b69f). If it is specified, it seems to override the codec params (at least in some cases) and the computed rate (that prevents the disc from overflowing) is lost. If you are sure, I can add this, but I do not recommend it. Phyllis is going to try these changes, and if they work here at home, then they are good. Thanks for the good work. Stay tuned. gg
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin