Opened 9 months ago

Closed 8 months ago

#18797 closed bug (fixed)

MediaPlayer - mp4 videos not playing

Reported by: vercu Owned by: pulkomandy
Priority: normal Milestone: R1/beta5
Component: Audio & Video/Codecs Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

With MediaPlayer my mp4 videos are not playing anymore. These are old files I had for years. Never had a problem playing them with Mediaplayer. Now there is a still picture with sound. The file can be played with qmplay2 without a problem. It is also possible to play mpg files with Mediaplayer. As i recall this problem began with the work with ffmpeg not long time ago. Hoped it will be fixed in the meantime - but it did not happen. A screenshot of the file is attached. If you need more information - please let me know. hrev57581

Attachments (5)

screenshot1.png (41.4 KB ) - added by vercu 9 months ago.
Tele-Gym - short.mp4 (171.9 KB ) - added by vercu 9 months ago.
media_info.png (44.6 KB ) - added by vercu 9 months ago.
syslog (427.4 KB ) - added by vercu 9 months ago.
Tele-Gym - short-1.mp4 (359.6 KB ) - added by vercu 9 months ago.

Download all attachments as: .zip

Change History (21)

by vercu, 9 months ago

Attachment: screenshot1.png added

comment:1 by bruno, 9 months ago

Would be better to have the actual video in question. A short part only, would do! Please give also your Haiku version 64bit or 32bit beta4 or nightly? Useful is also a syslog, found in boot/system/var/log!

Start the video and use the media info in MediaPlayer like this one: https://0x0.st/HddX.png

Here all my mp4 files are playing fine!

comment:2 by vercu, 9 months ago

It is 64bit nightly here. A short version is attached. Media info and syslog is also attached.

by vercu, 9 months ago

Attachment: Tele-Gym - short.mp4 added

by vercu, 9 months ago

Attachment: media_info.png added

by vercu, 9 months ago

Attachment: syslog added

by vercu, 9 months ago

Attachment: Tele-Gym - short-1.mp4 added

comment:3 by vercu, 9 months ago

Please use the latest video. The first one was too short.

comment:4 by waddlesplash, 9 months ago

Component: Audio & VideoAudio & Video/Codecs
Keywords: Mediaplayer removed
Milestone: UnscheduledR1/beta5
Owner: changed from nobody to pulkomandy
Status: newassigned

The frames are all reported as having very low performance times (these are in microseconds), that appears to be the problem:

VideoProducer: dropped frame (1) (perf. time 11)
VideoProducer: dropped frame (2) (perf. time 22)
VideoProducer: dropped frame (3) (perf. time 33)
VideoProducer: dropped frame (4) (perf. time 44)
VideoProducer: dropped frame (5) (perf. time 55)
VideoProducer: dropped frame (6) (perf. time 66)
VideoProducer: dropped frame (7) (perf. time 77)
VideoProducer: dropped frame (8) (perf. time 88)
VideoProducer: dropped frame (9) (perf. time 100)

comment:5 by waddlesplash, 9 months ago

Confirmed that the problem does not happen on R1/beta4.

comment:6 by pulkomandy, 9 months ago

It would help to have some information about the latest hrev where it worked fine. vercu, did you notice this recently? Do you update Haiku often? Any hint will save me time in trying to find when the problem happened for the first time.

comment:7 by vercu, 9 months ago

I have an USB stick with href57134. That was from July 2023. The video works with that version. Few month ago there were some commits to ffmpeg. If I remember correctly these were from you. Since then the problem starts. I will install some nightlies in order to narrow it down.

comment:8 by bruno, 9 months ago

The downloaded file works fine in VLC and Qmplay2 and AVIDemuxer, but not in MediaPlayer!

comment:9 by vercu, 9 months ago

Test results: href57475 from Dez 27 is ok. href57508 from Jan 11 is not ok. Is that close enough?

comment:10 by vercu, 9 months ago

More testing: hrev57492 from Dez 31 is ok. hrev57498 from Jan 4 is not.

comment:11 by vercu, 9 months ago

And finally: hrev57492 from Dez 31 is ok. hrev57493 from Jan 2 is not.

comment:12 by pulkomandy, 9 months ago

Thanks for checking.

Some of these changes (to remove the setting of ticks_per_frame) maybe should not have been merged before the update to ffmpeg 6 (where this field is deprecated).

The whole _ApplyEssentialVideoContainerPropertiesToContext function is a bit sketchy anyways, ideally we should finalize and merge a solution more like this one: https://review.haiku-os.org/c/haiku/+/666 where, instead of attempting to recreate a codec context ourselves, we just reuse the one that ffmpeg has created when parsing the file.

Currently we are trying to separate ffmpeg into two independant things: parsing of the container and extraction of individual tracks, and then the decoding of each of those tracks. It isn't designed to work that way, and the information loss is the source of many problems. It is also what makes the encoding side of the media kit completely unusable with the ffmpeg plugin.

However this change can't be merged as it is now, there are memory ownership problems. Help welcome if someone has more time to figure this out.

comment:14 by pulkomandy, 8 months ago

Status: assignedin-progress

So, it turns out _ApplyEssentialVideoContainerPropertiesToContext is doing the right thing, but then the value of framerate in fCodecContext is modified in _DecodeNextVideoFrame. Investigating this now...

comment:16 by waddlesplash, 8 months ago

Resolution: fixed
Status: in-progressclosed

Fix merged in hrev57686.

Note: See TracTickets for help on using tickets.