Preview Image only grabs first frame

[krisbee]

Okay, as discussed on the roku board, the image preview of this branch invokes the backend to dynamically make a thumbnail preview for the mythroku channel.

Previous versions have the script use ffmpeg to make the image - inside the script a note is made that backend has an issue with keyframes in mp4s

I still had that line in, but this branch doesn't use the preview images I was making, which is actually good because they used to get orphaned and I would have to go in twice a year and clean up orphaned preview images...

However, the issue is that the backend does in fact seem to have issues making preview images from the mp4s, as stated - all preview images are frame 1 of the file. It just so happens that myth is SO good at capturing things on time that this often is happening during a fade in, or just as a commercial is ending before the program starts - so my previews are often black or of Judge Judy/Peoples Court bumpers, etc. :)

Now, my frontend doesn't seem to have these preview issues, though - it does seem to make previews more in the show than the mythroku call - is it perhaps there is an additional flag that needs to be passed to grab an image some seconds into the file?

As stated, my script deletes the original .mpg file, but I believe Rick said it pulls the image from wherever the database is pointing to...

[rshendershot]

I don't recall any script that created previews- the main, and my, branch used mythbackend to create them. The original used a pearl script in the mythweb/modules (a procedure named get_pixmap). I call the myth service directly.

Are you using my branch unmodified (except for settings.php) ?

Have you looked at the myth logs? What version of MythTV and on what platform? The later have a mythpreviewgen.log but that might be different on your system. My log has this: Preview at calculated offset (1220 seconds)

I have a test environment for earlier versions of MythTV so knowing what you are using will help. It really should be transparent in creating the preview images, even with the older MRP versions.

I still had that line in what is the content of that line?

[krisbee]

Here is the section of the script that says what I was saying - I imagine I had that convert script from the main branch: /usr/bin/HandBrakeCLI --preset='AppleTV' -i $MYTHDIR/$MPGFILE -o $newname >> $LOGFILE 2>&1

date=date echo "$newbname:$date Previews" >> $LOGFILE

Mythtv seems to have problems with keyframes in mp4s, so make previews with ffmpeg

ffmpeg -loglevel quiet -ss 00:05:09 -vframes 1 -i $newname -y -f image2 $MYTHDIR/$newbname.mp4.png >> $LOGFILE 2>&1

ffmpeg -loglevel quiet -ss 00:05:09 -vframes 1 -i $newname -y -f image2 -s 100x75 $MYTHDIR/$newbname.mp4.64.100x75.png >> $LOGFILE 2>&1

ffmpeg -loglevel quiet -ss 00:05:09 -vframes 1 -i $newname -y -f image2 -s 320x240 $MYTHDIR/$newbname.mp4.64.320x240.png >> $LOGFILE 2>&1

ffmpeg -loglevel quiet -ss 34 -vframes 1 -i $newname -y -f image2 -s 100x75 $MYTHDIR/$newbname.jpg >> $LOGFILE 2>&1

I am using .25 of myth - and it does turn out that even my normal frontend can't render the image except the first frame, so it is definitely the backend having issue.

