Opened 2 years ago

Last modified 7 months ago

#13407 new bug

Videos encoded in Haiku are totally unplayable

Reported by: Giova84 Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: Audio & Video/Codecs Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by jackburton)

hrev51051

I attempted to record a video of Haiku using BeScreenCapture: i leave all default settings (file format: AVI - codec: MP4): i recorded few seconds of video: the resulting video file is unplayable with any media player: the default MediaPlayer, SMPlayer and mplayer. I get no error, just "silence". If i attempt to open such video file with MediaConverter, it tell me that the file has a duration of 0 ms, and is also unconvertible.

A working video downloaded from Internet, if converted using MediaConverter, becomes unplayable by other OSes.

Months ago, also if imperfects, at least i was able to play such files generated from BeScreenCapture.

However, i attach such video file.

Attachments (2)

outputfile.avi (847.3 KB) - added by Giova84 2 years ago.
clip.mpg (2.5 MB) - added by jackburton 12 months ago.
Working clip

Change History (36)

Changed 2 years ago by Giova84

Attachment: outputfile.avi added

comment:1 Changed 2 years ago by Giova84

Has a Patch: set

comment:2 in reply to:  1 Changed 2 years ago by Giova84

Replying to Giova84:

Sorry, but, maybe, the bug tracker has recently set the "has a patch" option as default? Because i didn't voluntarily set the "has a patch" entry.

comment:3 Changed 2 years ago by humdinger

yes, see #13354.

comment:4 Changed 2 years ago by diver

Has a Patch: unset

comment:5 Changed 2 years ago by richienyhus

I just checked the file on Android, VLC couldn't play it as it just showed a blank screen.

However I was able to play it correctly with ES Player and Samsung Video. Although it did appear rather janky when played, but I am assuming that is because BeScreenCapture was set at low frame rate when recorded?

comment:6 Changed 23 months ago by Barrett

I checked the file just now, and it plays correctly under linux. The quality is also very good, too bad for not being frame-accurate. But this is a problem at the source, and doesn't relate ffmpeg.

comment:7 Changed 23 months ago by Giova84

Now I am on hrev51152: using MediaPlayer I am still unable to play the video file; with MPlayer, now instead, I am able to play such file.

comment:8 Changed 23 months ago by Barrett

Yes, that means differently from what it's written in the title, it's a decoding problem and not an encoding one.

comment:9 Changed 23 months ago by Giova84

Well, with the term "unplayable", in facts I meant "unable to decode", since decoding, in this case, occurs when the file is played.

comment:10 Changed 16 months ago by jackburton

I wouldn't exclude an encoding problem, however: Since some time, encoding a media file (with any method) has been problematic. BeScreenCapture uses the Haiku media kit api to encode the media clip.

For example, here's the terminal output when I try to encode a clip within BeScreenCapture:

[avi @ 0x1d88c09d140] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead.
[avi @ 0x1d88c09d140] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
[swscaler @ 0x1d88c5778f0] Warning: data is not aligned! This can lead to a speedloss
[avi @ 0x1d88c09d140] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[avi @ 0x1d88c09d140] Encoder did not produce proper pts, making some up.

Last edited 16 months ago by pulkomandy (previous) (diff)

comment:11 Changed 16 months ago by jackburton

I forgot: this is on x86_64

comment:12 Changed 16 months ago by pulkomandy

The missing pts looks worrying indeed. I also noticed similar issues in the decoding path (we seem to ignore the pts there...)

I think a review of the ffmpeg encoder could be needed. I'm also considering making a "dummy" encoder that would just trace information to a text file, which would allow to see if at least the application and media kit are behaving as expected.

comment:13 Changed 16 months ago by smallstepforman

I’m making a developer time lapsed video of a new project (using BeScreenCapture), and all my x86_32 videos (from 12 months ago) captured at 1600x1200@10 fps. All my current videos on x86_64 are captured at 1600x1200@2 fps. I also noticed the problem with MediaPlayer struggling to play back short videos @2 fps, longer videos play fine.

From these 2 test scenarios, I can deduct the following: a) x86_64 version of BeScreenCapture struggles to capture and reverts to 2fps or b) a regression in backend during last 12 months

comment:14 Changed 16 months ago by diver

ffmpeg package was updated several times within last 12 months.

comment:15 in reply to:  13 ; Changed 16 months ago by jackburton

Replying to smallstepforman:

I’m making a developer time lapsed video of a new project (using BeScreenCapture), and all my x86_32 videos (from 12 months ago) captured at 1600x1200@10 fps. All my current videos on x86_64 are captured at 1600x1200@2 fps. I also noticed the problem with MediaPlayer struggling to play back short videos @2 fps, longer videos play fine.

From these 2 test scenarios, I can deduct the following: a) x86_64 version of BeScreenCapture struggles to capture and reverts to 2fps or b) a regression in backend during last 12 months

Just to know, which version of BeScreenCapture are you using ? I've developed the latest version on x86_64 (on a VM), and while I have not tried 1600x1200 clips, I managed to record smaller clips with decent performances.

comment:16 in reply to:  15 Changed 16 months ago by smallstepforman

