ffmpeg transcoding

PacketMan

PacketMan

Would someone be able to suggest to me a great cookbook website for cli based ffmpeg transcoding? Samsung TVs (unlike Sony PS3 and PS4) do not seem to like MPEG TS streams that well, and thus require transcoding on the fly (typically through media servers like Emby, Plex, etc). This is CPU intensive. I would like to take these media files and convert them to something more friendly, say .mp4. or .avi for example, and then Emby, Plex, etc would not need to transcode these every time the file is played.

I tried it a few times but seem to be tripping up in the variety of options. If anyone could refer me to a a great web site, doc, etc that would be great. I'm not a fan of YouTube for stuff like this but am open to such formats.

Thanks in advance.
 
I'm not sure exactly what you're looking for. I have a page that covers a lot of different transcoding situations, with links to other pages at http://srobb.net/dvds.html

I find it easiest to figure out what I'm looking for, for example, hevc video bad quality, then google that particular search term. A lot of things are documented on their man pages as dclau said, but there's so much information that you usually have to narrow down what you're seeking. Personally, I prefer mp4 containers for any format that I'm sharing which can be as simple as ffmpeg -i myvid.avi myvid.mp4
Then, if something's wrong with myvid.mp4, google the specific problem, eg, ffmpeg avi to mp4 volume too low.
 
scottro said:
I'm not sure exactly what you're looking for. I have a page that covers a lot of different transcoding situations, with links to other pages at http://srobb.net/dvds.html
Click to expand...

Well for one thing I keep getting lots of errors (see below), so I had assumed I need to include more than the generic ffmpeg -i file.ts file.mp4

Code: 
[h264 @ 0x80c962f00] left block unavailable for requested intra mode
[h264 @ 0x80c962f00] error while decoding MB 77 48, bytestream 18807
[h264 @ 0x80c962f00] concealing 2372 DC, 2372 AC, 2372 MV errors in P frame
[h264 @ 0x80c964300] Reference 2 >= 2
[h264 @ 0x80c964300] error while decoding MB 79 12, bytestream 6028
[h264 @ 0x80c964300] concealing 6690 DC, 6690 AC, 6690 MV errors in P frame
[h264 @ 0x80c962f00] top block unavailable for requested intra mode -129.5kbits/s dup=124 drop=0 speed=0.897x 
[h264 @ 0x80c962f00] error while decoding MB 79 22, bytestream 12660
[h264 @ 0x80c962f00] concealing 5490 DC, 5490 AC, 5490 MV errors in P frame
[h264 @ 0x80c964d00] top block unavailable for requested intra mode -107.6kbits/s dup=127 drop=0 speed=0.889x 
[h264 @ 0x80c964d00] error while decoding MB 119 18, bytestream 14391
[h264 @ 0x80c964d00] concealing 5930 DC, 5930 AC, 5930 MV errors in P frame
[h264 @ 0x80c962500] top block unavailable for requested intra mode
[h264 @ 0x80c962500] error while decoding MB 5 6, bytestream 11463

scottro said:
Then, if something's wrong with myvid.mp4, google the specific problem, eg, ffmpeg avi to mp4 volume too low.
Click to expand...

I'll look at your web pages and try again to search for decoding errors.
 
PacketMan said:
Well for one thing I keep getting lots of errors (see below), so I had assumed I need to include more than the generic ffmpeg -i file.ts file.mp4
Click to expand...
I guess, the transport stream (*.ts) indeed may have errors, the idea of using it is the possibility of recovering quickly from transmission errors.
Anyway, do you get a good resulting *.mp4 file?
 
Yeah its OTA video grabbed by a HDHomeRun tuner and its output is MPEG transport stream. To tell the truth, I never let it finished because of the errors. If I try to play the segment that was created I get an error message saying "the file contains no playable streams".

So you think that is actual video errors, and not ffmpeg reading the original source file wrong?
 
Of course, I'm not sure about your case, but I've seen errors reported by ffmpeg in different situations with the subsequent successful transcoding.
Would you share a fragment of your ts file?
 
Let me fart around first. I may have been over thinking this for what I am trying to do. I actually just did a file with the -c copy option since my suspicion is all I really want to do is change the container format. That one completed really fast with no errors; which makes sense since it doesn't do decoding/encoding. I'll see how the Samsung TVs like it or not and report back in a while.
 
Also, keep in mind, that ffmpeg has a useful option: preset. For your purpose you may want to use ultrafast:
Code: 
$ ffmpeg -i file.ts -preset ultrafast file.mp4
I tested it with a short ts file and got transcoding time of 16 sec vs 84 sec with medium (the default option), it doesn't affect the quality, but does increase the output file's size significantly.
 
Thanks again aragats. I don't see the -preset option listed in ffmpeg(1), I'll try that layer, but I'd rather have a smaller sized output file, even if the conversion takes hours. Oh, the -c copy didn't make a difference, but the file did play.

Thanks for your help with this.
 
PacketMan said:
I don't see the -preset option listed in ffmpeg(1)
Click to expand...
This is a good cheat sheet.

Also, slightly offtopic, but could be useful.
Not sure about Samsung TVs, but from my experience with Chromcast: although it's supposed to play only compliant mp4 files, it actually plays mkv with x264 streams as well if I change the file's extension to mp4! So for most cases I just created symlinks like ln -s file.mkv file.mp4 instead of transcoding.
 
I'd also like to add that I frequently see all sorts of errors that turn out to be meaningless. Of course, I can't get one right now, but it will be something like say, frame mismatch, can't copy whatever, but then it continues, and the final file is fine.
aragats, thanks for that little note. I find all sorts of oddities here and there, that aren't consistent. For example (not ffmpeg but) doing mkvmerge -o new.mkv my.srt my.mp4 gave me something with no video. On that particular file I just did ffmpeg -i my.mp4 -copy my.avi and then worked with the avi container.

TL;DR sometimes you get inconsistent results or error messages that don't affect the final file.
 
I use HandBrake for transcoding, works great:

HandBrakeCLI -i in_file.ts -o out_file.mp4 -e x264 --preset "Very Fast 480p30" -x :threads=8 -q 20
 
Thanks for all your help with this guys. Looks like the output of the HDHomeRun has some errors in it, which I am guessing is due to errors being in the input OTA signal. I'll look into getting a high gain outdoor antenna this spring. In the meantime I discovered something. I had the output of the HDHomeRun set to transcode profile "heavy". The output of this is H.264 inside a MPEGTS container, and the Samsung TVs do not like that. If I get the HDHomerun profile to raw, the output is still MPEGTS but its not H.264, and of course I forgot what it is. The Samsung TVs has no issue anymore.

But I will still use ffmpeg to convert to .mp4. I also tried .avi, but the end result is poor video; much more grainier.

Thanks again.
 
PacketMan said:
I also tried .avi, but the end result is poor video; much more grainier.
Click to expand...
AVI is just a container, I guess, in your case the difference in quality occurs due to different default encoding parameters. In other words, when you tell ffmpeg to convert using namely MP4 container, it uses certain default parameters which eventually provide better quality. You can explicitly set the encoding parameters for consistent quality, e.g.
Code: 
ffmpeg -i input.ts -c:v libx264 -preset slow -crf 22 -c:a copy output.avi
where crf value is in 0–51 range: 0 is lossless, 23 is the default, and 51 is worst quality (there are other parameters too, but setting crf is enough for most purposes). Also, if you don't set video codec to libx264 explicitly, it's not clear what ffmpeg may use when encoding using AVI container.
 
You must log in or register to reply here.
Back
Top