[Jim Sustacek]

I think there was some odd issue with your source files? I had to process them individually first, then combine them, so it took three commands:
ffmpeg -y -i "Render.avi" -crf 35.0 -vcodec libx264 -vf scale=320:240 -aspect 4:3 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me_method hex -subq 6 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 1 -qcomp 0.6 -qmin 0 -qmax 69 -qdiff 4 -bf 3 -refs 5 -direct-pred 3 -trellis 1 -wpredp 2 -rc_lookahead 50 -threads 0 "video.mp4"

ffmpeg.exe -y -i "Kalimba.mp3" -vn -acodec libvo_aacenc -ar 48000 -b:a 128k "audio.mp4"

ffmpeg.exe -y -i video.mp4 -i audio.mp4 -c copy -shortest "Sample.mp4"

Let us know if that works for you.

[Jim Sustacek]

Thanks for the “-map 0” tip, I will keep that in mind!

[Jim Sustacek]

What happens if you trim first, then re-encode?

You could also try forcing some keyframes in your re-encoding, for example
-force_key_frames 0:00:00,0:00:05
would force two key frames: one at the beginning of the file and one at 5 seconds. Or:
-force_key_frames expr:gte(t,n_forced*5)
should do the same. Although admittedly I haven’t played around with forcing keyframes… I was just guessing that maybe the LG TV is seeing too few keyframes in the shortened file.

[Jim Sustacek]

You should be able to trim at the end without impacting compatibility, right? I know trimming at the beginning of files (-ss) can be problematic, but I trim the end of files to arbitrary points all the time without any issues, although admittedly I’m not trimming them down to 5-10 seconds or trying to play them on a TV…

[Jim Sustacek]

I don’t think you can do it — I’ve never seen ffmpeg update/write a file in-place.

I often use MP4Box (and mp4track) for metadata updates instead.

Otherwise, for ffmpeg, I always use two commands: the first to write to a temp file, then the second to copy it back to the original:
ffmpeg -i original.mp4 -metadata title="my title" -c copy -y /tmp/tmp.mp4 && ffmpeg -i /tmp/tmp.mp4 -c copy -y original.mp4
If you do it a lot, you could wrap it all in a nice script too.

[Jim Sustacek]

That’s curious. My first thought is maybe it’s a key frame issue? Or maybe your LG TV doesn’t support files under a certain time/size, as it might assume them to be corrupt?

First, I would try trimming to 6, 7, 8, 9 seconds etc., up to 15, to see when exactly the trimmed video becomes compatible.

Then, I would try trimming to 5 seconds (or however many seconds as determined by the test above) within your original export command:
ffmpeg -i first.MTS -vcodec libx264 -preset fast -vf scale=1280:720 -crf 20 -maxrate 10000k -bufsize 5000k -acodec copy -t 5 -y firsttrim5.mp4
Let us know how that works. I would be curious to see if this LG TV would play ANY file of 5 seconds in length, if you have any other compatible files you could try trimming and/or re-exporting.

[Jim Sustacek]

This binary does not have libfaac, sorry. But it does have libx264 and libmp3lame — the author has posted his compile command here:

https://ffmpegmac.net/How%20To/

Personally, we’ve been using FFMPEG’s built-in AAC encoder with “-strict experimental” and it’s been working great for us. Definitely try it in your workflow and see if it works for you first — it sure beats trying to compile your own!

[Jim Sustacek]

“-strict experimental” also works — that’s the way it’s described in the ffmpeg documentation:

https://ffmpeg.org/ffmpeg-codecs.html

-2 is just the integer value they use to represent “experimental” — I assume 0 is “normal”, 2 is “very”, etc.

[Jim Sustacek]

If you are running Mac OS X, you can just grab a precompiled binary from here:

https://ffmpegmac.net/

They’ve got 32-bit (OS 10.5) and 64-bit (OS 10.6+) versions, just updated to FFMPEG 1.1.2. These are already built with AAC support (using the “-strict experimental” or “-strict -2” commands, of course).