Replying to jackburton:

Just to know, which version of BeScreenCapture are you using ? I've developed the latest version on x86_64 (on a VM), and while I have not tried 1600x1200 clips, I managed to record smaller clips with decent performances.

Bleeding edge on x86_64, h51659 (latest on 07/12/2017), BeScreenCapture is 2.3. The framerate setting makes no difference, I always get 2fps at 1600x1200 and at 1280x1024, and at 1024x768 I get 4 fps (slight improvement). Videos I captured last year in september/october on the 32 bit version of Haiku captured 1600x1200@10 fps, so it performed better.

The original bug was about videos being unplayable on some systems, which is not exactly true since they will play when sufficient footage is captured to combat the 2fps.

comment:17 Changed 16 months ago by jackburton

Would you please also open a ticket in the bescreencapture bug tracker about the fps issue? Also with your PC hardware specs, please.

comment:18 Changed 15 months ago by Giova84

hrev51727 gcc2h: now (I can't recall from which revision of Haiku or of BeScreenCapture) the resulting vdeo files - at least *.avi/MP4, are OK.

comment:19 Changed 13 months ago by waddlesplash

Close as fixed then?

comment:20 Changed 12 months ago by jackburton

For this problem:

 [avi @ 0x1d88c09d140] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead.

it seems we just need to add the following two lines in AVFormatWriter.cpp, line 144:

	fStream->time_base.den = (int)format->u.raw_video.field_rate;
	fStream->time_base.num = 1;

as far as I understand, we need to duplicate that data both in the stream and in codec.

comment:21 Changed 12 months ago by pulkomandy

Sounds sane.

comment:22 Changed 12 months ago by jackburton

For reference:

https://stackoverflow.com/questions/49024804/using-avstream-codec-time-base-as-a-timebase-hint-to-the-muxer-is-deprecated-se

Setting the codecContext->time_base value is mandatory and should not be skipped. Uncomment it and you should be fine. Also see the code example that ffmpeg provided.

As to why both values are needed: AVStream and AVCodecContext are two different structures that may or may not be used together, depending on what your code needs to do. They both need a time_base so they both have them. You may call it one of the many peculiarities in the ffmpeg codebase.

Is anyone able to test & commit this ?

comment:23 Changed 12 months ago by Barrett

I will look at it lately, looks like a nice catch ;)

Changed 12 months ago by jackburton

Attachment: clip.mpg added

Working clip

comment:24 Changed 12 months ago by jackburton

It seems that using MPEG/Mpeg4 produces working clips (like the one attached), with a duration and all. Now, it's not yet clear if there are problems only in the encoding part, or also in the decoding.

comment:25 Changed 12 months ago by jackburton

Seems I spoke too fast: the attached clip plays fine in Haiku, but not on CentOS.

comment:26 Changed 12 months ago by Barrett

Unfortunately setting the stream timebase still produces video without duration here.

About the decoding thing, it seems my linux install is more resilient with those files, that's why I think we can do better on decoding side.

comment:27 Changed 10 months ago by cocobean

Tested on hrev52012 x86_64 w/BeScreenCapture v2.3.2. Everything works on my end. Recorded screen movements using AVI/MP4 @1080p (default setting for me). Playback worked in Mplayer and MediaPlayer. Resolved on my end.

comment:28 Changed 8 months ago by jackburton

Component: Servers/media_serverAudio & Video/Codecs
Description: modified (diff)
Owner: changed from Barrett to pulkomandy
Platform: x86All
Summary: Resulting video files from BeScreenCapture are totally unplayableVideos encoded in Haiku are totally unplayable

comment:29 in reply to:  27 Changed 8 months ago by jackburton

Replying to cocobean:

Tested on hrev52012 x86_64 w/BeScreenCapture v2.3.2. Everything works on my end. Recorded screen movements using AVI/MP4 @1080p (default setting for me). Playback worked in Mplayer and MediaPlayer. Resolved on my end.

Seems like there are still problems: an avi or mpeg video (MPeg4) encoded in Haiku is only playable in Haiku, and not on other OSes.

comment:30 Changed 8 months ago by jackburton

Sorry, didn't want to change owner, only component.

comment:31 Changed 8 months ago by jackburton

I tried with Barrett's latest changes (including hrev52169): While warning about codec vs codecpar have disappeared, AVI files still haven't got a duration, Theora videos still aren't encoded correctly. MPEG/MPEG4 still work in Haiku, will try on other OSs shortly.

comment:32 Changed 8 months ago by jackburton

Don't know if it helps or if it's related, but sometimes, when I encode a clip with BeScreenCapture, MediaPlayer finds two tracks in it. Happened also before Barrett's changes.

Could be a bug in BeScreenCapture, but who knows.

comment:33 Changed 8 months ago by jackburton

I tried to play these clips on Windows with VLC: They play correctly. There are still some issues (described in the comments), but maybe these deserve a new ticket ?

comment:34 Changed 7 months ago by cocobean

@jackburton - Seems we can close this ticket and create new ones more specific to your issues.

Note: See TracTickets for help on using tickets.