clever FFmpeg-GUI, small FFmpeg UI, fully portable, no installation.

[Columbo]

was curious why the original FFmpeg muxed file would not play on my OPPO players when previously I had no issues

I can try to help with that too if you provide a sample. If it's MKV don't do any editing in mkvtoolnix.

[oniiz86]

was curious why the original FFmpeg muxed file would not play on my OPPO players when previously I had no issues

I can try to help with that too if you provide a sample. If it's MKV don't do any editing in mkvtoolnix.

Thanks for that, the mkv file I attached had no mkvtoolnix editing done to it but I think I've narrowed down the problem which I don't think I would've if it weren't for your detective work.

[oniiz86]

... the AVC track was the last track when it has always been the first track & then I'd add the source file but this time it appears to be reversed as you can see below, not sure if it has anything to do with the different beta versions from 3.5.9.02 to 3.5.9.03.

It was changed in 3.5.9.03.
The order now is:
source streams
preprocessed streams
new added streams

@ProWo I think I've found the problem, you remember I had said this was a recent change regarding this OPPO playback issue, well I tested it with the official v3.5.9 release & the problem is no longer present, the issue is the order change you made in v3.5.9.03 which changed the preprocessed streams order, v3.5.9 had the preprocessed streams listed first then the source file streams which is why I never encountered this issue with the OPPO players because the Track Elements are written at the start of the file as the (idx) numbers are in the correct order, the AVC video stream is always (idx 0), the current beta releases simply deselecting the unnecessary HEVC stream is not enough as the mux will proceed to mux the AVC stream as the first track but the Track Elements are written at the end of the file which is fine for most software-based media players like, MPC-HC & VLC but hardware-based players like OPPOs with their media players having a stricter compliance & require the Track Elements written at the start of the file, this troubleshooting wouldn't have been possible without the wonderful assistance of @Columbo

If I want the file to play with the current beta version of Clever which has the preprocessed AVC video stream at the end of the source file streams, I manually have to swap the (idx) numbers of the HEVC stream (idx 0) to whatever the AVC stream (idx) number is & ensure that it is (idx 0) before proceeding with the mux so the Track Elements are written at the start of the file, this is an extra unnecessary step which if possible for the next beta release if you could revert the change so the order is the same as the current official v3.5.9 release:
Preprocessed Streams
Source Streams
New Added Streams

[Columbo]

The Matroska spec (RFC 9559) does not require the video to be the first track. Track order in the Tracks element and the TrackNumber values are arbitrary, and nothing mandates that a video track come first or any specific ordering. Players are expected to identify tracks by TrackType and select defaults via FlagDefault/FlagForced and language, not by position.

However, video-first is a common convention, largely because mkvmerge orders tracks that way by default. Some older or naive players and tools assume it.

[ProWo]

@ProWo I think I've found the problem, you remember I had said this was a recent change regarding this OPPO playback issue, well I tested it with the official v3.5.9 release & the problem is no longer present

Nothing has changed in the mux command line since version 3.5.9, except for the subtitle timestamps.

the issue is the order change you made in v3.5.9.03 which changed the preprocessed streams order, v3.5.9 had the preprocessed streams listed first then the source file streams which is why I never encountered this issue with the OPPO players because the Track Elements are written at the start of the file as the (idx) numbers are in the correct order, the AVC video stream is always (idx 0), the current beta releases simply deselecting the unnecessary HEVC stream is not enough as the mux will proceed to mux the AVC stream as the first track but the Track Elements are written at the end of the file which is fine for most software-based media players like, MPC-HC & VLC but hardware-based players like OPPOs with their media players having a stricter compliance & require the Track Elements written at the start of the file, this troubleshooting wouldn't have been possible without the wonderful assistance of @Columbo

You're getting something mixed up here.
The order in which the streams are written to the data grid has nothing to do with how they are then muxed.
For example, if the video stream is displayed at idx10 in the grid, it is still listed as first stream during muxing.

If I want the file to play with the current beta version of Clever which has the preprocessed AVC video stream at the end of the source file streams, I manually have to swap the (idx) numbers of the HEVC stream (idx 0) to whatever the AVC stream (idx) number is & ensure that it is (idx 0) before proceeding with the mux so the Track Elements are written at the start of the file, this is an extra unnecessary step which if possible for the next beta release if you could revert the change so the order is the same as the current official v3.5.9 release:

This is nonsense.

[oniiz86]

@ProWo I think I've found the problem, you remember I had said this was a recent change regarding this OPPO playback issue, well I tested it with the official v3.5.9 release & the problem is no longer present

Nothing has changed in the mux command line since version 3.5.9, except for the subtitle timestamps.

