Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

audio track with delay +21000 " not recognized and ignored" #329

Closed
darekpro opened this issue Sep 1, 2020 · 8 comments
Closed

audio track with delay +21000 " not recognized and ignored" #329

darekpro opened this issue Sep 1, 2020 · 8 comments
Labels
bug Something isn't working

Comments

@darekpro
Copy link

darekpro commented Sep 1, 2020

Hello,

When I want create new blu-ray folder and I adding new audio track with delay +21000 after creating folder the same folder can not be open again in tsmuxer.

BDMV sample
https://drive.google.com/file/d/1ahX4_jtOihYTAyVKXj2hmAGg7jKRfVEx/view?usp=sharing

Zrzut ekranu z 2020-09-01 11-32-39

@jcdr428
Copy link
Collaborator

jcdr428 commented Sep 1, 2020

@darekpro you need to grant access to your drive link.

@darekpro
Copy link
Author

darekpro commented Sep 1, 2020

Upsss sorry :) done

@jcdr428
Copy link
Collaborator

jcdr428 commented Sep 1, 2020

tsMuxer scans the beginning of the m2ts to analyze the tracks. The size of the analyzed chunk is DETECT_STREAM_BUFFER_SIZE = 16 MB (line 42 of vod_common.h). With your delay of 21 ms, the AC3 track starts after this 16 MB chunk, so is not detected.

One solution would be to increase the buffer size, with the detrimental effect of increasing memory need / time needed to scan. An audio starting 21 sec. after video being quite uncommon, in such situation it would be preferable to append a 21 sec. "silence" AC3 before your AC3 track.

Edit: on the other side, tsMuxer was originally written for HD and not UHD, so maybe it would be logical to increase the detect buffer to 64 MB. @xavery @justdan96, any thought on the inconvenient of doing so ?

@darekpro
Copy link
Author

darekpro commented Sep 1, 2020

"in such situation it would be preferable to append a 21 sec. "silence" AC3 before your AC3 track."
True but not with DTS-MA, TRUEHD itd :P

@jcdr428
Copy link
Collaborator

jcdr428 commented Sep 1, 2020

@darekpro True... I'll propose the one-line patch to increase buffer to 64 MB, let's see what @xavery thinks about this.

jcdr428 added a commit to jcdr428/tsMuxer that referenced this issue Sep 1, 2020
See issue justdan96#329 : when a track starts after the first 16 MB in the m2ts, it is not detected.
It is therefore proposed to increase the detect buffer (i.e. size of scanned chunk) to 64 MB.
xavery pushed a commit that referenced this issue Sep 1, 2020
See issue #329 : when a track starts after the first 16 MB in the m2ts, it is not detected.
It is therefore proposed to increase the detect buffer (i.e. size of scanned chunk) to 64 MB.
@xavery
Copy link
Contributor

xavery commented Sep 1, 2020

@darekpro True... I'll propose the one-line patch to increase buffer to 64 MB, let's see what @xavery thinks about this.

Sounds okay, the whole algorithm should start with a small-ish value and gradually work its way up to larger ones anyway. However, since we have no real performance/memory usage targets, and no real way to compare them across changes or versions, simply increasing the buffer size here is the natural way to go.

@jcdr428
Copy link
Collaborator

jcdr428 commented Sep 2, 2020

Thanks @xavery.
@darekpro could you please test latest bintray nightly, and close the issue if your problem is fixed.

@darekpro
Copy link
Author

darekpro commented Sep 2, 2020

Perfect now everything it is ok. Thank you.

@xavery xavery closed this as completed Sep 2, 2020
@jcdr428 jcdr428 added the bug Something isn't working label Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants