Audio Format NOT supported !

[ToiletDuck]

This i realy something   else..

today, i've tried to play some media files from an usb stick on my LG FUlLHD 3D smart TV.

The media file contains 1 e-ac3 audio track that the LG doesn't seems to support..
Yet, an EAC3 (Dolby Digital Plus 7.1) sample i have download plays just perfect on my tv?

But it refuses to playback a 5.1/2.0 e-ac3 track !?!

But, the eac3 track from the media files does playback just fine in other strict players such as my BD player and PDVD..
What does that even mean 


so, the E-AC3 audio codec is an non-stop recuring problem when iam using that format for my media files for some mysterious reason !
I then did an EAC3 to DTS format transcode, and voila.. My TV does NOT HAVE ONE slightest problem to playback the fresh created DTS track   

EAC3 keeps haunting this poor duck !!




Cheerios
TD °^°

---

UPDATE : Found the Cullprit ↓

So, just found out that the eac3 audio from my untouched media file does play perfect on my TV.. 

But ONCE i remux it using hybrid using PASSTHROUGH, the TV complains about unsupported format again !!!

That ↑ indicates, that the mux process affects the untouched EAC3 tracks in a BAD WAY   

This means, the compatibility of all audio tracks from the new created media files through hybrid are RUINED to some degree  .. 0_0 !
Just GREAT .. SPLENDID


UPDATE 2:  

It seems, TSmux gui is the CULLPRIT !!  Original source file played just fine, UNTILL i remux it through TSmux and tried to playback that file from usb on my HDTV !!

Great, another (and not MINOR) issue with nightly builds .... 

[Selur]

In case you remux to mkv, the problem might be due to the removal of the ac3 part.

[ToiletDuck]

In case you remux to mkv, the problem might be due to the removal of the ac3 part.

Interesting part of all this selur izz..

As you very well know, in the past i fixed / worked arround audio eac3 problems by converting m2ts back into mkv, do you remember?

But now it's different..

Once i have used tsmux to create Ts files from the source, and change those back to *.mkv, → the quickest way in a ATTEMPT to fix audio playback / compatibility issues..  The result is the same = NO AUDIO !!  

Same thing happends using FFmpeg 6 !!!

So, i have to recode all audio tracks into other formats to FIX this now !!!

And iam not to happy about that 

[Selur]

Ts files from the source,

