VideoHelp Forum
+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 42 of 42
Thread
  1. Originally Posted by sneaker View Post
    Thx. See post #28.
    I've checked that post but I really don't know...

    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:
    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.
    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?
    Last edited by erunamo; 1st May 2019 at 08:52.
    Quote Quote  
  2. 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.
    Image Attached Files
    Last edited by sneaker; 1st May 2019 at 09:26.
    Quote Quote  
  3. I think next we should see if files produced by other encoders but with constraint_set4_flag=1 still work for some reason.
    Quote Quote  
  4. 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?
    Quote Quote  
  5. 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.
    Quote Quote  
  6. Originally Posted by sneaker View Post
    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.
    I'll try, it's worth trying :P

    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.
    Quote Quote  
  7. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    You just modified it.

    Oh, you mean "automated" replacement tool. PowerGREP?

    Scott
    Quote Quote  
  8. Originally Posted by Cornucopia View Post
    You just modified it.

    Oh, you mean "automated" replacement tool. PowerGREP?

    Scott
    Yes I meant some "h264 sps editor" to edit that bit in every instance of a file. Because searching and replacing could end in replacing strings which weren't part of the sps... But at least works.

    By the way, a million thanks sneaker!!!
    Quote Quote  
  9. Member
    Join Date
    Apr 2020
    Location
    Portugal
    Search Comp PM
    Originally Posted by sneaker View Post
    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.
    Hi, everyone. Sorry to re-open the thread after so many time.
    I have the same issue with x264 core 157 r2969 d4099dd playing in my Samsung FHD TV.
    Would you please explain how can I edit those "algorithms"?

    Thanks in advance.
    Quote Quote  
  10. Originally Posted by VideoPT View Post
    Originally Posted by sneaker View Post
    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.
    Hi, everyone. Sorry to re-open the thread after so many time.
    I have the same issue with x264 core 157 r2969 d4099dd playing in my Samsung FHD TV.
    Would you please explain how can I edit those "algorithms"?

    Thanks in advance.

    Image
    [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.
    Quote Quote  
  11. 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
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!