Continuing problems playing mkv files via ChromecastHDwGTV

[wordlover 104]

ARGH! It isn't fully fixed by disabling audio transcoding. I tried another video - foreign film - with multiple subtitle files, and the playback control problems are still there.

[wordlover 104]

Here are file details on two different files that still don't have proper playback control even after disabling audio transcoding: 

 

And here is a file that DOES play properly but only after disabling audio transcoding:

 

 

[ebr 14948]

17 hours ago, wordlover said:

with multiple subtitle files

If the item ends up needing to remux for any reason, the problem is going to re-occur.

This is why I said originally that, even if we could work around this instance, it wasn't a true solution.  The real problem is the way the files are constructed.  Have you tried re-encoding one of them to see if that fixes the timing data?

[ebr 14948]

18 hours ago, wordlover said:

As Carlo noted upthread:  "EAC-3 AC-3 is supported on the CC Google TV device

18 hours ago, wordlover said:

It does not - single "English AAC audio" track.

AAC is not EAC3...

However, it appears the device does support AAC if that is the true audio codec that was involved.

[wordlover 104]

1. Yes, I ran several of these files through MKVToolNix, which didn't fix the problem.

2. Of the latest batch of files showing this problem, the ones that were 'fixed' when audio transcoding is turned off are all in TV library, while the ones in Movie library still have same problem, if that's useful info for you.

2. You keep raising "but this might be a future problem" concerns. But right now this is a problem with scores and scores of files from a diverse range of sources. Y'all pitch Emby as a great streaming solution. I just want to use Emby to stream video files direct to my CCHD with no transcoding or other alteration - that's it! They play and control absolutely fine when cast to old CC. For some reason your software is doing unnecessary transcoding only when casting to CCHD. Let's not solve hypothetical problems, let's solve the problem that's right here, right now. 

[wordlover 104]

To give you full comp information yet again, attached are logs and media info for a movie that still has the same playback control problem as before. To repeat the summary of the exact same process:

Running Emby Android app on Pixel 5a phone, connect Emby server to Original CC (Chromecast 1), cast movie, play 15 seconds, press Emby "skip 30 seconds" button, playback jumps 30 seconds and playback continues as normal. 

Stop movie, disconnect from Old CC, connect to new CCHD (Chromecast 2), cast movie, play 15 seconds, press Emby "skip 30 seconds" button, but now video on TV freezes at 0:15 while the timeline on the phone app resets to 0:00 and starts over, while video remains frozen until phone app 'catches up', i.e. timeline reaches 0:45 (i.e. original 0:15 plus attempted 0:30 jump), and playback continues normally. 

Audio transcoding is turned off in user settings.

Below are screen captures of media information for this video file (in the Movie Library) that Emby doesn't control properly when casting to CCHD, and also for a video file (in the TV Library) that DOES control properly, now that audio transcoding is turned off. What differences do you see in the logs that would explain this different Emby behavior when casting the exact same file to two different CC devices?

ffmpeg-directstream-b4fdc8e5-fc13-4644-b39e-44e9fe140a06_1.txt ffmpeg-directstream-45df84d0-57dd-451f-87fa-75914181056f_1.txt ffmpeg-directstream-49aff8e3-7a41-43b8-8f9c-ef8e052f1207_1.txt ffmpeg-directstream-e07c6d76-e34e-4a7f-b1ec-5ff200a5a4e9_1.txt embyserver.txt

[ebr 14948]

19 hours ago, wordlover said:

Yes, I ran several of these files through MKVToolNix

Hi.  That is not re-encoding it.  That is just re-packaging it.  You would need to use something like ffmpeg to actually re-encode the video and see if that fixes the timing information.

[wordlover 104]

But again, these files play fine when not transcoded. Can you make Emby stop needlessly doing so? Or whatever else Emby is doing only when casting to CCHD.

Edited July 15, 2023 by wordlover

[Carlo 4330]

  

On 7/12/2023 at 1:42 AM, Luke said:

