auto-append needed for sequential files - options?

Started by kstathem, March 11, 2019, 10:50:00 AM

Previous topic - Next topic

kstathem

In reference to my post 3 years ago at https://avidemux.org/smif/index.php/topic,16611.msg73837.html#msg73837, I am not able to open these files properly in 2.7.1 or 2.7.2 as explained in https://avidemux.org/smif/index.php/topic,18376.msg84320.html.
These files do not conform to a convenient filesize, so the latest trick (https://github.com/mean00/avidemux2/commit/598a96bb4ffa446cfc03bec31c770ffd612f5a92) completely breaks them. I would upload (portions of) the files in question, but it would be about 560KB, well above the size limit.
I realize this is an edge case, and I can use (in bash) head --bytes=-47K *.ts > /tmp/file.ts; avidemux /tmp/file.ts as a workaround, but for those who, for various reasons, are certain that they are working with fragments of a single stream, would it be possible to put an option in preferences to restore the original behavior? Or even allow for user-defined filetypes as an advanced feature?

eumagga0x2a

Quote from: kstathem on March 11, 2019, 10:50:00 AM
In reference to my post 3 years ago at https://avidemux.org/smif/index.php/topic,16611.msg73837.html#msg73837, I am not able to open these files properly in 2.7.1 or 2.7.2 as explained in https://avidemux.org/smif/index.php/topic,18376.msg84320.html.
These files do not conform to a convenient filesize, so the latest trick (https://github.com/mean00/avidemux2/commit/598a96bb4ffa446cfc03bec31c770ffd612f5a92) completely breaks them.

Fortunately, that buggy commit was not the latest trick, later commits fixed sizes and lowered the threshold down to 256 MiB.

Regarding the particular issue with your receiver, I don't see any possibility to workaround it in Avidemux for being able to use multiloading. What the receiver is doing is just crazily broken, it is hopeless to chase each device doing strange things.

However, you should get the prompt to load all consecutively named fragments if the fragments are 1 GiB +/- 1 MiB in size as you stated. Do you get this prompt? Please be aware that you must delete *.idx2 files first to trigger reindexing.

Quotewould it be possible to put an option in preferences to restore the original behavior?

The original behavior wouldn't help here.

QuoteOr even allow for user-defined filetypes as an advanced feature?

This is pointless as only MPEG TS (and MPEG PS in case of DVD streams) can be split in fragments and still work. MPEG TS was developed explicitely with this option in mind.

kstathem

Quoteyou should get the prompt to load all consecutively named fragments if the fragments are 1 GiB +/- 1 MiB in size as you stated.

I actually stated the fragments are NOT any such convenient filesize; the first fragment in the my tests yesterday was about 1.3 GiB

QuoteDo you get this prompt? Please be aware that you must delete *.idx2 files first to trigger reindexing.

I found one fragment that was by chance about 1 GiB, I got the prompt with that one and it worked fine. Otherwise, I deleted the .idx2 file many times, testing various ways of opening the file, versions of avidemux, etc. Version 2.6.20 works fine, 2.7.* will open it fine if the .idx2 file was created with 2.6.20, but 2.7.* will not give me the prompt except on the one that happens to be the right size.

QuoteThe original behavior wouldn't help here.

2.6.12 through 2.6.20 open these files alright, so I don't get that

Quoteit is hopeless to chase each device doing strange things.

I entirely agree, which is why I suggested user-defined filetypes - probably actually subtypes

anyway, if I sound a bit hostile I apologize; I'm about at the point of abandoning avidemux in favor of an ffmpeg script. It's messier, but much less likely to break at random (since I'm only chasing two or three devices doing strange things)

eumagga0x2a

Quote from: kstathem on March 12, 2019, 03:37:27 AM
Quoteyou should get the prompt to load all consecutively named fragments if the fragments are 1 GiB +/- 1 MiB in size as you stated.

I actually stated the fragments are NOT any such convenient filesize;

I refered to

QuoteMy satellite receiver (Geosatpro HD) splits its files at ~1GB. When I try to mux two or more sequential files, I get the too short error and the output file ends at the split.
I investigated with a hex editor and discovered that each file repeats the last 47KiB (exactly) of the previous file.

from https://avidemux.org/smif/index.php/topic,16611.msg73837.html#msg73837. Does the behavior with repeated part of the stream persist? Theoretically, this part may consist of filler NALUs, cut exactly at TS packet boundaries and thus be valid (because automatically skipped), but difficult to tell without seeing the actual data.

Quotethe first fragment in the my tests yesterday was about 1.3 GiB

Okay, I see, no luck with that. The fragment size is a weak evidence, sure, but it holds in the vast majority of use cases. The rare exceptions have two options with Avidemux: concatenate the stream fragments with cat (or an equivalent tool when on Windows) and completely disable autosplit in the receiver.

Quote
QuoteDo you get this prompt? Please be aware that you must delete *.idx2 files first to trigger reindexing.

I found one fragment that was by chance about 1 GiB, I got the prompt with that one and it worked fine. Otherwise, I deleted the .idx2 file many times, testing various ways of opening the file, versions of avidemux, etc. Version 2.6.20 works fine, 2.7.* will open it fine if the .idx2 file was created with 2.6.20, but 2.7.* will not give me the prompt except on the one that happens to be the right size.

Obviously, the mentioned prompt, triggered only if an index doesn't exist yet, is linked to fragment size matching the (256 * 2^n) MiB + the rest pattern.

Quote
QuoteThe original behavior wouldn't help here.

2.6.12 through 2.6.20 open these files alright, so I don't get that

You mentioned 47 KiB of the previous fragment being repeated at the start of the next one. Unless the assumption outlined above holds, this can't result in a valid stream when concatenated.

Quote
Quoteit is hopeless to chase each device doing strange things.

I entirely agree, which is why I suggested user-defined filetypes - probably actually subtypes

If you thought of file types as special file name extensions, Avidemux doesn't care about file name extensions when probing, except of .vpy which is treated as a VapourSynth script as long as no other demuxer gets interested.

Quoteanyway, if I sound a bit hostile I apologize;

Absolutely not needed, everything was fine.

QuoteI'm about at the point of abandoning avidemux in favor of an ffmpeg script. It's messier, but much less likely to break at random (since I'm only chasing two or three devices doing strange things)

No problem with that.