Opened 6 years ago

Closed 4 years ago

#2196 closed defect (wontfix)

specific ogg video plays in vlc/ffplay but not in mplayer (r37224)

Reported by: Zorael Owned by:
Priority: normal Component: undetermined
Version: unspecified Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: yes Analyzed by developer: no


Summary of the bug:

System is running Arch x86_64 with current mplayer and related packages, with mplayer reporting itself as SVN-r37224.

Trying to play, everything plays fine for 2.4 seconds, then audio dies. Video continues to play until t=6.4s, then the program exits saying End of file.

Manually specifying -demuxer ogg makes both video and audio repeatedly die (and shortly revive) with AO_ALSA error messages.

[AO_ALSA] Write error: Broken pipe
[AO_ALSA] Trying to reset soundcard.

Manually specifying -demuxer lavf exhibits the same behaviour as when not passing any -demuxer argument.

The video plays fine in both vlc (2.1.4-49-gdab6cb5) and ffplay (2.2.4), both from the official Arch repositories.

How to reproduce:

$ wget

$ mplayer -v dconf2014-day02-talk03.ogv
# observe audio stopping, then program exiting

$ mplayer -v -demuxer ogg dconf2014-day02-talk03.ogv
# observe audio and video constantly pausing and resuming, sync hopelessly lost

Attachments (2)

beastd-mplayer-Hack-for-making-the-sample-from-ticket-2196-work.patch (945 bytes) - added by beastd 6 years ago.
10s-of-dconf2014-day02-talk03.ogv (1.0 MB) - added by beastd 6 years ago.
First 10s of the reported sample; enough to reproduce the problem

Download all attachments as: .zip

Change History (8)

comment:1 Changed 6 years ago by beastd


the attached patch seems to make your quoted sample work for me.

Not yet sure how a proper fix would look like.

Changed 6 years ago by beastd

First 10s of the reported sample; enough to reproduce the problem

comment:2 Changed 6 years ago by beastd

  • Reproduced by developer set
  • Status changed from new to open

comment:3 Changed 6 years ago by beastd

If I simply remux the file with ffmpeg like this

ffmpeg -i dconf2014-day02-talk03.ogv -map 0 -c copy dconf2014-day02-talk03.remuxed_by_ffmpeg.ogv

the file plays with unpatched mplayer.

The interleaving seems quite different; here follows an excerpt of the
comparison I conducted with the help of ffprobe. The first number is the
number of consecutive packets of video or audio, the lines starting with
v are talking about video packets and the lines with a are about audio.

--- dconf2014-day02-talk03.ogv.packets.txt
+++ dconf2014-day02-talk03.remuxed_by_ffmpeg.packets.txt
@@ -1,2189 +1,7025 @@
-v:       68   last packet: pts_time=-0.002585
+v:       20   last packet: pts_time=-0.002585
-a:      249   last packet: pts_time=2.435769
+a:      149   last packet: pts_time=0.834168
-v:      120   last packet: pts_time=2.467438
+v:       35   last packet: pts_time=0.998776
-a:      255   last packet: pts_time=6.439773
+a:       76   last packet: pts_time=2.002002
-v:       96   last packet: pts_time=6.456463
+v:       25   last packet: pts_time=2.021905
-a:      253   last packet: pts_time=9.642976
+a:       88   last packet: pts_time=2.836170
-v:      108   last packet: pts_time=9.964966
+v:       36   last packet: pts_time=3.027166
-a:      217   last packet: pts_time=13.246580
+a:       56   last packet: pts_time=4.037371
-v:      108   last packet: pts_time=13.478730
+v:       24   last packet: pts_time=4.043039
-a:      210   last packet: pts_time=16.850184
+a:       54   last packet: pts_time=4.838172
-v:      120   last packet: pts_time=17.115034
+v:       36   last packet: pts_time=5.053107
-a:      255   last packet: pts_time=20.854188
+a:       51   last packet: pts_time=6.039373
-v:       61   last packet: pts_time=21.125057
+v:       24   last packet: pts_time=6.054467
-a:      251   last packet: pts_time=24.824825
+a:       66   last packet: pts_time=6.840174
-v:       21   last packet: pts_time=24.596621
+v:       36   last packet: pts_time=7.059569
-a:      254   last packet: pts_time=29.262596
+a:       63   last packet: pts_time=8.041375
-v:       52   last packet: pts_time=29.578821
+v:       24   last packet: pts_time=8.075442
-a:      255   last packet: pts_time=34.067401
+a:       54   last packet: pts_time=8.842176
-v:      108   last packet: pts_time=34.178617
+v:       36   last packet: pts_time=9.085510
-a:      255   last packet: pts_time=37.671004
+a:      106   last packet: pts_time=10.043377
-v:      108   last packet: pts_time=37.895397
+v:       24   last packet: pts_time=10.103129
-a:      254   last packet: pts_time=41.274608
+a:       65   last packet: pts_time=10.844178
-v:       84   last packet: pts_time=41.425782
+v:       36   last packet: pts_time=11.124807
-a:      253   last packet: pts_time=44.077411
+a:       62   last packet: pts_time=12.045379
-v:       72   last packet: pts_time=44.121043
+v:       24   last packet: pts_time=12.137778
-a:      255   last packet: pts_time=46.479813
+a:       70   last packet: pts_time=12.846180
-v:       84   last packet: pts_time=46.668413
+v:       36   last packet: pts_time=13.153651
-a:      253   last packet: pts_time=49.282616
+a:       49   last packet: pts_time=14.047381
-v:      120   last packet: pts_time=49.505170
+v:       24   last packet: pts_time=14.169002
-a:      255   last packet: pts_time=53.286620
+a:       74   last packet: pts_time=14.848182

comment:4 Changed 6 years ago by reimar

Hm, it actually plays for me.
It tends to play audio and video alternatingly or out of sync though.
And if I play with different -mc value it indeed starts to exit...

comment:5 Changed 6 years ago by reimar

With latest SVN it will continue playing in all cases.
But you will need to explicitly -ni to make it play usably.
IMHO the file is just broken, and maybe we should support it better, but mostly the creators need to fix their workflow, bad interleaving is especially bad when streaming to low-memory devices.

comment:6 Changed 4 years ago by reimar

  • Resolution set to wontfix
  • Status changed from open to closed

r37838 prints a warning and points out the -ni workaround.
From my point of view we don't want to do more about this, needing user interaction for severly broken files like this seems mostly acceptable to me.

Note: See TracTickets for help on using tickets.