[Cin] megapatch series 8

[Andrew Randrianasulu]

On Monday, April 18, 2022, Phyllis Smith <phylsmith2017 at gmail.com> wrote:

> 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).
>
>
strange, for me patch itself look different..... are you comparing to head
(before any of my changes?)



>
>
>  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/20220418/7cd0a605/attachment-0001.htm>