You're getting something mixed up here.
The order in which the streams are written to the data grid has nothing to do with how they are then muxed.
For example, if the video stream is displayed at idx10 in the grid, it is still listed as first stream during muxing.

I understand that I can see my preprocessed stream as the first during muxing, it still poses a problem for my OPPO players unless I swap (idx) numbers & make the preprocessed video stream idx0 just before I press the mux button.

If I want the file to play with the current beta version of Clever which has the preprocessed AVC video stream at the end of the source file streams, I manually have to swap the (idx) numbers of the HEVC stream (idx 0) to whatever the AVC stream (idx) number is & ensure that it is (idx 0) before proceeding with the mux so the Track Elements are written at the start of the file, this is an extra unnecessary step which if possible for the next beta release if you could revert the change so the order is the same as the current official v3.5.9 release:

This is nonsense.

@ProWo You may think it's nonsense but that is what I'm witnessing, how can you explain it working on v3.5.9 but not on beta v3.5.9.03/04, do you have an OPPO player to test for this? I know @Columbo said above that how the Track Elements are written at the start or end of the file aren't important but it's the only thing I can go on at this point, I have to manually swap the (idx) numbers for the preprocessed AVC stream & source HEVC stream before I mux using the latest beta to obtain a playable file for my OPPO players.

Edit: I forgot to mention there are a couple of typos on the "Set your FFmpeg bin folder" screen, the word "unterface" should be corrected to interface, "requiers" to requires & dont is missing an apostrophe.


[Attachment 94070 - Click to enlarge]

[ProWo]

...I have to manually swap the (idx) numbers for the preprocessed AVC stream & source HEVC stream before I mux using the latest beta to obtain a playable file for my OPPO players.

This swap is useless and doesnt change the mux order.
You can test this by yourself.
In the clever FFmpeg-GUI program folder you find a portable.config file.
Open it with a text editor, find the row
<cmd_l>0</cmd_l>
and change 0 to 1.
Save the file and start clever.
Do your multiplexing thing without swapping anything and click multiplex.
You can see the whole multiplex commandline now.
Click copy and insert the copied content in a textfile.
Then click stop to stop the muxing.

Repeat the operation with swapping the index numbers.
Click multiplex, copy, insert the copied content in the same textfile as before.
Click stop to stop the muxing.

Now compare the two mux commandlines.

[ProWo]

I forgot to mention there are a couple of typos on the "Set your FFmpeg bin folder" screen, the word "unterface" should be corrected to interface, "requiers" to requires & dont is missing an apostrophe.

Thx for the hint, will be fixed.

[AlanFord54]

Is it possible enabling the GUI to open directly file .iso

Will add this.

Thanks a lot.

[ProWo]

Is it possible enabling the GUI to open directly file .iso

Will add this.

Thanks a lot.

Done. Update please to 3.5.9.05. Test it.
Info:
Select or drag the iso. You get a message if is sucessfully mounted.
Then select your m2ts file for further processing.
Closing clever, the mounted ISO is automatically dismounted.

[mannequin80]

getting this error opening a random .mkv:


[Attachment 94071 - Click to enlarge]

[ProWo]

getting this error opening a random .mkv

Just tested it: No problem here on my end.
Rename the portable.config file in the program folder to _portable.config
Then restart and configure the app and retry to load a mkv.

[mannequin80]

Just tested it: No problem here on my end.

i looked closer at that error since it was happening with just that particular file and it looks like the GUI crashes in "Find_interlaced" when the .mkv has no clear scan-type / field-order information (or it is marked “unknown”) or perhaps something was off in that file in those fields/header. by re-writing them through the Header editor the file can be opened by clever with no issues.

[ProWo]

i looked closer at that error since it was happening with just that particular file and it looks like the GUI crashes in "Find_interlaced" when the .mkv has no clear scan-type / field-order information (or it is marked “unknown”) or perhaps something was off in that file in those fields/header. by re-writing them through the Header editor the file can be opened by clever with no issues.

If you have this problematic, uncorrected MKV file, please post it here. I'd like to take a closer look at it.

[Columbo]

Yeah, #metoo

[mannequin80]

If you have this problematic, uncorrected MKV file, please post it here. I'd like to take a closer look at it.

unfortunately, already got rid of it. it was something very niche anyway (probably with broken scan-type / field-order information).

[Columbo]

Doesn't make much sense to report a problem and then delete the source file!

[oniiz86]

...I have to manually swap the (idx) numbers for the preprocessed AVC stream & source HEVC stream before I mux using the latest beta to obtain a playable file for my OPPO players.

This swap is useless and doesnt change the mux order.
You can test this by yourself.
In the clever FFmpeg-GUI program folder you find a portable.config file.
Open it with a text editor, find the row
<cmd_l>0</cmd_l>
and change 0 to 1.
Save the file and start clever.
Do your multiplexing thing without swapping anything and click multiplex.
You can see the whole multiplex commandline now.
Click copy and insert the copied content in a textfile.
Then click stop to stop the muxing.

