h264 Codec Tag avc1 file cannot be played through web browsers

[Badoune 3]

Why would Chrome or Edge would play those files on my PC (that is my emby server) and on those same browsers but connected remotely they wont let me play them?

[Luke 37095]

7 hours ago, Badoune said:

Why would Chrome or Edge would play those files on my PC (that is my emby server) and on those same browsers but connected remotely they wont let me play them?

Assuming they're playing the same way, it wouldn't matter. It would be the same both ways.

[Badoune 3]

Well playing the file ''direct connect'' work, remote connect don't work? they don't play the same since one way works and the other doesn't...

[Luke 37095]

On 3/23/2022 at 1:58 AM, Badoune said:

Well playing the file ''direct connect'' work, remote connect don't work? they don't play the same since one way works and the other doesn't...

Can we please look at an example? Server/ffmpeg log? Thanks.

[Badoune 3]

I cannot create a ffmpeg log since the problem files will not even start to play... Already added the server log on previous post...

[Badoune 3]

Just did a test with my friend, he started a movie remotely, the movie took 16 minutes before it started playing... once it started, it was in direct play mode... and no ffmpeg log...

[Luke 37095]

17 hours ago, Badoune said:

Just did a test with my friend, he started a movie remotely, the movie took 16 minutes before it started playing... once it started, it was in direct play mode... and no ffmpeg log...

If there's no ffmpeg log then it sounds like the video player downloaded the entire file before it started playing.  What do they have the quality setting configured to? I would suggest lowering it so that the server can transcode it down to a lower bitrate.

[visproduction 123]

On 2/22/2022 at 11:10 PM, Badoune said:

 

Hi and thanks for the reply! I have tested this player on two PC and it works! can this gives clues on why it does not work on the ''normal'' browsers?

Badoune,

Did you not read the page, I linked to in my above comment?  Where it talked about why some audio codecs do not work on some browsers?

 

On 2/8/2022 at 11:56 AM, visproduction said:

Suspect the issue can be Audio codec LC with bitrate above 160 kbps is not supported by some browsers and hardware.  See: https://confluence.atlassian.com/confkb/unable-to-play-embedded-mp4-videos-on-ipad-or-iphone-in-confluence-305037325.html

Use bitrates 160kbps or 128 kbps in LC or use HE-AAC instead if you want a higher bitrate.

Hope that helps.

 

[Badoune 3]

12 hours ago, visproduction said:

Badoune,

Did you not read the page, I linked to in my above comment?  Where it talked about why some audio codecs do not work on some browsers?

 

 

Hi! yes thanks for the reply but why would it work in the same version of Chrome on my Emby server PC but it would not work when connected remotely on the same Chrome version... this is my problem/question that I have...

[visproduction 123]

Aha, that may need a little investigating.  When you connect remotely, even if you do it from your workstation in your house and the server is also in your home network, then you have to send a TCP packet requesting data through your router, out to your host DNS server which queries the DNS lookup record.  This might very well send you first to your host's main server, probably to a second peer to peer server which then finds the DNS IP address record to head back to your host and your host server takes the TCP request packet back and sends it to your server at port.  It queries if the port is open and not blocked, then it heads back to your server and requests content streaming packets from your EMBY dbase for the media.

Then the streaming packets of the media stream might go out to the host DNS server again to confirm the IP, the host server may move the packet again to the peer router server which again routes it back to your host, back to you, asks if the port is available and then sends the request to get the next TCP packet of the media.  I think also there are some awk TCP packets sent back from your workstation that the packet was received and it goes through the whole process back to the server.  Awk packets are handled differently for UDP media packets.

Then, the host auto limits outbound upload traffic to a maximum limit that is usually about 10% of the download speed.  That's normally fast enough, but if 3 other users are online doing something, you could hit a limit where media buffers.

None of this happens when you request media locally. 

So any delay or heavy load on the DNS server, or if the host is paying for a remote DNS, these could slow down the packet transfer.  Then there are other settings that are of interest.  I sort of doubt these would start happening, because the problem usually only comes up when you are trying contact a server out of the country.  There is a maximum setting for allowing TCP packets to be received out of order.  It's called RWIN inside your TCP settings in your workstation.  It's all automatic now in Windows and Mac OS since the last 15 years.  If for some extreme case, you get more than 10 out of order packets and the first packet hasn't arrived, for example, then that 1st packet in the list is considered lost and is requested again.  You end up with a lot of dropped packets and the media stutters.  Window and Mac have their TCP settings tuned to typical longest delay for national sites.  When I set up remote offices in Africa, I had to go in and tweak the RWIN settings.  When you download UDP packets, it's different and I think only the first connection packet is tested, but you can also get lost packets that need to be resent.  Anyway, it's doubtful this is happening, but it's also possible. All the host packet handling might slow the data transfer enough to hit a RWIN limit;  the DNS server to main peer server, lookup DNS record, keeping the route cached, accessing the cache, accepting a TCP routing as valid, outbound speed limit for your host contract auto slows the data.  Any combination that causes a packet to not get through, once it hits the RWIN limit, the packet is considered lost and you could get buffering.  But, it's more likely something else.

