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

[oniiz86]

@ProWo I ran into a weird issue with a file duration of 04:13:05.378, I created an AVC encoded video stream from the 4K UHD file then add the original source file to the mux deselecting the HEVC video track & forgot to swap the idx numbers which I thought wouldn't be an issue as I'm simply deselecting that extra unnecessary video track, the mux was successful but when inputting it into eac3to it did not recognise the file & reported "The format of the source file could not be detected. <ERROR>" & my OPPO BDP-105D & UDP-203 players would not play the file, when you select the file on an OPPO if you wait a few seconds some metadata will populate like resolution & framerate, it should've displayed 1920 x 800 & 23.976Hz but it displayed 0 x 0 & 0.000Hz instead & refused to play but MPC-HC & VLC player had no issues with this file, what could the issue be?

I remuxed the file with MKVToolNix & now eac3to accepts the file also MediaInfo had shown no issues with this file, all metadata was present & correct.

I'm not sure if this has always been the case with FFmpeg's muxer but is there any reason when muxing DTS-HD MA & DD+ audio tracks the "Default Duration" isn't populated & the header field is empty unlike when I mux with MKVToolNix, the Default Duration for DTS-HD MA will report 10666667 & DD+ will report 32000000. The FFmpeg muxed mkv file has an empty header field, I'm only showing the DTS-HD MA selected track but DD+ track shows the same thing.


[Attachment 94025 - Click to enlarge]

Edit: I did another AVC encode & now when selecting the original source file & deselecting the HEVC video track (which is idx 1) & swapping the idx numbers for the audio tracks & subtitle tracks, the FFmpeg muxed mkv file is now recognised by eac3to & can be played in my OPPO players, not sure how that could've made any difference by simply swapping the idx numbers.

[ProWo]

@ProWo I ran into a weird issue with a file duration of 04:13:05.378

Is the video duration really 04:13:05.378?

I created an AVC encoded video stream from the 4K UHD file then add the original source file to the mux deselecting the HEVC video track & forgot to swap the idx numbers which I thought wouldn't be an issue as I'm simply deselecting that extra unnecessary video track

You're right, no need to swap the streams here.

the mux was successful but when inputting it into eac3to it did not recognise the file

Tested now. Muxed hevc video with DTS-HD MA + DD + ac3, imported in eac3to without problems.

Please post a small cut from this video here, so i can take a look.

[oniiz86]

@ProWo I ran into a weird issue with a file duration of 04:13:05.378

Is the video duration really 04:13:05.378?

I created an AVC encoded video stream from the 4K UHD file then add the original source file to the mux deselecting the HEVC video track & forgot to swap the idx numbers which I thought wouldn't be an issue as I'm simply deselecting that extra unnecessary video track

You're right, no need to swap the streams here.

the mux was successful but when inputting it into eac3to it did not recognise the file

Tested now. Muxed hevc video with DTS-HD MA + DD + ac3, imported in eac3to without problems.

Please post a small cut from this video here, so i can take a look.

@ProWo Yes, the file duration really is 04:13:05.378, it's the recent release of Kill Bill - The Whole Bloody Affair both Vol.1 & Vol.2 combined with extended sequences, total runtime is 4 hrs 13 mins. I unfortunately cannot give you a sample as I use MKVToolNix to cut a sample with the "Split by timestamps" setting & by doing so there is no longer an issue, the issue only presented itself with FFmpeg's muxer, also do you know why when muxing with FFmpeg the Default Duration header has an empty field for DTS-HD MA & EAC3 (DD+) tracks but when muxed with MKVToolNix they are populated? TrueHD & AC3 (DD) tracks are unaffected & do have their Default Duration headers with this figure "32000000" when muxed with FFmpeg, why would the other DTS-HD MA & EAC3 (DD+) formats have an empty header field?

Does your sample with DTS-HD MA & I'm assuming you meant DD+ (EAC3) above as you wrote DD + AC3 which are the same thing have Default Duration's of 10666667 & 32000000 respectively when imported into MKVToolNix's header editor?

[ProWo]

I unfortunately cannot give you a sample as I use MKVToolNix to cut a sample

Use clever instead. Load your video (muxed with clever, not with mkvtoolnix), click cut, wait for indexing, insert start and end as in the picture, click add cut mark, then click cut.


[Attachment 94026 - Click to enlarge]

Post the result here.

Does your sample with DTS-HD MA & I'm assuming you meant DD+ (EAC3) above as you wrote DD + AC3 which are the same thing have Default Duration's of 10666667 & 32000000 respectively when imported into MKVToolNix's header editor?

Yes.

BTW:
Default Duration has no meaning.

[oniiz86]

@ProWo Thanks for that, I don't know why but I was unaware of Clever's cutting feature, thanks for letting me know. I'm sorry but I accidentally deleted the problematic file that couldn't be imported into eac3to & play on my OPPO players, I can't believe I did that, I did another AVC encode of the original 4K UHD file & this time it works without issues, I don't quite understand how this happened & can no longer duplicate the issue, what was different this time around is that when the AVC encoded video track finished & I selected the purple "Multiplex" button, 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.


[Attachment 94027 - Click to enlarge]

I thought Default Duration was important for audio tracks to maintain seamless AV synchronisation & to ensure the broadest compatibility amongst hardware & software-based media players.

[ProWo]

... 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