I have a question regarding the best way to playback DV FEL files. My setup is almost the same as yours (LG C2 and a Denon AVR) but i have a shield Pro.
I was wondering if upgrading to the x800m2 would be a good idea as it has FEL support but i was looking at previous posts and saw that the L1/L2 bugs affect this player.
Is there any difference between the two players for DV playback (besides the red push in the shield which I also see)? What is your current setup?
overall, the x800m2 (or oppo and x700) easily wins over the shield in terms of quality.
Not to mention that some bluray lately has been using FEL to expand the brightness of the BL and these blurays can only be played properly on FEL devices.(unless you bake FEL into the BL)
EG: https://www.youtube.com/watch?v=VObky4peBXE
I thought mp4box only spits out hvc1 unless DV5? And that the Dovi mp4muxer is what spits out hev1?
7-1-1 in my script doesn't not use the mp4muxer unless your input has 7.1 lossless audio. It's mp4box doing the muxing and the people that tested on the appletv did not complain about stuttering.
so the test file I sent you is from mp4box only.
What command did you use through mp4box (through your scripts) to get hev1 codec then? And the test file stutters on my iPhone just like when me and the Chinese guy here were figuring out the whole stuttering thing with the hev1/hvc1 codec ID. I can try and screen record that if you want.
You might want to check if a line in one of your scripts is off and it's sending stuff to mp4muxer instead of mp4box? Look at the codec ID of the file you gave me and try pumping another one out through command line only and mp4box only yourself - without going through your scripts at all to eliminate it possibly accidentally using mp4muxer?
Here's your file codec ID
Here's directly piped out though mp4box with command line:
Your file also doesn't have the mp4box bug of listing HDR10 over and over when a DV file
You might want to check if a line in one of your scripts is off and it's sending stuff to mp4muxer instead of mp4box?
it possibly accidentally using mp4muxer?
no it's not.
As I said, only if your input has lossless 7.1, then mp4muxer will be used because mp4box choke on 7.1 EC3 audio muxing.
my cmd is full of variable but if you input raw hevc:
You might want to check if a line in one of your scripts is off and it's sending stuff to mp4muxer instead of mp4box?
it possibly accidentally using mp4muxer?
no it's not.
As I said, only if your input has lossless 7.1, then mp4muxer will be used because mp4box choke on 7.1 EC3 audio muxing.
my cmd is full of variable but if you input raw hevc:
Also here you can see because the file does end up with codec ID hev1 however it does - it does stutter on iOS devices like me and that Chinese guy were talking about a while back
You might want to check if a line in one of your scripts is off and it's sending stuff to mp4muxer instead of mp4box?
it possibly accidentally using mp4muxer?
no it's not.
As I said, only if your input has lossless 7.1, then mp4muxer will be used because mp4box choke on 7.1 EC3 audio muxing.
my cmd is full of variable but if you input raw hevc:
Also here you can see because the file does end up with codec ID hev1 however it does - it does stutter on iOS devices like me and that Chinese guy were talking about a while back
Also here you can see because the file does end up with codec ID hev1 however it does - it does stutter on iOS devices like me and that Chinese guy were talking about a while back
Also here you can see because the file does end up with codec ID hev1 however it does - it does stutter on iOS devices like me and that Chinese guy were talking about a while back
I don't know about phone playback and don't have an apple device(never will).
I only tested the ATV with @ragico and he didn't report any stuttering.
IIRC Resolve dv 8.1 mp4 are also HEV1
I'll see if I can find someone over on [H] forum or AVSForum with an AppleTV to confirm that unless someone else here does first- just to be sure - stuff happens - maybe the test file at that time was hvc1? maybe they just didn't notice? Maybe it only does happen on phones or tablets? Maybe the Apple TV can just power through SW decode? Maybe one of a hundred other things?
Frustrating - nothings ever easy or simple :/
Edit: And like I said - this is only NF titles - not 4K BR DV or other Web DV titles :/
no, my script (7-1) always created HEV1 P8 or DVH1 P5 mp4
maybe splitting the file broke something, did you try (7-1) with an untouched P8 mkv that has audio and subs?
For P8 on ATV you have to use infuse. For plex you have to use 'fake' P5(p8).
no, my script (7-1) always created HEV1 P8 or DVH1 P5 mp4
maybe splitting the file broke something, did you try (7-1) with an untouched P8 mkv that has audio and subs?
For P8 on ATV you have to use infuse. For plex you have to use 'fake' P5(p8).
I can't use HEV1 for my setup unfortunately - besides occasionally watching from my iPhone when at the airport/waiting rooms - I share Plex with people that watch from iPhone only (way the world is now sometimes lol)
I wanted to avoid fake P5 files if I could - was fine with P8 only playing back as HDR10 on iOS as long as no stutter - I'll give it a shot just to see
@sw5163 said he noticed this on All Quiet on the Western Front too (another NF title)
I asked quietvoid via DM - maybe NF authors these in HEV1/DVHE originally? And that's somehow why they refuse to work as HVC1? (edit: he said negative on that)
I forgot to mention one very important info: Apple require the video track fourcc ID to be “dvh1” for Dolby Vision. So you need to change it manually using a Hex editor. (More info: the sample I recommended to you is “dvhe”, which cannot be played by QuickTime/Apple TV app)
The correct codec ID (for profile 8.1) should be "hvc1" in place of "hev1". But be careful, these boxes are not random: they indicate to the decoder how the information for the initialization of the latter is stored within the file. Changing the header with a hex editor isn't always enough!
I also tried to change "dvh1" to "hvc1" of the MBox profile 8.1 sample. The resulting file can be played in QuickTime (contrast still wrong), but cannot be played on my iPad. This is what I could't understand. It should be at least backward compatible with HDR10, like your Terminator sample.
As I said, very often it is not enough to change the header of a box for the file to be played. QuickTime is perhaps smarter and can retrieve the information needed to initialize the decoder. The iPad player may not be capable of it!
I guess Plex is doing something wrong when processing hev1.
Apple can retrieve the information needed to initialize the decoder even if the file is wrongly muxed.
But it requires powerful processor. So on newer iPhone/Mac/ATV playback will not have the black screen/stutter problem.
I guess Plex is doing something wrong when processing hev1.
This happens on Windows too with no Plex in the chain, where all my screenshots showing the issue come from. And again only for NF titles - that there shows it's something with these specific titles in particular.