View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000119 | Cinelerra-GG | Bug | public | 2019-01-19 02:47 | 2019-01-24 21:28 |
| Reporter | terje | Assigned To | goodguy | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | suspended | ||
| Product Version | 2018-12 | ||||
| Summary | 0000119: Cin-GG doesn't read in or playback H.265/HEVC .mp4 video smoothly (jump between stills) | ||||
| Description | 1) The quite new Google Pixel 3 phone's default video camera setting is H.264/AVC .mp4, which can be recorded as 1080p (4:2:0 8-bit) HD video. ffplay VID_20181218_131437.mp4: Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VID_20181218_131437.mp4': Duration: 00:00:14.36, start: 0.000000, bitrate: 22548 kb/s Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 191 kb/s (default) Stream #0:1(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt470bg/bt470bg/smpte170m), 1920x1080, 22351 kb/s, SAR 1:1 DAR 16:9, 30.02 fps, 30.01 tbr, 90k tbn, 180k tbc (default) This reads in and playback smoothly with both Cinelerra-GG (cin and cinx), ffplay and VLC. However the H264 compression isn't smooth at horizonal panorating, at least not at this bit-rate. 2) Tested so recording with the Pixel 3's Ultra HD 4k (4:2:0 8-bit) .mp4 video camera setting and H.265/HEVC compression (supported by Snapdragon 845 and Android 9). ffplay VID_20190118_233312.mp4: Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VID_20190118_233312.mp4': Duration: 00:00:37.75, start: 0.000000, bitrate: 43761 kb/s Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default) Stream #0:1(eng): Video: hevc (Main) (hvc1 / 0x31637668), yuvj420p(pc, bt470bg/bt470bg/smpte170m), 3840x2160, 43565 kb/s, SAR 1:1 DAR 16:9, 30.07 fps, 30 tbr, 90k tbn, 90k tbc (default) This UHD video file doesn't read in smoothly or doesn't playback smoothly neither with Cinelerra-GG (cin or cinx), ffplay or VLC. The first video images looks fine with beatyful colors and resolution, but so it continues with and jumps between single still images. The playback on the Pixel 3 phone works fine as far as I can see. | ||||
| Steps To Reproduce | As writte above | ||||
| Additional Information | Can try to load a "small UHD video clip" next, if wanted. | ||||
| Tags | Codec, Feature request, Main window, Timeline, Viewer | ||||
| Attached Files | |||||
|
|
Terje: "However the H264 compression isn't smooth at horizonal panorating, at least not at this bit-rate." What does "panorating" mean? The closest we can see is "panning audio"???? "This UHD video file doesn't read in smoothly or doesn't playback smoothly neither with Cinelerra-GG" send a short sample so gg can take a look at it. |
|
|
Phyllis. "Terje: "However the H264 compression isn't smooth at horizonal panorating, at least not at this bit-rate." What does "panorating" mean? The closest we can see is "panning audio"????" My English guess :) Pan - horizontal camera movements where the video images change rapidly (similar effect for vertical tilt or zoom in/out). This is likely a limit example for h264 on a demanding source video sections compressed at a relative low bitrate. "This UHD video file doesn't read in smoothly or doesn't playback smoothly neither with Cinelerra-GG" send a short sample so gg can take a look at it." I suspect this may be a hardware limit as well, as also VLC and ffplay failed during playback of this UHD_H265 video. My take out of new test with two short recorded clips, is that this issuse may be related more to UHD resolution and bitrate than with the h265 compression, because a less demanding HD_265 works well. Upload these two clips next (the snow on the HD_265 is real snow because it was snowing:) ) HD_H265_VID_20190119_125859.mp4 (3.8 MB) UHD_H265_VID_20190119_123318.mp4 (4.0 MB) |
|
|
Me: "I suspect this may be a hardware limit as well, as also VLC and ffplay failed during playback of this UHD_H265 video." I forgot to say: ..... a hardware limit or compatibility issue (decoding, device) ? |
|
|
Terje: thanks for sending the samples. GG is looking at UHD now and it is indeed slow because it is only using 1 CPU. It is not a hardware limit with Cin because he has lots of cores. The problem is that ffmpeg decode is only using 1 thread and he has not figured out a way to make it use more threads. I will let you know if he makes any progress. P.S. I thought "panorating" was another technical word that I did not know -- it should be as it would make a good word for something. |
|
|
Terje: if you download "Big Buck Bunny" 4k version which is HEVC also, it does not have the same slow/choppy playing because it does uses multiple threads - 15 on gg's desktop. So there appears to be something that causes the Pixel 3 generated files to prevent the use of threads. A workaround if to pre-process the file using: ffmpeg -i UHD....mp4 -slices 24 UHD...output_filename.mp4 GG is looking at vdpau now to see if that provides a clue. |
|
|
Thank you for the reply. Yes, using a single core sounds remarkable as the Pixel 3's Snapdragon 845 has 8 cores 8 threads, compared to i7-6700K's 4 cores 8 threads. I tested preprocessing the initial larger .mp4 with the 'ffmpeg -slices' command. And here i7 ran up to 796% CPU load. The output.mp4 was loadable in Cin (max 670% cpu load) and playable (100-150% cpu load) in Cinelerra, the latter also with VLC and ffplay. The output.mp4 file got lower bitrate (video 32.9 Mb/s, audio 129 kb/s) and smaller file size 149 MiB than the initial.mp4 had (video 43.6 Mb/s, audio 43.6 kb/s) and file size 197 MiB. But this doesn't matter for this test. |
|
|
Terje: GG was stopped on the HEVC-vdpau because we do not have the equipment to go any further. If OK with you I would like to mark this issue as closed for now until further information as to how to get around the single thread problem as right now we have no clues. Let me know if OK to close or if you have another "clue"! I guess at this point it is not really a bug, just the way it works. GG noticed this same result as in your statement - "The output.mp4 file got lower bitrate (video 32.9 Mb/s, audio 129 kb/s) and smaller file size 149 MiB than the initial.mp4 had (video 43.6 Mb/s, audio 43.6 kb/s) and file size 197 MiB." There are probably better parameters for the pre-processing ffmpeg command line if this is an issue. |
|
|
Phyllis, yes it is OK to close it for now. I understand we have to wait to see if some solution appears later. I tested also on my Dell XPS 13 (9370) with Intel Core i7-8550U and Intel UHD Graphics 620, and it failed even earlier to load and playback the UHD_265.mp4 file from Pixel 3. While I understand for pure playback on a videoplayer that the file has to be decoded in realtime, my simple wondering is why loading and decoding the file into Cinelerra (ffmpeg) cannot accept delayed time as hardware manage(?) And though the UHD_H265.mp4 is encoded on and optimized for playback on Android/Snapdragon, it is remarkable it manages a single thread when the expected faster i7 cpu doesn't (?) I tested a little more with playback. VLC v. 3.02 failed immediately with a frozen early image and several messages like [0000559463ff1b60] main libvlc: Kjører VLC med standardbrukerflaten. Bruk «cvlc» for å kjøre VLC uten en brukerflate. [00007f71ac12e910] chain filter error: Too high level of recursion (3) [00007f71ac1166e0] main filter error: Failed to create video converter [00007f71b0005200] main video output error: video output creation failed [00007f71c4c15f90] main decoder error: failed to create video output [00007f71c4c15f90] avcodec decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?) [hevc @ 0x7f71c4cc63e0] Could not find ref with POC 2 I installed and tested also playback with VLC beta 4.0.0-dev which was able to playback the whole video, but with serious dropouts in-between and output messages like [00005623e277db60] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [00007f2b1013caf0] chain filter error: Too high level of recursion (3) [00007f2b1013d130] main filter error: Failed to create video converter [00007f2b28c203f0] avcodec decoder error: more than 25 frames of late video -> dropping frame (computer too slow ?) [hevc @ 0x7f2b28cc5ae0] Could not find ref with POC 11 [00007f2b28c203f0] avcodec decoder error: more than 25 frames of late video -> dropping frame (computer too slow ?) [hevc @ 0x7f2b28c93a20] Could not find ref with POC 22 I had a look at the Android developers site, Video decoding recommendations, but it covered only HEVC for HD1080 video and nothing updated to 4k UHD video https://developer.android.com/guide/topics/media/media-formats#video-decoding And lastly, just a couple of other generic HEVC urls for Android and in general https://www.droidviews.com/enjoy-hevc-h-265-video-playback-on-android/ https://www.digitaltrends.com/computing/h-265-hevc-encoding-explained/ |
|
|
Possibly Pixel 3 has a built-in HEVC decoding chip (hardware accellerator) to do the job. On XPS 13 there is installed an intel-vaapi-driver for the Intel UHD Graphics 620. VLC 3.0.2 and VLC 4.00-dev are "able to play back" the UHD_265 video, but with serious dropouts or distorted images. |
|
|
Terje: your last note makes sense. I would like to have GG read over your second to last note before closing for now. |
|
|
@terje I just did some update work on the server and had to restore to today's backup state in the morning because the CMS was causing some problems, so I had to manually add your note from today at noon. ---------------------------------------------------------------------- Add urls to a couple of other posts related to HEVC, Fedora, openSUSE and XPS 13/Intel graphics https://www.reddit.com/r/Fedora/comments/9pi7ot/h265_hevc_playback_issues_f28kde/ https://www.reddit.com/r/openSUSE/comments/5sru0z/confused_about_graphic_drivers/ I added these packages on XPS13/Leap15 with zypper: (1/2) Installing: gstreamer-plugins-vaapi-1.12.5-lp150.3.1.x86_64 ........[done] (2/2) Installing: libva-utils-2.0.0-lp150.1.4.x86_64 .....................[done] No better success with VLC playback of UHD_H265 video. No clue if the following output tells something of interest(?) linux-2v50:~ # vainfo error: XDG_RUNTIME_DIR not set in the environment. libva info: VA-API version 1.0.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_0 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.0 (libva 2.0.0) vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.0.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointEncSliceLP VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointEncSlice VAProfileVP9Profile2 : VAEntrypointVLD ---------------------------------------------------------------------- |
|
|
Finally, at least I got the 200MB UHD_HEVC.mp4 file to playback on XPS 13 in the default Gnome Totem video player, while VLC and ffplay still fails. Cinx loads the file slowly with playback like stills. I think the little progress is due that I possibly happened to get direct accellerated Intel GPU (UHD 620) graphics to work, while the CPU load was held about 80-85% during playback. zypper se -i intel Laster pakkebrønndata... Leser installerte pakker... S | Navn | Sammendrag | Type ---+--------------------+------------------------------------------------------------------------+------ i+ | intel-gpu-tools | Collection of tools for development and testing of the Intel DRM dri-> | pakke i | intel-vaapi-driver | Intel Driver for Video Acceleration (VA) API for Linux | pakke i+ | libdrm_intel1 | Userspace interface for Kernel DRM services for Intel chips | pakke i | libvulkan_intel | Mesa vulkan driver for Intel GPU | pakke i+ | ucode-intel | Microcode Updates for Intel x86/x86-64 CPUs | pakke i+ | xf86-video-intel | Intel video driver for the Xorg X server # inxi -Fz System: Host: linux-2v50 Kernel: 4.12.14-lp150.12.45-default x86_64 bits: 64 Console: tty 2 Distro: openSUSE Leap 15.0 Machine: Device: laptop System: Dell product: XPS 13 9370 serial: <filter> Mobo: Dell model: 0F6P3V v: A00 serial: <filter> UEFI: Dell v: 1.6.3 date: 11/04/2018 Battery BAT0: charge: 52.0 Wh 100.0% condition: 52.0/52.0 Wh (100%) CPU: Quad core Intel Core i7-8550U (-HT-MCP-) cache: 8192 KB clock speeds: max: 4000 MHz 1: 2000 MHz 2: 2000 MHz 3: 2000 MHz 4: 2000 MHz 5: 2000 MHz 6: 2000 MHz 7: 2000 MHz 8: 2000 MHz Graphics: Card: Intel Device 5917 Display Server: X.Org 1.19.6 driver: i915 Resolution: 3840x2160@60.00hz OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) version: 4.5 Mesa 18.0.2 Audio: Card Intel Sunrise Point-LP HD Audio driver: snd_hda_intel Sound: Advanced Linux Sound Architecture v: k4.12.14-lp150.12.45-default |
|
|
Suspending in case a better idea pops into gg's head about HEVC and vdpau or why it is not using multiple-threads. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-01-19 02:47 | terje | New Issue | |
| 2019-01-19 02:47 | terje | Tag Attached: Codec | |
| 2019-01-19 02:47 | terje | Tag Attached: Feature request | |
| 2019-01-19 02:47 | terje | Tag Attached: Main window | |
| 2019-01-19 02:47 | terje | Tag Attached: Timeline | |
| 2019-01-19 02:47 | terje | Tag Attached: Viewer | |
| 2019-01-19 05:52 | PhyllisSmith | Note Added: 0000633 | |
| 2019-01-19 16:04 | terje | File Added: HD_H265_VID_20190119_125859.mp4 | |
| 2019-01-19 16:04 | terje | File Added: UHD_H265_VID_20190119_123318.mp4 | |
| 2019-01-19 16:04 | terje | Note Added: 0000634 | |
| 2019-01-19 16:16 | terje | Note Added: 0000635 | |
| 2019-01-19 18:40 | PhyllisSmith | Note Added: 0000636 | |
| 2019-01-19 18:40 | PhyllisSmith | Assigned To | => goodguy |
| 2019-01-19 18:40 | PhyllisSmith | Status | new => assigned |
| 2019-01-19 23:41 | PhyllisSmith | Note Added: 0000638 | |
| 2019-01-20 00:56 | terje | Note Added: 0000639 | |
| 2019-01-21 17:12 | PhyllisSmith | Note Added: 0000651 | |
| 2019-01-21 21:06 | terje | Note Added: 0000653 | |
| 2019-01-22 01:17 | terje | Note Added: 0000655 | |
| 2019-01-22 03:34 | PhyllisSmith | Note Added: 0000656 | |
| 2019-01-22 13:51 | Sam | Note Added: 0000657 | |
| 2019-01-23 02:31 | terje | Note Added: 0000658 | |
| 2019-01-24 21:28 | PhyllisSmith | Status | assigned => closed |
| 2019-01-24 21:28 | PhyllisSmith | Resolution | open => suspended |
| 2019-01-24 21:28 | PhyllisSmith | Note Added: 0000664 |
