[Cin] megapatch series 8

Phyllis Smith phylsmith2017 at gmail.com
Mon Apr 18 06:02:22 CEST 2022


Andrew,
Tomorrow I am going to make one last test (still without chapters) and
check this mini_pile into GIT, but 1 more question.
>From megapile_10,
0015-Attempt-at-fixing-bdwrite-stream_type-coding_type-co.patch, I think
the case renumbering of 3 and 4 may be incorrect.
Currently the code for case 3 and 4 is different than what it used to be
-- I think these numbers mean something (although 0x03 versus 3 is OK and
0x04 versus 4 is OK).  See this diff in bdwrite.C :
*Before =  *                                        *After =*
  case 0x04:                                       case 4:
    bs.write(subpath_id, 8);                        bs.write(subpath_id, 8);
    bs.write(subclip_id, 8);                        bs.write(pid, 16);
    bs.write(pid, 16);                              break;
    break;

  case 0x03:                                        case 3:
    bs.write(subpath_id, 8);                          bs.write(subpath_id,
8);
    bs.write(pid, 16);                                bs.write(subclip_id,
8);
    break;                                            bs.write(pid, 16);
                                                      break:

Could you check this??

On Sun, Apr 17, 2022 at 12:01 PM Andrew Randrianasulu <
randrianasulu at gmail.com> wrote:

>
>
> On Sunday, April 17, 2022, Phyllis Smith <phylsmith2017 at gmail.com> wrote:
>
>>
>>
>> The 2 modifications I made are in bdcreate.C to temporarily comment out
>>>>>> the choices of lpcm and truehd as neither 1 works for me (see error
>>>>>> messages in previous email).
>>>>>>
>>>>>
>>>>> those mesages come from players themselves?
>>>>>
>>>>
>>>> No, from bdwrite -- see the last line in the terminal output below for
>>>> the error message when I choose "truehd" and then "lpcm".  I verified that
>>>> 0004-Improve-truehd-decoder-encoder-from-ffmpeg.git.patch is in as well as
>>>> all of the patches as stated earlier.
>>>>
>>>
>>>
>>> be sure there is no old bdwrite binary in PATH?
>>>
>> It is rare that I change $PATH from or even add cnelerra:
>> /root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
>>
>
>
> still, old bdwrite may lay here.. I say with some confidence because
> fully-patched bdwrite binary even output different error message for stream
> type!
>
> try to add some your own string ( fprintf ("my cool string\n";) into code
> of bdwrite (right into main {} function) and see  if it printed when script
> executes?
>
>
>
>>>
>>>
>>>  PATH=/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/tmp/cinelerra-5.1/bin
>>>
>>
>>
>>> However, the choice of "tsmuxer" works, or at least does something and
>>>>>> creates no problem but I do not see or hear any difference if checked off
>>>>>> or on.
>>>>>>
>>>>> you need to have tsmuxer binary in $PATH   to see it used
>>>>>
>>>> I wonder why the output is different when I check the tsmuxer box than
>>>> when I don't?
>>>>
>>>> Because I do not check for tsmuxer existence in C code, and just  write
>>> universal sh script doing check for us?
>>>
>> Never mind -- it is different just when running it twice so there must be
>> timestamps in it.
>> I did download tsmuxer source code, but when it said I needed "ninja", I
>> stopped and just laughed.  Maybe later I will try again.
>>
>
> yeah, I have this installed for mesa3d builds mostly...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220417/669df271/attachment.htm>


More information about the Cin mailing list