Opened 8 years ago

Last modified 5 years 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:
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 8 years ago.
clip.mpg (2.5 MB ) - added by jackburton 7 years ago.
Working clip

Change History (36)

by Giova84, 8 years ago

Attachment: outputfile.avi added

comment:1 by Giova84, 8 years ago

patch: 01

in reply to:  1 comment:2 by Giova84, 8 years ago

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 by humdinger, 8 years ago

yes, see #13354.

comment:4 by diver, 8 years ago

patch: 10

comment:5 by richienyhus, 8 years ago

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 by Barrett, 7 years ago

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 by Giova84, 7 years ago

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 by Barrett, 7 years ago

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

comment:9 by Giova84, 7 years ago

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 by jackburton, 7 years ago

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 7 years ago by pulkomandy (previous) (diff)

comment:11 by jackburton, 7 years ago

I forgot: this is on x86_64

comment:12 by pulkomandy, 7 years ago

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 by smallstepforman, 7 years ago

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 by diver, 7 years ago

ffmpeg package was updated several times within last 12 months.

in reply to:  13 ; comment:15 by jackburton, 7 years ago

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.

in reply to:  15 comment:16 by smallstepforman, 7 years ago

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 by jackburton, 7 years ago

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 by Giova84, 7 years ago

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 by waddlesplash, 7 years ago

Close as fixed then?

comment:20 by jackburton, 7 years ago

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 by pulkomandy, 7 years ago

Sounds sane.

comment:22 by jackburton, 7 years ago

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 by Barrett, 7 years ago

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

by jackburton, 7 years ago

Attachment: clip.mpg added

Working clip

comment:24 by jackburton, 7 years ago

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 by jackburton, 7 years ago

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

comment:26 by Barrett, 7 years ago

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 by cocobean, 6 years ago

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 by jackburton, 6 years ago

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

in reply to:  27 comment:29 by jackburton, 6 years ago

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 by jackburton, 6 years ago

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

comment:31 by jackburton, 6 years ago

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 by jackburton, 6 years ago

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 by jackburton, 6 years ago

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 by cocobean, 6 years ago

Last edited 5 years ago by cocobean (previous) (diff)
Note: See TracTickets for help on using tickets.