Adds buffer_size argument to parse

[tsitter-evertz]

We have an issue getting media info from TS files that we are stored in S3. The output is missing certain fields and/or tracks. i.e. Our tracks would not have a StreamOrder property, and sometimes the Menu track would not be returned. I believe it may be due to this open issue in MediaInfo.

As a workaround we found that increasing the buffer size in certain cases fixes the issue for the files we've been testing with, so hoping we can make this configurable.

Thanks!

[sbraz]

Hi and thanks for the PR. Would you have a small sample file that could be used to test the difference in behaviour when varying buffer sizes are used?
I'd also like to know if keeping this parameter makes sense in the long run. @JeromeMartinez, do you think there is a chance that the bug will be fixed and that this parameter will become useless in the future?

[JeromeMartinez]

there is a chance that the bug will be fixed

We have no ETA for the fix, struggling with lot of work on MediaInfo, but this issue has some kind of not so high but still high priority.

and that this parameter will become useless in the future

Fixing this issue does not make this option useless, some people use our direct API sometimes with smaller buffers e.g. 7*188 for 7 TS packets in a Ethernet frame (not the best example as it is about "file like" content, but this gives an idea of possibilities), or bigger buffers e.g. 1 MiB when they know they use only SSDs.

[JeromeMartinez]

Our tracks would not have a StreamOrder property, and sometimes the Menu track would not be returned.

@tsitter-evertz please open a ticket on https://github.com/MediaArea/MediaInfoLib/issues with a use case, I catch why there is a complete lack of detection of TS but not why StreamOrder property or menu track could be missing.

[tsitter-evertz]

@JeromeMartinez will do, I have a file that I am able to replicate this issue but we're just trying to get permission from a client to share it, or else I'll have to generate a new file that I can share.

[juanitosvq]

Fixing this issue does not make this option useless, some people use our direct API sometimes with smaller buffers

@sbraz does this mean that we could get in the change proposed in this PR? We've temporarily vendored that parse method into our application to be able to customize the buffer size, it would be great if we could go back to using the library.

[sbraz]

@juanitosvq absolutely :) I was about to merge it but I noticed that the new parameter is not at the end of the list.
@tsitter-evertz, in the (very unlikely, I know) case that some consumers use parameters by position and not by name, could you please move it after output?

[tsitter-evertz]

Good catch @sbraz, pushed that change.

[sbraz]

Thanks! I squashed your commits and committed this, I'll add Python 3.12 to the CI and create a new release soon.

[tsitter-evertz]

Hi, do we have an ETA for the next release? Thanks

[tsitter-evertz]

Our tracks would not have a StreamOrder property, and sometimes the Menu track would not be returned.

@tsitter-evertz please open a ticket on https://github.com/MediaArea/MediaInfoLib/issues with a use case, I catch why there is a complete lack of detection of TS but not why StreamOrder property or menu track could be missing.

Opened an issue here: MediaArea/MediaInfoLib#1899

[sbraz]

Hi, do we have an ETA for the next release? Thanks

I'm running the CI on this branch right now: https://github.com/sbraz/pymediainfo/tree/python312
Once it passes, I'll merge and tag as a new release.

[sbraz]

It's released as v6.1.0.