You really didn't think accessing content locally should be identical to remotely did you? Ha!

Hope that helps.

 

Edited March 29, 2022 by visproduction

[Badoune 3]

3 hours ago, visproduction said:

Aha, that may need a little investigating.  When you connect remotely, even if you do it from your workstation in your house and the server is also in your home network, then you have to send a TCP packet requesting data through your router, out to your host DNS server which queries the DNS lookup record.  This might very well send you first to your host's main server, probably to a second peer to peer server which then finds the DNS IP address record to head back to your host and your host server takes the TCP request packet back and sends it to your server at port.  It queries if the port is open and not blocked, then it heads back to your server and requests content streaming packets from your EMBY dbase for the media.

Then the streaming packets of the media stream might go out to the host DNS server again to confirm the IP, the host server may move the packet again to the peer router server which again routes it back to your host, back to you, asks if the port is available and then sends the request to get the next TCP packet of the media.  I think also there are some awk TCP packets sent back from your workstation that the packet was received and it goes through the whole process back to the server.  Awk packets are handled differently for UDP media packets.

Then, the host auto limits outbound upload traffic to a maximum limit that is usually about 10% of the download speed.  That's normally fast enough, but if 3 other users are online doing something, you could hit a limit where media buffers.

None of this happens when you request media locally. 

So any delay or heavy load on the DNS server, or if the host is paying for a remote DNS, these could slow down the packet transfer.  Then there are other settings that are of interest.  I sort of doubt these would start happening, because the problem usually only comes up when you are trying contact a server out of the country.  There is a maximum setting for allowing TCP packets to be received out of order.  It's called RWIN inside your TCP settings in your workstation.  It's all automatic now in Windows and Mac OS since the last 15 years.  If for some extreme case, you get more than 10 out of order packets and the first packet hasn't arrived, for example, then that 1st packet in the list is considered lost and is requested again.  You end up with a lot of dropped packets and the media stutters.  Window and Mac have their TCP settings tuned to typical longest delay for national sites.  When I set up remote offices in Africa, I had to go in and tweak the RWIN settings.  When you download UDP packets, it's different and I think only the first connection packet is tested, but you can also get lost packets that need to be resent.  Anyway, it's doubtful this is happening, but it's also possible. All the host packet handling might slow the data transfer enough to hit a RWIN limit;  the DNS server to main peer server, lookup DNS record, keeping the route cached, accessing the cache, accepting a TCP routing as valid, outbound speed limit for your host contract auto slows the data.  Any combination that causes a packet to not get through, once it hits the RWIN limit, the packet is considered lost and you could get buffering.  But, it's more likely something else.

You really didn't think accessing content locally should be identical to remotely did you? Ha!

Hope that helps.

 

Thanks for detailed reply! Also remember that my problem only occurs when the h264 file has a ''Codec Tag avc1''... any other format works A1

[visproduction 123]

Right, so audio AC3 and LP encoding above 128 kbps are both known issues that causes most browsers playback to fail. Safari and older Edge might be exceptions.  Some 3rd party software like VLC plays back AC3 with no problem.  I think there may be some browser plugin option for a 3rd party player.  I've never bothered to try those because I want make my video playable for everyone.  So if you content has AC3 audio available as an alternate or main audio, that would explain a browser failing to play it back.  I know that the default playback could be AAC and that is cached by the browser.  If you go to the same content through an outside IP address, the browser could consider the AC3 as the default and that would error out as not playable in the IP but playable in the local.  Same exact problem if you have LP audio with bitrates higher than 128 kbps.

So, all these connections should only be tested with a test video and not a random video that you have issues.  There is probably other metadata errors in the timeline, that are interpreted differently when you access the media local vs. IP address.  There is no point in trying to fix one random video that doesn't work.  You need to use a test video of high quality that you can download online for MP4 and AAC.  If that works for all situations, then it is your video that is at fault.  Trying to test on a problem video, is sort of a waste of time.

Hope that makes sense.

[Badoune 3]

4 hours ago, visproduction said:

Right, so audio AC3 and LP encoding above 128 kbps are both known issues that causes most browsers playback to fail. Safari and older Edge might be exceptions.  Some 3rd party software like VLC plays back AC3 with no problem.  I think there may be some browser plugin option for a 3rd party player.  I've never bothered to try those because I want make my video playable for everyone.  So if you content has AC3 audio available as an alternate or main audio, that would explain a browser failing to play it back.  I know that the default playback could be AAC and that is cached by the browser.  If you go to the same content through an outside IP address, the browser could consider the AC3 as the default and that would error out as not playable in the IP but playable in the local.  Same exact problem if you have LP audio with bitrates higher than 128 kbps.

So, all these connections should only be tested with a test video and not a random video that you have issues.  There is probably other metadata errors in the timeline, that are interpreted differently when you access the media local vs. IP address.  There is no point in trying to fix one random video that doesn't work.  You need to use a test video of high quality that you can download online for MP4 and AAC.  If that works for all situations, then it is your video that is at fault.  Trying to test on a problem video, is sort of a waste of time.