Because that's what it's telling us is supported. To my knowledge, Chromecast doesn't support any ac3 or eac3 decoding. so it can only pass it through to something that can decode it. So it depends on what it's connected to that will determine what audio formats are supported or not.

Emby bases the decision for sending AAC or transcoding it based on what the device specifies when prompted for it's abilities.  On my setup I can set the Chromecast w/ Google TV to use passthrough for AAC and your video plays for me on both the new and old.  If I turn off AAC passthrough it will transcode and i have similar issues to what you have reported as the file doesn''t transcode clean as it has timing issues (if I remember correctly).

On 7/13/2023 at 3:12 PM, wordlover said:

As Carlo noted upthread:  "EAC-3 AC-3 is supported on the CC Google TV device but we're not sending this audio codec to ffmpeg as a choice. Part of the problem here besides files with dozens of subs and files with bad timings is that we're doing audio transcoding and remuxing when we shouldn't have to." 

As mentioned above, this depends on the setup of the device for AAC audio.

On 7/13/2023 at 3:13 PM, Luke said:

Are you sure? How many channels is the track?

One of his files I've used to test with has the following:

[wordlover 104]

@CarloWhere do you see CCHD settings for passthrough for AAC? I have drilled down into every menu item on mine and only see settings for Dolby and DTS stuff.

[wordlover 104]

@CarloPlease let me know how to do this: "I can set the Chromecast w/ Google TV to use passthrough for AAC" - I don't see settings to do that either on the CCHD nor in Emby.

[ebr 14948]

I think maybe AAC and EAC3 are getting mixed up here...

I doubt the device has any settings for AAC as its specs mention nothing of supporting that format.  I think, in the end, we probably just need to assume it is supported even though the device may not be reporting it.  It seems you've proven that will work - at least in your setup - by denying audio transcode permissions.

However, that is still just dodging the root issue which is the timing data in the source file.  So any other situation that requires a remux or transcode will just encounter it again (as you saw with the subtitles).

[wordlover 104]

But again: why do these play and control fine on old CC?!

[ebr 14948]

4 minutes ago, wordlover said:

why do these play and control fine on old CC?!

Probably because that device reports support for AAC.

[wordlover 104]

On 7/25/2023 at 7:36 AM, ebr said:

I think maybe AAC and EAC3 are getting mixed up here...

I doubt the device has any settings for AAC as its specs mention nothing of supporting that format.  I think, in the end, we probably just need to assume it is supported even though the device may not be reporting it.  It seems you've proven that will work - at least in your setup - by denying audio transcode permissions.

However, that is still just dodging the root issue which is the timing data in the source file.  So any other situation that requires a remux or transcode will just encounter it again (as you saw with the subtitles).

I genuinely am not trying to be rude, but what you're saying doesn't make logical sense. Files that require remuxing for subtitles play fine on old CC but not on CCHD. If timing data was the problem, ffmpeg should choke on them in both instances, but does not. Why? 

[ebr 14948]

3 hours ago, wordlover said:

Files that require remuxing for subtitles play fine on old CC

Do you have an example of that (ffmpeg log)?

[wordlover 104]

15 minutes ago, ebr said:

Do you have an example of that (ffmpeg log)?

See attached. I did the same order of operations as in example above from July 14. I added a number to the front of the ffmpeg files so you can see order they were created. I have no idea why two were created for each playback, on Old CC and CCHD. Also attached is log file, as well as video file info. In user settings, transcoding is set to on for audio & video. It plays and controls fine on Old CC.

embyserver.txt 4-ffmpeg-transcode-4c831e90-214e-4696-b454-3c6e8f0e00f0_1.txt 3-ffmpeg-transcode-20b18eda-c907-4753-a719-43adba5fe139_1.txt 2-ffmpeg-transcode-6693c3a2-6184-4204-9bb7-856de598d389_1.txt 1-ffmpeg-transcode-4071fc31-5c86-4bc4-879b-662cabe3e6c0_1.txt

[ebr 14948]