I hope you tried .m2ts not .ts, since some players will not support eac3+ac3 in ts.
(spec allows it, but some hardware players don't support it)

Once i have used tsmux to create Ts files from the source, and change those back to *.mkv,

Yes, this would remove the ac3 part of 'eac3+ac3'-streams.
this seems wrong combined with:

The media file contains 1 e-ac3 audio track that the LG doesn't seems to support..
Yet, an EAC3 (Dolby Digital Plus 7.1) sample i have download plays just perfect on my tv?

=> look at your files with mediainfo in regard to what audio streams are supported.


Cu Selur

[ToiletDuck]

Ts files from the source,

I hope you tried .m2ts not .ts, since some players will not support eac3+ac3 in ts.
(spec allows it, but some hardware players don't support it)

yeah.. i should have know you assumed as much..   
NO, i alway's use M2TS .. but i shortened to ts for all intents and purposes >_> ..

 

Once i have used tsmux to create Ts files from the source, and change those back to *.mkv,

Yes, this would remove the ac3 part of 'eac3+ac3'-streams.
this seems wrong combined with:

The media file contains 1 e-ac3 audio track that the LG doesn't seems to support..
Yet, an EAC3 (Dolby Digital Plus 7.1) sample i have download plays just perfect on my tv?

=> look at your files with mediainfo in regard to what audio streams are supported.
Cu Selur

Well yes, did ts2mkv from media files containing Truehd atmos tracks, to circumvent the crashes in hybrid.
But my current problem is from an whole other branch now..

And no, iam talking about the very same sample with the very same eac 7.1 track that works just FINE when it's played as is = untouched.  
so, it's not so much an Audio format issue, since my tele supports the format CLEARLY ↑

But once i remux it (testing purpose) with tsmux , bam → suddenly the audio format isn't supporte ... AS IF .. like WHAT EVER

[Selur]

Maybe time would be better spend on finding out whether extraction with ffmpeg could be speedup, since iirc. muxing the output of ffmpeg worked fine, right?

[Selur]

Maybe it would be better to try to figure out why ffmpeg is slower than ffmpeg.

Remuxing "Caras de la noticia ep1.ts"

ffmpeg started...
starting 2023-11-20@14_52_26_9710_01_audio@14:53:04.632 - G:\Output\Caras de la noticia ep1.mkv
"F:\Hybrid\64bit\ffmpeg.exe" -y -threads 8 -analyzeduration 200M -probesize 200M -i "G:\clips\ts_remux_test\Caras de la noticia ep1.ts" -r 25/1 -sn -vcodec copy -map_metadata -1 -metadata encoding_tool="Hybrid 2023.11.19.1" -bsf:v h264_mp4toannexb -f h264 "J:\tmp\Caras de la noticia ep1_1_2023-11-20@14_52_26_9710_05.264" -map 0:4 -y -acodec copy -map_metadata -1 "J:\tmp\iId_4_aid_485_2023-11-20@14_52_26_9710_04.eac3" -map 0:1 -y -acodec copy -map_metadata -1 "J:\tmp\iId_3_aid_484_2023-11-20@14_52_26_9710_03.eac3" -map 0:3 -y -acodec copy -map_metadata -1 "J:\tmp\iId_2_aid_483_2023-11-20@14_52_26_9710_02.mp2" -map 0:2 -y -acodec copy -map_metadata -1 "J:\tmp\iId_1_aid_482_2023-11-20@14_52_26_9710_01.mp2"
2023-11-20@14_52_26_9710_01_audio finished after 00:00:12.508
finished...

vs.

"F:\Hybrid\64bit\tsMuxeR.exe" "J:\tmp\tsmuxer_2023-11-20@14_52_48_2410_01_0.meta" "J:\tmp"
2023-11-20@14_52_48_2410_02_audio finished after 00:00:03.482
finished...

with:

MUXOPT --no-hdmv-descriptors --new-audio-pes --demux --vbr --vbv-len=500
A_MP3, "G:\clips\ts_remux_test\Caras de la noticia ep1.ts", track=482
A_MP3, "G:\clips\ts_remux_test\Caras de la noticia ep1.ts", track=483
A_AC3, "G:\clips\ts_remux_test\Caras de la noticia ep1.ts", track=484
A_AC3, "G:\clips\ts_remux_test\Caras de la noticia ep1.ts", track=485
V_MPEG4/ISO/AVC, "G:\clips\ts_remux_test\Caras de la noticia ep1.ts"

=> I suspect the thing that is slowing ffmpeg down is the bitstream filter
https://ffmpeg.org/ffmpeg-bitstream-filt...p4toannexb
(nowadays, that filter should even be added automatically: "Please note that this filter is auto-inserted for MPEG-TS (muxer mpegts) and raw H.264 (muxer h264) output formats. ")

Removing that from the call does not make a difference:

ffmpeg started...
starting 2023-11-20@15_02_52_1210_01_audio@15:03:15.593 - G:\Output\Caras de la noticia ep1_new.mkv
"F:\Hybrid\64bit\ffmpeg.exe" -y -threads 8 -analyzeduration 200M -probesize 200M -i "G:\clips\ts_remux_test\Caras de la noticia ep1.ts" -r 25/1 -sn -vcodec copy -map_metadata -1 -metadata encoding_tool="Hybrid 2023.11.19.1" "J:\tmp\Caras de la noticia ep1_new_1_2023-11-20@15_02_52_1210_05.264" -map 0:4 -y -acodec copy -map_metadata -1 "J:\tmp\iId_4_aid_485_2023-11-20@15_02_52_1210_04.eac3" -map 0:1 -y -acodec copy -map_metadata -1 "J:\tmp\iId_3_aid_484_2023-11-20@15_02_52_1210_03.eac3" -map 0:3 -y -acodec copy -map_metadata -1 "J:\tmp\iId_2_aid_483_2023-11-20@15_02_52_1210_02.mp2" -map 0:2 -y -acodec copy -map_metadata -1 "J:\tmp\iId_1_aid_482_2023-11-20@15_02_52_1210_01.mp2"
2023-11-20@15_02_52_1210_01_audio finished after 00:00:11.608
finished...

Neither does changing the thread count "-threads X" or removing the analysis/probe size "-analyzeduration 200M -probesize 200M".

adding "-vn -sn" to the audio extraction parts:

ffmpeg started...
starting 2023-11-20@15_27_30_2210_01_audio@15:27:37.184 - G:\Output\Caras de la noticia ep1.mkv
"F:\Hybrid\64bit\ffmpeg.exe" -y -threads 8 -analyzeduration 200M -probesize 200M -i "G:\clips\ts_remux_test\Caras de la noticia ep1.ts" -r 25/1 -an -sn -vcodec copy -map_metadata -1 -metadata encoding_tool="Hybrid 2023.11.19.1" -bsf:v h264_mp4toannexb -f h264 "J:\tmp\Caras de la noticia ep1_1_2023-11-20@15_27_30_2210_05.264" -map 0:4 -y -sn -vn -acodec copy -map_metadata -1 "J:\tmp\iId_4_aid_485_2023-11-20@15_27_30_2210_04.eac3" -map 0:1 -y -sn -vn -acodec copy -map_metadata -1 "J:\tmp\iId_3_aid_484_2023-11-20@15_27_30_2210_03.eac3" -map 0:3 -y -sn -vn -acodec copy -map_metadata -1 "J:\tmp\iId_2_aid_483_2023-11-20@15_27_30_2210_02.mp2" -map 0:2 -y -sn -vn -acodec copy -map_metadata -1 "J:\tmp\iId_1_aid_482_2023-11-20@15_27_30_2210_01.mp2"
2023-11-20@15_27_30_2210_01_audio finished after 00:00:08.621
finished...

does speed it up somewhat.

=> no clue why ffmpeg is so much slower than tsMuxeR

Cu Selur

[ToiletDuck]

Maybe time would be better spend on finding out whether extraction with ffmpeg could be speedup, since iirc. muxing the output of ffmpeg worked fine, right?

Yeah, you probebly right 

Come to think of it.. The Tele is dated from 2013 (unlucky number   ) !

So, you have noticed too that ffmpeg is way slower than tsmuxer ehh   .. Not only that , but just found out that the developer of FFmpeg excluded the use of Subrip subtitles from the mux process  !?  

Yep, no more text based subtitles are supported .. Another fine mess to deal with 

[Selur]

Not only that , but just found out that the developer of FFmpeg excluded the use of Subrip subtitles from the mux process Huh !?

a. m2ts doesn't support idx/sub subtitle, so those would need to be converted to pgs (for example using BDSub2Sup++); tsMuxeR also doesn't support idx/sub muxing.
b. I don't think I ever implemented muxing subtitles with ffmpeg, but muxing pgs subtitles into m2ts should be possible with ffmpeg in theory.

So, you have noticed too that ffmpeg is way slower than tsmuxer ehh

I didn't question that.

Cu Selur
Ps.: I also never implemented a way to convert sup to idx subtitle. (never needed it)

[ToiletDuck]

Not only that , but just found out that the developer of FFmpeg excluded the use of Subrip subtitles from the mux process  Huh !? 

a. m2ts doesn't support idx/sub subtitle, so those would need to be converted to pgs (for example using BDSub2Sup++); tsMuxeR also doesn't support idx/sub muxing.
b. I don't think I ever implemented muxing subtitles with ffmpeg, but muxing pgs subtitles into m2ts should be possible with ffmpeg in theory.

So, you have noticed too that ffmpeg is way slower than tsmuxer ehh

I didn't question that.

Cu Selur
Ps.: I also never implemented a way to convert sup to idx subtitle. (never needed it)

Selur .. Selur ... SIR Selur   ..  You know diz duck better than that...  

Iam not talking about IDX/SUB subs ..  Iam very well aware those are DVD Vob subtitles that ofcourse needs to be converted to PGS , easy peasy..  NO, i wos talking about what i specifically wrote .. yezzzzz... → SubRip → Text files .. not PGS a.k.a presentation Graphic Stream or IDX/sub vobsubs  !!

No, i talk about → simple text based subtitles isn't supported anymore in ffmpeg for the mux process !!??

cheers,