Hope that makes sense.

I have the problem on all the h264 files that has a ''Codec Tag avc1'', I tried more than 50+ different movies so far and NONE would work remotely

[visproduction 123]

Badoune.

Many issues can cancel playback.  Audio can also cancel playback for h264 avc1.  Bad timeline or metadata errors can cancel playback on browsers and not on 3rd party direct players if the media has some issue.  It is very possible that audio or file errors in your media might be the cause.  This is why you need to use test file media instead to see where the problem lies, not media you get from some random place or media that you have created.  I think you are blaming a video codec when that is probably not the problem.  It's much likely your files have issues.

https://jell.yfish.us/
https://test-videos.co.uk/bigbuckbunny/mp4-h264

Just test the smallest size video from a test site that has h264 codec.

[Badoune 3]

On 3/31/2022 at 9:26 PM, visproduction said:

Badoune.

Many issues can cancel playback.  Audio can also cancel playback for h264 avc1.  Bad timeline or metadata errors can cancel playback on browsers and not on 3rd party direct players if the media has some issue.  It is very possible that audio or file errors in your media might be the cause.  This is why you need to use test file media instead to see where the problem lies, not media you get from some random place or media that you have created.  I think you are blaming a video codec when that is probably not the problem.  It's much likely your files have issues.

https://jell.yfish.us/
https://test-videos.co.uk/bigbuckbunny/mp4-h264

Just test the smallest size video from a test site that has h264 codec.

the test files all works.

Out of my 4200+ emby librairy, I must have at least 2000+ h264 files that has a ''Codec Tag avc1'' with ACC sound track and i'm sure none of them will start remotely, Like I said before I tested 50+ so far and none would work. I have to convert the ACC sound track to a AC3 format and then the files start flawlessly everytime...

[pwhodges 1532]

On 31/03/2022 at 07:01, Badoune said:

I have the problem on all the h264 files that has a ''Codec Tag avc1'', I tried more than 50+ different movies so far and NONE would work remotely

You haven't yet provided a log which might easily provide the answer.  You said there was no ffmpeg log, but there is always a server log.

This could be as simple as these files requiring transcoding when accessed remotely, but transcoding being disabled in the server settings, for instance.

But the server log should give that information.

Paul

[Luke 37095]

24 minutes ago, pwhodges said:

You haven't yet provided a log which might easily provide the answer.  You said there was no ffmpeg log, but there is always a server log.

This could be as simple as these files requiring transcoding when accessed remotely, but transcoding being disabled in the server settings, for instance.

Yup, bingo.

[KegTapper 8]

I didn't pay attention to this topic until now.  But I am having the exact same problem when remotely playing H264 with codec tag acv1.  The audio codec is the cause of my issues.  My co-workers and I use edge remotely at work.  I simply lower the bitrate, the videos transcode, playback normally. I started dabbling with tdarr to add audio streams

[Happy2Play 8296]

But previous OP posts show user policies set to "true" but every new example needs logs.

Still can not reproduce on any local or remote connection with h264 avc1 aac media.

[Badoune 3]

On 4/7/2022 at 8:41 AM, pwhodges said:

You haven't yet provided a log which might easily provide the answer.  You said there was no ffmpeg log, but there is always a server log.

This could be as simple as these files requiring transcoding when accessed remotely, but transcoding being disabled in the server settings, for instance.

But the server log should give that information.

Paul

I have put a server log on previous post, transcoding is enable, ffmpeg log does not get created since the files wont even start playing... they will start after 16minutes but no log either...the file must download itself completely... I also posted a printscreen of my server settings, feel free to check and see if I have something wrong there

[Happy2Play 8296]

@LukeWhat would cause client to Download file before playing?  But lowering quality will cause it to transcode and stream instantly.

I can say neither of my servers this way.

[Luke 37095]

16 minutes ago, Happy2Play said:

@LukeWhat would cause client to Download file before playing?  But lowering quality will cause it to transcode and stream instantly.

I can say neither of my servers this way.

The two most common reasons are a mis-configured reverse proxy not properly supporting range request headers. 

Another could be that the file is not encoded properly and therefore the client needs the whole thing before it can start playing. That's rare though.

[Luke 37095]

On 4/9/2022 at 2:26 AM, Badoune said:

I have put a server log on previous post, transcoding is enable, ffmpeg log does not get created since the files wont even start playing... they will start after 16minutes but no log either...the file must download itself completely... I also posted a printscreen of my server settings, feel free to check and see if I have something wrong there

Can you provide a sample video for testing?

[Happy2Play 8296]

Just now, Luke said:

Can you provide a sample video for testing?

I got the file from online and cannot reproduce the issue and connecting to OP server I see in debug console the file downloading while having the spinning circle on screen.  My server just servers the file.  So this would have to be specific to setup.

@Badouneare you running a reverse proxy?

[Luke 37095]

@pir8radio are you able to reproduce?