Repeat the operation with swapping the index numbers.
Click multiplex, copy, insert the copied content in the same textfile as before.
Click stop to stop the muxing.

Now compare the two mux commandlines.

@ProWo I just tested this now & you're right the two mux commandlines are identical, I tried this again using the latest beta 3.5.9.05 & left the Preprocessed AVC stream at (idx39) & deselected the source HEVC stream (idx0) & the mux can be imported in eac3to v4.01 without issue, I thought I was going to experience an issue as the fix is implemented in eac3to v4.02, was very surprising indeed. I was curious though, what prompted the mux grid order change in v3.5.9.03 when after a preprocessed stream is complete & then you click the Purple Multiplex button, the preprocessed stream ends up at the end of the source streams?

Thanks for the typo fixes but it appears that you inadvertently introduced another typo "versio" the "n" got removed should be version.


[Attachment 94076 - Click to enlarge]

[ProWo]

... I was curious though, what prompted the mux grid order change in v3.5.9.03 when after a preprocessed stream is complete & then you click the Purple Multiplex button, the preprocessed stream ends up at the end of the source streams?

The reason was a code optimization. This prevented the source video from being analyzed again unnecessarily.

[oniiz86]

Thank you for reporting this and for the sample file. It was worth
raising, because it turned up a limitation eac3to has had from the
start.

The file is a valid MKV, but its Tracks element (the list of tracks
and their codec settings) sits at the very end of the file, after all
the audio and video data. The Matroska specification allows that, as
long as the directory at the front of the file (the SeekHead) points
to it. Every eac3to version so far reads an MKV from front to back and
expects the track list before the first data, so it found no tracks
and reported that the format could not be detected.

The file most likely got that way in two steps. It was muxed by
FFmpeg, which writes the track list near the start with no spare room
after it. Afterwards its track properties were edited with MKVToolNix
(mkvpropedit or the header editor in the GUI), and the edit made the
track list slightly bigger. When an edited element no longer fits in
its old place, MKVToolNix blanks the old spot and writes the element
at the end of the file instead. The track list now carries language
entries in a newer format that MKVToolNix writes and FFmpeg does not,
which points to the edit rather than to FFmpeg itself.

eac3to 4.02 test handles this layout and reads such files normally.
Remuxing the file with mkvmerge also works with any eac3to version,
because mkvmerge puts the track list back at the front.

@ProWo I'd just like to apologise for wasting your time these past few days, I actually had forgotten that I did indeed edit the Default Duration values with MKVToolNix's header editor with the FFmpeg muxed files which @Columbo had alluded to in the above post, I feel bad wasting his time too on this & that is the cause of failure to play on my OPPO players, I can't believe they would refuse to play, it must be those MediaTek SoC chipsets with their quirky behaviour, as MPC-HC & VLC had no such issues with playback.

[Columbo]

I knew it.

[oniiz86]

@Columbo Yes, very much my mistake, you said that the file is legal but most unusual, what seems trivial for most software players like MPC-HC & VLC, a file like this is flat out rejected by hardware players like my OPPOs with a "File Format is not supported" message, is there a particular reason why you think that the OPPO engineers or MediaTek chipset designers overlooked something like this?

[Columbo]

They probably didn't know about mkvtoolnix and the side effect of header editing. I think most developers are thrilled to get something working at all and don't spend a lot of time rummaging through the small print of the specs. With software at least one can make fairly quick releases in response to trouble reports. But firmware...not!

For anyone that doesn't know oniiz86, we call him the "big o" over in DG land. He's a major contributor to eac3to development.

Speaking of which, eac3to for linux hits the streets tomorrow.

[oniiz86]

@ProWo I've come across an issue with clever not opening an mkv file much like @mannequin80 above, this file opens okay in mkvtoolnix, tsMuxer & eac3to. I'm sorry but it's a very large file 64.2 GB, here is the link https://gofile.io/d/0cE36A5w I tried renaming the portable.config file to _portable.config as you had suggested above but it made no difference & still refuses to open in clever.


[Attachment 94102 - Click to enlarge]

In case you missed it above the "Set your FFmpeg bin folder" screen has another typo that wasn't there previously but introduced in v3.5.9.05, the word "versio" is missing the "n" should be corrected to "version".


[Attachment 94103 - Click to enlarge]

[ProWo]

@ProWo I've come across an issue with clever not opening an mkv file much like @mannequin80 above, this file opens okay in mkvtoolnix, tsMuxer & eac3to. I'm sorry but it's a very large file 64.2 GB

You have PM.