Opened 10 years ago

Closed 10 years ago

#6406 closed patch (fixed)

Recordings player picks wrong decuder due to mpegps_probe bug

Reported by: Josh Mastronarde <jmastron@…> Owned by: Janne Grunau
Priority: minor Milestone: 0.22
Component: MythTV - General Version: 0.21-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The probe scores reported by the "mpegps" AVFormat decoder are too high for either transcoded h.264 mp4 files (which should be handled by the "mov,..." decoder, or mpegTS files from an HDHomerun (which should be handled by the "mpegts" decoder). The proper decoder reports a non-zero score also, but the mpegps score is higher. This results in the player selecting mpegps, which then fails (bouncing back to the Watch Recordings screen). It appears that mpegps is removed from the encoder list when it fails, so the second time the recording plays with the proper decoder. However, after that, regular mpegps files (in my case from a PVR150) fail to play until the frontend is restarted.

I believe this was also causing other instability in my system (occasional long delays starting to play a show, long delays in processing lirc keypresses). I suspect either the mpegts player can sort of decode mpegps, or vice versa, but not properly. In any case, all of those issues seem to have gone away when I patched this.

The latest ffmpeg sources have a rewritten mpegps_probe procedure that's otherwise compatible with the rest of the code. Trunk already has this as of the latest ffmpeg sync. This patch applies only the "mpegps_probe" procedure from the latest ffmpeg code to the 0.21-fixes mpeg.ps.

I'm submitting because I suspect others may have this issue and not realize it (I originally thought my h.264 transcodes were bad, and that my HDHomerun wasn't installed properly, until I dug into the code to track it down). Others on mythtv-users report similar symptoms, and logging with "-v libav" show the probes being done over and over after this failure.

Attachments (1)

mpegpspatch (2.5 KB) - added by Josh Mastronarde <jmastron@…> 10 years ago.
Patch for mpeg.c

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by Josh Mastronarde <jmastron@…>

Attachment: mpegpspatch added

Patch for mpeg.c

comment:1 Changed 10 years ago by Josh Mastronarde <jmastron@…>

Realized the patch file may not have enough path info -- the file being patched is:

mythtv/libs/libavformat/mpeg.c

comment:2 Changed 10 years ago by Josh Mastronarde <jmastron@…>

Note, per a suggestion to clarify from Michael Dean:

This patch is effectively janne's changeset 18944 for trunk libavformat/mpeg.c, plus FFmpeg changeset 17091 to the same file (bringing the mpegps_probe function up to the latest ffmpeg source). Applying those 2 changesets to 0.21-fixes gives the same result, so I suppose this is better stated as a request to apply those, rather than a distinct patch. Any coding weirdnesses are ffmpeg's, not mine :-) (and are in trunk already). If you'd like, I can see if mythtv 18944 is sufficient to solve the problem, though ffmpeg change is a one-liner and I assume you'll eventually be syncing that to trunk anyway.

I dug into the history -- prior to mythtv trunk 18944 the "mpegps_probe" function hadn't been synced with ffmpeg source in a long time -- it most closely matches ffmpeg r4842 from Jan 2006. Other parts of the mpeg.c file were synced to later ffmpeg revs, but not this function.

At least 3 others have tried this patch and reported that it resolved their file detection and remote lag issues. I also suspect that at least some of the other issues people have reported at various times with mpeg TS and h.264 files are really due to this, as I also had weird issues I'd given up on that went away when I applied this.

comment:3 Changed 10 years ago by danielk

Owner: changed from Isaac Richards to Janne Grunau
Status: newassigned

comment:4 Changed 10 years ago by Janne Grunau

Milestone: unknown0.22
Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.