[solved] 0.10.0 vs. 0.9.9 sometimes non-smooth playback on RaspberryPi

[beta-tester]

hi,

i noticed playback differences between videos made by official handbrake 0.10.0 and 0.9.9 on my Raspberry Pi.
i used on both versions the bilt-in "High Profile" settings.
the same video plays back slightly different.
the video created with version 0.9.9 plays back motions always smoothly.
the video created with 0.10.0 plays back partially non-smooth the motion, like there are missing frames...
kind of deinterlacing issue at huge horizontal movements?
this issue appears only on my Raspberry Pi (using official OpenELEC 4.2.1/XBMC 13.2) - even overclocking does not prevent that issue.
i can playback the videos created with both handbrake versions with smooth motion on a PC (using VLC).

i am wondering, if something changed with the builtin "High Profile" in version 0.9.9 to 0.10.0 or is the converter engine changed and i have no chance to get the old smooth motion playback with the new version 0.10.0...

(Windows 8.1 64bit, HandBrake-0.9.9-1_x86_64-Win_GUI.exe, HandBrake-0.10.0-x86_64-Win_GUI.exe, settings: built-in "High Profile")

[Woodstock]

Encoding logs for the same video processed by both versions would make it a LOT easier to tell what is going on....

[beta-tester]

oh, yeah, sorry, i forgot... my fault.
i'll post them, as soon i redo/reinstall both videos with both handbrake versions...
cu tomorrow.

[beta-tester]

here the log-files

Title00-1-0_10_0.mkv 2014-12-13 00-50-45.txt
http://pastebin.com/ex9ZKFjH

Title00-1-0_9_9.mkv 2014-12-13 01-58-25.txt
http://pastebin.com/8RyAz0FM

0_10_0.hbq
http://pastebin.com/wVkCJbLw

0_9_9.hbq
http://pastebin.com/WUKvajUA

(the links will expire in 6 days)

both created video have nearly the same resulting file size - less than 0.01% difference .
but the video created with HB 0.10.0 shows stutter/jagged/non-smoothed motion playback sometimes in the video on the RaspberryPi.
the video created with HB 0.9.9 shows always smooth motion playback on my RaspberryPi.

any ideas?

the only different i can see is in 0.10.0 the CLI query has:
--encoder-level="4.1" --encoder-profile=high
where 0.9.9 has:
--h264-level="4.1" --x264-profile=high

and further down, version 0.10.0 has an additional job configuration, that version 0.9.9 does not show there:

Code: Select all

job configuration:
 * video track
  + frame rate: same as source (around 24.000 fps)

and the exported query files differs in:

Code: Select all

#0.10.0:
      <DenoisePreset>Weak</DenoisePreset>
      <DenoiseTune>None</DenoiseTune>
      <H265Profile>None</H265Profile>
      <QsvPreset>Balanced</QsvPreset>
      <X264Preset>Medium</X264Preset>
      <X264Tune>None</X264Tune>
      <X265Preset>VeryFast</X265Preset>

and

Code: Select all

#0.9.9:
      <Denoise>Off</Denoise>
      <X264Preset>Medium</X264Preset>

[beta-tester]

i found a related post
viewtopic.php?f=11&t=31304&p=144236

[s55]

Can you try remux the file that won't play smooth on rPI with mkvmerge

[beta-tester]

i used MKVToolNix GUI 7.4.0 to remux the bad video file made by hb 0.10.0...
in the remuxed output file, the issue is still present at the exact same position(s).

Code: Select all

C:\Users\ich\Downloads\mkvtoolnix-amd64-7.4.0\mkvmerge
--output E:/EQ/0.10.0/Title00-1-0_10_0-2-remuxed.mkv
--language 0:und ( E:/EQ/0.10.0/Title00-1-0_10_0-2.mkv )

[s55]

Couple things to try:

