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@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@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@gmail.com> wrote:
On Sunday, April 17, 2022, Phyllis Smith <phylsmith2017@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...