FFmpegSource2 !

[ToiletDuck]

mkv is usually easier to open for filters like FFVideosource2 and LWLibAVSource.
So my suggestion for remuxing to mkv beforehand mainly aimed for the preview issues.

For muxing m2ts, Hybrid can either use tsMuxeR or ffmpeg, so you could also try whether it works better if you use ffmpeg as muxer.

Mkv or m2ts.. it doesn't matter.. it takes proximately the same time to summon filter preview... It only takes longer with LWlibavsource, and whit lwlibav the index file NEEDS to be created from bottom up, every single time i re-open filter preview !!  

Using ffmpegsource2 however, it only needs to create/prepare that index file just ONCE for a filter preview !?!  Even though i close preview, and re-open to check result after i change any filter settings, it doesn't need to recreate / prepare for it time and time again !?  You know why that is ?

It's an 2 egde sword, like i have mentioned before ffmpegsource2 affects output files in a very bad "playback" way !!!
But affects only Low resolution content, not 1080p or 2160p (4k) !!?!

Ps.: m2ts is a mess (trying to calculate the overhead this container creates, before muxing, is just crazy) and in my opinion should never have been used for media files and only for streaming content,...

 
↑ that's one of the main reasons i like to use ts output, to automatically calculate overhead.. 
Even though i know what the overhead is out of my head by now (a few megabytes more or less  ), depending on the Audio (AC3, THD+ac3 ←)  aswell from the source..  


cheers,
TD

[Selur]

For me FFVideoSource works fine for 2k, 4k, 8k content, like mentioned before, enabling hardware decoding might help.
LWlibavsource needs to create the index file, since it only creates the index file inside the RAM.
Hybrid does not support cache=false for LWlibavsource, since it will try to create the cache file next to the source.
iirc there was a tool named aui_indexer which was able to create the lwi index files and one could load those files as source in LWlibavsource, but there were some issues with it and I haven't seen a .exe build of it for ages,...
(personally, I usually use DGDecNV for m2ts content,..)

↑ that's one of the main reasons i like to use ts output, to automatically calculate overhead..

create a 2hr movie with low bit rate and look at the overhead,...
I doubt you can 'guess' the overhead correctly +/- a few mb,...

Cu Selur

Ps.: Last version of aui_indexer seem to be from 2017: https://onedrive.live.com/?authkey=%21AN...75AC8933C6

[ToiletDuck]

For me FFVideoSource works fine for 2k, 4k, 8k content, like mentioned before, enabling hardware decoding might help.
LWlibavsource needs to create the index file, since it only creates the index file inside the RAM.
Hybrid does not support cache=false for LWlibavsource, since it will try to create the cache file next to the source.
iirc there was a tool named aui_indexer  which was able to create the lwi index files and one could load those files as source in LWlibavsource, but there were some issues with it and I haven't seen a .exe build of it for ages,...
(personally, I usually use DGDecNV for m2ts content,..)

so , do i read this ↑ right.. Only LWlibavsource creates index files, not ffmpegsource2 ?  I ask, because awhile ago you wrote that there alway's need to be index file created for filter preview.  So i thought, in any situation regardless of wich setting...

↑ that's one of the main reasons i like to use ts output, to automatically calculate overhead..

create a 2hr movie with low bit rate and look at the overhead,...
I doubt you can 'guess' the overhead correctly +/-  a few mb,...
Cu Selur
Ps.: Last version of aui_indexer seem to be from 2017: https://onedrive.live.com/?authkey=%21AN...75AC8933C6

i know, the difference in filesize between .mkv, mp4 etc and TS file is how you know too..  Again, depends how large the video & AUDIO track is aswell  !!

Like for an audio track of 7-8 GB, overhead is like 3 GB for crying out loud when you remux to a *.ts file..  
Overhead is much less when the audio track is like 3 - 4 GB naturaly... 

That's what i have found out..

so yes, once you know the filesize of the tracks (demuxed) you can pretty much guess the final filesize of an TS file ..  (give or take ... a few hundred MB's   )



cheers,
TD

[Selur]

Only LWlibavsource creates index files, not ffmpegsource2 ?

No, both create index files, LWlibavsource creates temporal onces in RAM and for LWlibavsource (and DGDecNV) they can be created with separate tools inside the tmp-folder.

give or take ... a few hundred MB's

or 'a few megabytes more or less' are totally different things

[ToiletDuck]

Only LWlibavsource creates index files, not ffmpegsource2 ?

No, both create index files, LWlibavsource creates temporal onces in RAM and for LWlibavsource (and DGDecNV) they can be created with separate tools inside the tmp-folder.

I thought ffmpegsource2 used the ram !!  Again, ffmpegsource2 is MUcH faster compared to lwlibav..!?

give or take ... a few hundred MB's

or 'a few megabytes more or less' are totally different things 

True.. 

I meant to say that my predictions (out of my head) were as good if not better than hybrid's estimates, in some cases ... 

Even an tool/app misses the mark by hundreds of megabytes in predicting the final file size of a ts file   in my experience !!


cheers,
td

[Selur]

Problem is, that at least I, after reader the specifications of transport streams, h.264, h.264, dts, ac3, etc. am not really confident in the file predictions.
An especially low bit rate encodes can have X00%+ overhead.
(for mkv&co size prediction should be nearly exact.)

FFMS => index in file system and is bad with vc-1 and mpeg-2
LW => index in RAM, but it's bad with transportstreams and mpeg-2
DGDecNV (requires NVIDIA card)=> index in file system, but can only handle stuff the GPU can decode (next to DGDecode it's the best for anything mpeg-2 based and transportstreams)

Cu Selur

[ToiletDuck]

Problem is, that at least I, after reader the specifications of transport streams, h.264, h.264, dts, ac3, etc. am not really confident in the file predictions.
An especially low bit rate encodes can have X00%+ overhead.
(for mkv&co size prediction should be nearly exact.)

FFMS  => index in file system and is bad with vc-1 and mpeg-2
LW => index in RAM, but it's bad with transportstreams and mpeg-2
DGDecNV (requires NVIDIA card)=> index in file system, but can only handle stuff the GPU can decode (next to DGDecode it's the best for anything mpeg-2 based and transportstreams)

Cu Selur

Actually, i wos talking about the difference in filesize because of the different format/container that is used.. 
Not so much about predictions in terms of Low/high bitrate compression   .

But thanks anyway,

cheers,
td

[Selur]

MKV has the lowest container overhead between mkv, mp4, m2ts.
(M2)ts has the worst container overhead.

[ToiletDuck]

MKV has the lowest container overhead between mkv, mp4, m2ts.
(M2)ts has the worst container overhead.

True, tell me about it   .. !