1. Turn off decomb (don't actually need it for bluray content) You'll get faster encodes as a bonus.
2. Try setting the h.264 level to 4.0 This will keep bitrate spikes to a much lower level. You might just be hitting a bandwidth issue on the pi.

[beta-tester]

i used avidemux - just opened the bad video file and converted "copied" its content to an avi file.
with the avi file, the issue is gone.

PS.: i created the video as mp4 from the raw source file with the same settings as for mkv... that created mp4 file shows also the issue like the mkv (only to be sure, is it not only a container issue)

[beta-tester]

Couple things to try:
1. Turn off decomb (don't actually need it for bluray content) You'll get faster encodes as a bonus.
2. Try setting the h.264 level to 4.0 This will keep bitrate spikes to a much lower level.

i tried various combinations of that steps.
deinterlace(off), h264level(4.0), ...
deinterlace(off), h264level(4.1), ...
decomb(off), h264level(4.0), ...
decomb(off), h264level(4.1), ...
decomb(bob), h264level(4.1), ...
with all combinations the issue is still present.
(btw: in the high profile settings there is decomb selected, but its subvalue is setted to off... is deinterlaced selected and its subvalue off, is this then the same?
can be a bit confusing, when tell turn decomb to off... is it of with decomb(off) or deinterlaces(off) or in both cases?)

creating with deinterlace(bob), h264level(4.1), ...
makes playback smooth even on RPi...
but why is the result of hb 0.9.9 and hb 0.10.0 different by using the same built-in "High-Profile" settings???
and why is deinterlacing=bob in handbrake making such a difference at progressive (non-interlaces) video content - makes that any sense??? (1080p video content, 1080p player hardware, 1080p TV)

You might just be hitting a bandwidth issue on the pi.

no no no no, definitely not!
the RPi uses hardware accelerated decoding & rendering.
that pice of hardware is specially made for h264 high profile 4.1.
and as i sayed, videos made with hb 0.9.9 play always smooth,
same video with same settings created with hb 0.10.0 shows playback issues.
and i also turned the video quality down to RT=24 and exactly the same behaviour on hb 0.10.0 made videos.


that's too many questions, i can not get explaned, yet...
is it possible to use th new userinterface of handbrake 0.10.0 and the CLI of handbrake 0.9.9?
i want to switch back to 0.9.9, but the GUI of 0.10.0 is way more user friendly with the better audio and subtitle preselection possibilities.

[s55]

is it possible to use th new userinterface of handbrake 0.10.0 and the CLI of handbrake 0.9.9?

This isn't supported.

I have no idea what else has changed.

the RPi uses hardware accelerated decoding & rendering.

Doesn't mean there isn't bandwidth issues between the GPU/CPU/RAM/SD card/Network, although lower CRF / level should have ruled that out.


I would have thought using mkvmerge would have ruled out an issue with the mkv container we generate, since it re-creates it, however it might be worth comparing the mkv container info of the 0.9.9 and 0.10.0 files with mkvinfo.

Frankly, the fact the video/audio streams work with AVI, suggests that they are infact fine. It could well be that our new mkv /mp4 muxers are doing something with the files that is triggering a bug/issue with the software on rpi.

[s55]

I ran MkvValidator on a few of my own 0.10.0 MKV's and it shows "mkvalidator 0.4.0: the file appears to be valid" for all of them. If it does the same for you, I don't see how this can be a HandBrake issue. You've already validated the video/audio streams isn't the issue by remuxing it (assuming the tool didn't alter it in any way)

[Deleted User 11865]

FWIW, mkvmerge does preserve a lot of stuff when doing a simple remux. If you want mkvmerge to control all aspect of the output file, a complete demux + mux from elementary streams is required.

[beta-tester]

Code: Select all

# done with Handbrake 0.10.0:
C:\Users\ich>C:\Users\ich\Downloads\mkvalidator-win32.v0.4.2\mkvalidator.exe --details E:\EQ\0.10.0\Title00-1-0_10_0-2.mkv
WRN0E7: DisplayUnit seems to be pixels not aspect-ratio for Video track #1 1920px width from 1920
WRN0E7: DisplayUnit seems to be pixels not aspect-ratio for Video track #1 1080px height from 1080
mkvalidator 0.4.2: the file appears to be valid
Track #1    V_MPEG4/ISO/AVC 17913838 bits/s
        file created with Lavf55.12.0 / HandBrake 0.10.0 2014112200

Code: Select all

# done with Handbrake 0.9.9:
C:\Users\ich>C:\Users\ich\Downloads\mkvalidator-win32.v0.4.2\mkvalidator.exe --details E:\EQ\0.9.9\Title00-1-0_9_9-2.mkv
WRN103: Unnecessary secondary SeekHead was found at 956300267
WRN0D0: There are 4289 bytes of void data

mkvalidator 0.4.2: the file appears to be valid
Track #1    V_MPEG4/ISO/AVC 17913613 bits/s
        file created with libmkv 0.6.5 / HandBrake 0.9.9

BTW, the issue is not related to MKV container only. i also created a MP4/M4V containers and they also shows up the issue,
good on 0.9.9, bad on 0.10.0...
... or do they all using the same MKV library.

[beta-tester]

... however it might be worth comparing the mkv container info of the 0.9.9 and 0.10.0 files with mkvinfo.

oops, i totally overread that part...

... here is what i got from mkvinfo.exe:
Handbrake 0.9.9

Code: Select all

+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 956301715
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 187)
|+ EbmlVoid (size: 4096)
|+ Segment information
| + Segment UID: 0xfb 0xb7 0x29 0x13 0xe9 0x64 0x66 0xd7 0xc3 0xbf 0x6f 0xaf 0x67 0x6b 0xa4 0x0f
| + Muxing application: libmkv 0.6.5
| + Writing application: HandBrake 0.9.9
| + Timecode scale: 1000000
| + Duration: 427.042s (00:07:07.041)
|+ Segment tracks
| + A track
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
|  + Track UID: 26908
|  + Track type: video
|  + Lacing flag: 0
|  + Codec ID: V_MPEG4/ISO/AVC
|  + CodecPrivate, length 47 (h.264 profile: High @L4.1)
|  + Default duration: 41.667ms (24.000 frames/fields per second for a video track)
|  + Default flag: 1
|  + MinCache: 1
|  + Video track
|   + Pixel width: 1920
|   + Pixel height: 1080
|   + Display width: 1920
|   + Display height: 1080
|+ Cluster

Handbrake 0.10.0

Code: Select all

+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 956239676
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 147)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: Lavf55.12.0
| + Writing application: HandBrake 0.10.0 2014112200
| + Segment UID: 0xd9 0x6d 0x28 0x23 0x30 0xb7 0xa4 0xc1 0x01 0x05 0x3f 0xb0 0xbc 0x4b 0x47 0x1c
| + Duration: 427.125s (00:07:07.125)
|+ Segment tracks
| + A track
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
|  + Track UID: 1
|  + Lacing flag: 0
|  + Language: und
|  + Codec ID: V_MPEG4/ISO/AVC
|  + Track type: video
|  + Default duration: 41.667ms (24.000 frames/fields per second for a video track)
|  + Video track
|   + Pixel width: 1920
|   + Pixel height: 1080
|   + Display width: 1920
|   + Display height: 1080
|   + Display unit: 3 (aspect ratio)
|  + CodecPrivate, length 47 (h.264 profile: High @L4.1)
|+ Tags
| + Tag
|  + Targets
|  + Simple
|   + Name: ENCODER
|   + String: Lavf55.12.0
|+ Cluster

here the verbose versions of the info with all details:
Handbrake0.9.9v.txt & 0.10.0v.txt
the first non-smoothplayback issue appears at time ~10s and the second appears at ~42s, ...

the detailed info shows that HB 0.9.9 generates only one Cluster with BlockGroups where HB 0.10.0 generates multiple Clusters with SimpleBlocks.
maybe that makes the different

Code: Select all

#0.9.9
...
|+ Cluster
| + Cluster timecode: 0.000s
| + Block group
|  + Block (track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000)
|   + Frame with size 22544
| + Block group
|  + Block (track number 1, 1 frame(s), timecode 0.167s = 00:00:00.167)
|   + Frame with size 18272
|  + Reference block: -167.000000ms
| + Block group
|  + Block (track number 1, 1 frame(s), timecode 0.083s = 00:00:00.083)
|   + Frame with size 8826
|  + Reference block: 84.000000ms
...
| + Block group
|  + Block (track number 1, 1 frame(s), timecode 2.833s = 00:00:02.833)
|   + Frame with size 113407
|  + Reference block: -41.000000ms
| + Block group
|  + Block (track number 1, 1 frame(s), timecode 2.875s = 00:00:02.875)
|   + Frame with size 108075
|  + Reference block: -42.000000ms
...

Code: Select all

#0.10.0
...
|+ Cluster
| + Cluster timecode: 0.083s
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.083s = 00:00:00.083)
|  + Frame with size 22448
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.250s = 00:00:00.250)
|  + Frame with size 18454
...
|+ Cluster
| + Cluster timecode: 2.833s
| + SimpleBlock (track number 1, 1 frame(s), timecode 2.833s = 00:00:02.833)
|  + Frame with size 109488
| + SimpleBlock (track number 1, 1 frame(s), timecode 2.875s = 00:00:02.875)
|  + Frame with size 106451
...

[beta-tester]

that is really strange...
see x264 decoding stutters on Raspberry Pi
there described somebody exact the same behaviour, and it is possible to fix id for some video content by adding an option to the config.txt file on the Raspberry Pi.

but i can not see the relationship between that option and why when if convert exact the same videocontent with HB 0.9.9 it amways is good and smooth and converted with HB 0.10.0 it is stuttering partially...

PS.: currently i am using OpenELEC 5.0.3 on my RaspberryPi B+ (with 512MB)

[beta-tester]

i observed that issue some time, and with newer versions of OpenELEC i can not see that issue anymore.
(currently i am using OpenELEC 5.0.8 for PRi2)

so i think is was an issue of the RaspbianPi firmware/kernel option "avoid_fix_ts"

i changed the topic to "[solved]"