The next thing I might try is make a 5 second .mpg file and put it along side the file and see if it renders a different image (it shouldn't)...

[rshendershot]

you shouldn't need any scripting to do anything about preview images. please try my branch with no modifications except in the EDIT HERE sections of settings.php.

[krisbee]

Im using your branch on the mythweb side - the script side had those remnants in it, but I had rem'd them out - so they don't actually make preview images anymore...

The issue is mythbackend doesn't generate a proper preview image in my setup, I believe due to keyframes as the old branch had indicated - nothing to really do with your code, just the backend...

I wonder if it has something to do with the settings I'm using in handbrake - I do a higher res than you - I wonder if I go back to my earlier files that were using the iphone settings if those have a better preview...

[rshendershot]

that's a good idea. if you could try the iphone setting and see if it makes a difference that would be great.

this might help also: http://www.gossamer-threads.com/lists/mythtv/users/470383#470383

if you have select * from settings where value = 'PreviewPixmapOffset'; then you might remove that. I have it in one of my machines, but not the other, apparantly leftover from 0.23... it's set to 15. I'm pretty sure it's ignored by the 0.24+ new preview generation algorithm, but removing might find a bug.

Also check if you have HWAccelPlaybackPreview set. This is another legacy setting which exists on only one of my machines and neither of them have any problem with the iPhone converted mp4's.

[krisbee]

Confirmed that it doesn't matter what the quality of the encode/settings were. Also confirmed, mythbackend will create a .png if one doesn't exist in the file, after a frontend or application calls for a preview.

So, you record a show, no .png preview exists - you go into your frontend and one will be created on the fly if it doesn't exist.

So, if the mp4 exists and no image has been created, on my backend setup (myth .25) and apparently earlier versions as this fragment was in their script, the backend fails on the first frame and wont go further into the program.

Here is an example of the fail:

So, with this line of code I modified added to the script, one is created 134 seconds into the program before the backend calls for it - so when the mythroku goes to invoke the backend, it sees one has already been created and skips creating one and failing:

Code: ffmpeg -loglevel quiet -ss 134 -vframes 1 -i $newname -y -f image2 -s 320X240 $MYTHDIR/$newname.png >> $LOGFILE 2>&1

Here is the resulting image created:

[krisbee]

So, my suggestion is to add this line to the script and pre-generate any previews so all systems won't have an issue. I made a quick shell script to generate all my previously poor images and it worked perfectly - all images in my storage (150+) have been created 134 seconds into the program and most were black or had a bumper of the last bit of credits from the previous program...

Thanks for encouraging me to work through the problem!

--Kris

[rshendershot]

you can achieve the same by changing this line in image.php. I'd be very interested to know if this works for you. Glad you have a solution though!

$MythContentSvc . 'GetPreviewImage' . "?ChanId=$chanid&StartTime=$rawstarttime&Width=320&Height=240&SecsIn=134"

[rshendershot]

well that doesn't seem to work at all. even just SecsIn (w/o W and H) gives me unusable images. Not sure why.

[rshendershot]

oh. they're created with size or seconds-in params in their name and my code isn't expecting that. they probably work, but they're not going to be found unless I modify my code to expect a different PNG filename. since you have a solution, this serves as a place others can show they need a fix and it might be worth doing.

[krisbee]

I was also slightly off on the naming paramaters on my code above... this is the one that I think works...

ffmpeg -loglevel quiet -ss 134 -vframes 1 -i $newname -y -f image2 -s 320X240 $MYTHDIR/$newbname.mp4.png >> $LOGFILE 2>&1

[rshendershot]

I suspect that's the best overall solution.

[krisbee]

Okay, here is the final solution... Add after the mysql statement in the user encode script - first we call backend to FORCE to make preview thumbnails, then we overwrite with the correct one. The issue is that if backend hasn't made them yet, the ones we create will get overwritten...

date=`date`
echo "$newbname:$date Previews" >> $LOGFILE
#Mythtv seems to have problems with keyframes in mp4s, so make previews with ffmpeg
#
#Force backend to generate previews first
mythbackend  --generate-preview --chanid $CHANLID --starttime $STRTTIM
#Overwrite Previews made by Backend with good previews...
ffmpeg -loglevel quiet -ss 134 -vframes 1 -i $newname -y -f image2 -s 320X240 $MYTHDIR/$newbname.mp4.png >> $LOGFILE 2>&1
ffmpeg -loglevel quiet -ss 134 -vframes 1 -i $newname -y -f image2 -s 100X56 $MYTHDIR/$newbname.mp4.-1.100x56.png >> $LOGFILE 2>&1

[rshendershot]

are the previews generated by "mythbackend --generate-preview" not usable?

[krisbee]

That is correct - my version of myth (and the original author's, I assume) seem to have problems with mp4 and keyframes - so when a preview is generated by the backend, it always grabs the first frame of the video - never any further in. Apparently the timing on myth or my setup is SO good that the first frame is almost always a black frame, from between commercial to the start of the program, or it is just a few frames of the bumper (like Judge Judy or COMING UP NEXT) and doesn't show any relevant info to the program.

So, that is why I have to go through the trouble of making my own preview images with ffmpeg - it doesn't take but a second to do in the scheme of things - however, backend must create the preview thumbnails first (and the resulting files are based on the file name which is why you have to do it after the MySQL update pointing at the new file), then you can overwrite the bad preview with the good ones from ffmpeg.

I'm surprised you don't have this issue (or haven't in the past) since it was in the original branch (somewhat, without the backend call, and with different filenames that must have changed in version upgrades of myth)... it may be how backend is compiled between distros where it creeps up - I'm using mythbuntu...

Regardless, doing this cross branches won't hurt anything but it will fix any issues if it is present. Again, nothing to do with your code and how it calls backend - I have this issue if I use my normal frontends - if the backend hadn't made a preview before it will overwrite anything I have made despite having the same filenames and revert back to first frame of video in the preview.

Luckily I figured this call out, otherwise I would have had to make a cron job which seemed silly...

[rshendershot]

yeah I rely on mythbackend to do its job so if that breaks then I can understand the contortions you are having to go through to get it to work. If passing SecsIn to that service call results in usable images that's someting I could do. If offering an alternative function (maybe using the mythweb perl images routine or some implementation that does ffmpeg) to conditionally replace the service call would help I'd be willing to give it a try.

[krisbee]

Even still, if I don't use mythroku at all but still convert to mp4 on files, I'd have this issue. So I think internally it has a thumbnail flag in the table somewhere, since the files that are generated are the same names that I had made. I can't find the flag to set with MySQL, so it is easy enough just to force the preview to be made by backend and then redone. Again, takes maybe 3 seconds of processing time, and problem solved - no biggie at all.

[rshendershot]

About three weeks ago I started having a similar problem. In my case the filesize of the preview PNG is very small in comparison to good images and it will display as a clutter of mixed gray background and small black squares. They don't seem to be actual frames but I haven't gone through frame-by-frame. I did come up with a workaround, now on my DEV branch.

I'd found out that the call that Myth makes is a certain number of seconds in (600 typical value) and if I used mythpreviewgen, each time decrementing the index, soon I'd find a number that worked. I also found that --secsin 1 generally worked so that's what's currently in use. It's not completely reliable.

I stopped using handbrake about 6 weeks ago and if I process the same recording with it, the preview needs no workaround; it's doing something that ffmpeg isn't. I did try re-indexing the MP4 using ffmpeg codec copy but that had no observable effect.

I don't recall any software update from about 3-4 weeks ago that would be relevant - and then came the Fedora 22 upgrade a few days later. I think my cable company may have changed something about the program stream but that's a WAG.

I suspect your system is stable but if you have any interest, the places I modified are in rokuencode (calls mythpreviewgen executable) and imageSvc.php to add the --secsIn parameter.

In any case, this Issue documents the problems. I think there's a Myth bug floating around here somewhere...

[rshendershot]

added myth-pic-gen on dev branch - easily exercise mythpreviewgen