There must be differences in the implementation on the CC devices because both are playing from Emby in exactly the same manner.  The technical differences between the devices are that the newer one supports DD and DD+ where the old one doesn't and the new one supports HEVC and VP9 where the old one doesn't.  But none of those differences come into play in this example because both of them do report support for AAC and h264 which is  what this example is.

The stream being sent to the device by Emby is identical in both cases:

12:53:03.406 Output #0, matroska, to 'C:\Users\TedWeinstein\AppData\Roaming\Emby-Server\programdata\transcoding-temp\DD6C72\DD6C72.mkv':
12:53:03.406   Metadata:
12:53:03.406     encoder         : Lavf59.17.100
12:53:03.406   Stream #0:0: Video: h264 (H264 / 0x34363248), yuv420p(tv, bt709, progressive), 704x396 [SAR 1:1 DAR 16:9], q=2-31, 24 fps, 1k tbn
12:53:03.406     Metadata:
12:53:03.406       encoder         : Lavc59.21.100 libx264
12:53:03.406     Side data:
12:53:03.406       cpb: bitrate max/min/avg: 2791000/0/0 buffer size: 5583000 vbv_delay: N/A
12:53:03.406   Stream #0:1(swe): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 44100 Hz, stereo, fltp (default)

12:54:30.190 Output #0, matroska, to 'C:\Users\TedWeinstein\AppData\Roaming\Emby-Server\programdata\transcoding-temp\A023FA\A023FA.mkv':
12:54:30.190   Metadata:
12:54:30.190     encoder         : Lavf59.17.100
12:54:30.190   Stream #0:0: Video: h264 (H264 / 0x34363248), yuv420p(tv, bt709, progressive), 704x396 [SAR 1:1 DAR 16:9], q=2-31, 24 fps, 1k tbn
12:54:30.190     Metadata:
12:54:30.190       encoder         : Lavc59.21.100 libx264
12:54:30.190     Side data:
12:54:30.190       cpb: bitrate max/min/avg: 2791000/0/0 buffer size: 5583000 vbv_delay: N/A
12:54:30.190   Stream #0:1(swe): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 44100 Hz, stereo, fltp (default)

 

[wordlover 104]

So what does "differences in the implementation on the CC devices" mean? When streaming to CCHD, playback resets to 0:00, on Old CC it plays from new jump point without interruption. Where does that show up in the emby log or ffmpeg files, and what does that indicate? The full set of logs simply cannot be the same. 

[ebr 14948]

I don't see any indication of an interruption on the ffmpeg side but, perhaps, @softworkzwould have a better analysis.

[wordlover 104]

If that's the case, then that means there's an issue with Emby, which I have been saying for close to a year and trying to get support to resolve.

[Carlo 4330]

On 7/25/2023 at 10:36 AM, ebr said:

I think maybe AAC and EAC3 are getting mixed up here...

I doubt the device has any settings for AAC as its specs mention nothing of supporting that format.  I think, in the end, we probably just need to assume it is supported even though the device may not be reporting it.  It seems you've proven that will work - at least in your setup - by denying audio transcode permissions.

However, that is still just dodging the root issue which is the timing data in the source file.  So any other situation that requires a remux or transcode will just encounter it again (as you saw with the subtitles).

I see AAC reported as part of the spec for the device.

[ebr 14948]

On 7/27/2023 at 12:30 PM, Carlo said:

I see AAC reported as part of the spec for the device.

Yeah, and we are properly allowing it as well (see above example).

[wordlover 104]

Leaving aside that digression, again, what does "differences in the implementation on the CC devices" mean? When streaming to CCHD, when jumping the playback/time bar resets to 0:00, on Old CC it plays from new jump point without interruption. Where does that show up in the Emby log or ffmpeg files, and what does that indicate? The full set of logs cannot be the same. If ffmpeg logs are reporting identical behavior, what is it in Emby's behavior that is causing this? 

[Carlo 4330]

Your files seem to have a problem when transcoding but direct played.