# ffmpeg transcoding



## PacketMan (Dec 30, 2017)

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.


----------



## dclau (Dec 30, 2017)

Probably their documentation is your best bet: https://ffmpeg.org/ffmpeg.html


----------



## scottro (Dec 30, 2017)

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.


----------



## PacketMan (Dec 30, 2017)

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



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


```
[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.



I'll look at your web pages and try again to search for decoding errors.


----------



## aragats (Dec 30, 2017)

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


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?


----------



## PacketMan (Dec 30, 2017)

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?


----------



## aragats (Dec 30, 2017)

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?


----------



## PacketMan (Dec 30, 2017)

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.


----------



## aragats (Dec 30, 2017)

Also, keep in mind, that `ffmpeg` has a useful option: _preset_. For your purpose you may want to use _ultrafast_:
	
	



```
$ 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.


----------



## PacketMan (Dec 30, 2017)

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.


----------



## aragats (Dec 31, 2017)

PacketMan said:


> I don't see the -preset option listed in ffmpeg(1)


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.


----------



## scottro (Dec 31, 2017)

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.


----------



## aragats (Dec 31, 2017)

scottro said:


> I just did ffmpeg -i my.mp4 -copy my.avi and then worked with the avi container.


Yes, I noticed that too: sometimes _avi_ container works better. I frequently see inconsistent frame timestamps in various _mp4_ files, maybe that's the problem.


----------



## tankist02 (Dec 31, 2017)

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`


----------



## PacketMan (Jan 2, 2018)

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.


----------



## aragats (Jan 2, 2018)

PacketMan said:


> I also tried .avi, but the end result is poor video; much more grainier.


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.
	
	



```
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.


----------



## PacketMan (Jan 2, 2018)

I figured that, but have not had the time to dive into it.


----------

