Videos encoded in Haiku are totally unplayable

[Giova84]

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.

[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.

[humdinger]

yes, see #13354.

[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?

[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.

[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.

[Barrett]

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

[Giova84]

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

[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.

[jackburton]

I forgot: this is on x86_64

[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.

[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

[diver]

ffmpeg package was updated several times within last 12 months.

[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.

[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.

[jackburton]

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

[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.

[waddlesplash]

Close as fixed then?

[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.

[pulkomandy]

Sounds sane.

[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 ?

[Barrett]

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

[jackburton]

Working clip

[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.

[jackburton]

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

[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.

[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.