[Cin] megapatch series 8

[Phyllis Smith]

I will fix it, do not need a patch (and will retest chapters again).

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

> oh YES, you are right, I swapped those unintentionally!
>
> probably explains your bug with chapters? I used
>
> $ git diff 66e7bfbe cinelerra/bdwrite.C
>
> and yes, please switch cases 2/3 and 4 as they originally were... so it
> will look like this:
>
>
> @@ -1905,24 +1916,24 @@ write()
>
>    bs.write(stream_type, 8);
>    switch (stream_type) {
> - case 0x01:
> + case 1:
>      bs.write(pid, 16);
>      break;
>
> - case 0x02:
> - case 0x04:
> + case 2:
> + case 4:
>      bs.write(subpath_id, 8);
>      bs.write(subclip_id, 8);
>      bs.write(pid, 16);
>      break;
>
> - case 0x03:
> + case 3:
>      bs.write(subpath_id, 8);
>      bs.write(pid, 16);
>      break;
>
>    default:
> - fprintf(stderr, "unrecognized stream type %02x\n", stream_type);
> + fprintf(stderr, "unrecognized mpls stream type %02x\n", stream_type);
>      break;
>    };
>    bs.padb(9 - strm.bs_posb(bs));
> @@ -1935,6 +1946,7 @@ write()
>    case BLURAY_STREAM_TYPE_VIDEO_MPEG2:
>    case BLURAY_STREAM_TYPE_VIDEO_VC1:
>
>
> ===
>
> i can make real fix patch if you wish
>
> 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).  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/90e85c9e/attachment.htm>