Edit: Didn't see the new files attached...
x264-r2969-d4099dd-c.mkv - Works!!
x264-r2969-d4099dd-d.mkv - Unsupported video data
If that's the case, is it possible to reencode a sample with working encoders (2945 for example) with those parameters to see if that make that sample unplayable?
Edit: Probably I'm mistaken, but in the version history:
It says that it was changed on 9th of april 2018. Waaay too long ago. The r2969 version is from 12th March. It should be something they changed between 11 and 12th of march, isn't it?Signal Progressive and Constrained profiles
commit | commitdiff | tree
Yusuke Nakamura [Mon, 9 Apr 2018 02:01:28 +0000 (11:01 +0900)]
Signal Progressive and Constrained profiles
Progressive High, Constrained High, and Progressive High 10.
Even in Main profile, constraint_set4_flag is now set to 1 if progressive,
and constraint_set5_flag is set to 1 if no B-slices are present.
+ Reply to Thread
Results 31 to 42 of 42
Last edited by erunamo; 1st May 2019 at 08:52.
It wasn't committed until March 6th 2019. Sample "x264-r2969-d4099dd-c.mkv" is basically just a hex edit to change those flags to 0. So I'm fairly certain they are the cause. Seems to be Samsung bug.
One very last sample.
Sample d: constraint_set4_flag=1, constraint_set5_flag=0
Sample f: constraint_set4_flag=0, constraint_set5_flag=1
constraint_set4_flag=1 means progressive, contraint_set5_flag=1 means no bframes. You can't set those options on the command directly, unfortunately. Only (de)activate interlacing/bframes. So I think interlaced (incl. "fake interlaced") encodings should still work on Samsung.
Last edited by sneaker; 1st May 2019 at 09:26.
I think next we should see if files produced by other encoders but with constraint_set4_flag=1 still work for some reason.
x264-r2969-d4099dd-f.mkv doesn't work
If "c" version is just a hex edit, is it possible to edit those mkv that doesn't work to make them playable?
I replaced every instance of (hex) 00 00 00 01 67 64 0C by 00 00 00 01 67 64 00 in the elementary/raw H.264 bitstream. But I can't guarantee you it's always this easy because the spec is too complicated for me to fully understand.
I think 00 00 00 01 is kind of a magic number/start code. Then 67 64 is dependend on the profile being used so can be different. Then the 0C/00 at the end is the actual constraint_setn_flags and 2 reserved bits.
You could try changing the first instance for a start. Maybe playback doesn't stop.
It's probably better to learn how to change the source code and compile x264 yourself. Or speak to the developers.
Edit: I've tried and in my file this is what showed up:
00 00 00 01 67 64 08 29 AC D0 A0 14 01 6E C0 5A 81 01 00 A0 00 00 7D 20 00 17 70 11 E3 06 21 50 00 00 00 01 68 E8 9C 08 CB 22 C0
It seems that the byte 08 have those flags to 0... What am I doing wrong?
Edit 2: I've replaced 08 with 00 in the begining, and the file works, but crash after 3 seconds... I guess I have to change every instance of the flag...
Edit 3: Replacing every instance to 67 64 00 the file is completely playable...
Isn't there any tool out there to modify this flag?
Last edited by erunamo; 1st May 2019 at 14:22.
You just modified it.
Oh, you mean "automated" replacement tool. PowerGREP?
[Attachment 57459 - Click to enlarge]
The value of number of B-Frames must be zero. If it happens that way, samsung supports video. Samsung played the sample video because bframes = 0 in the x264-r2969-d4099dd-c example. I understood this from the examples. But if you have the means, for example using x264 r3033 0d754ec, you will have no problem if you use it.
I noticed that. the problem is not only with the r2969 version. Samsung cannot play video on all versions of Core 157. There was a problem with another video just now. x264 core 157 r2970 5493be8