I just bought a "Fetch TV" PVR (Australia) https://www.fetchtv.com.au/ and subscribed to a cheapie subscription pack, since I can't afford Foxtel any more (it's very expensive).
Anyway, this thing apparently only plays a limited selection of file types from USB and home media servers, mainly MKV files containing mpeg4&mp3 or mpeg2&mp3. No MP4/avc&aac. Not the greatest format/codec support, but there it is, and it is the only alternative in Australia which offers subscriptions to some UK channels (they have great crime/detective shows from time to time).
I have lots and lots of home movies and whatnot in mp4/avc&aac (most interlaced, 1080i and 576i, a fair number 576p). Many of the videos have various audio offsets.
Hence, what in your view is the prevailing latest and greatest method to convert the .mp4 files into mkv/avc&mp3 or mkv/mpeg2&mp3 without lip sync issues etc ?
My initial guess would be via ffmpeg using say -c:v copy and -c:a libmp3lame -ab 384k and -y output_file.mkv which avoids transcoding the video ?
+ Reply to Thread
Results 1 to 7 of 7
Last edited by hydra3333; 31st Dec 2017 at 00:33.
SONY 75" Full array 200Hz LED TV, Yamaha A1070 amp, Zidoo UHD3000, BeyonWiz PVR V2 (Enigma2 clone), Chromecast, Windows 7 Ultimate, QNAP NAS TS851
Note: "mpeg4" can mean different things. mpeg-4 part 10 is H.264/AVC, mpeg-4 part 2 is the old DivX/XviD thing.
I would go for quality not bitrate - -q:a 0 should work very nice for libmp3lame.
OK and thanks. Testing it is, then.
-q:a 0 does sound attractive, however I wonder in this case
-q:a 0 (NB this is VBR from 22 to 26 KB/s)
-b:a 320k (NB this is 32KB/s, or its max)
I'd ignored .TS as a container without critical thinking, because everywhere you look people are talking about converting to use .mp4 and .mkv containers and not .ts. I now wonder why.
I googled to find pros and cons of .MKV vs .TS and saw not a lot.
https://en.wikipedia.org/wiki/Comparison_of_video_container_formats which says
MPEG transport stream TS (.ts) MPEG Patent encumbered
because of the tiny packet size, streams can be interleaved with less latency and greater error resilience compared to program streams and common containers such as AVI, MOV/MP4, and MKV, which generally wrap each frame into one packet.
So far I suppose:
- can contain just about anything
- can probably use vanilla ffmpeg to move to .mkv container
- I'd need to transcode audio to mp3 for my particular hardware use case (so, slower conversion)
- more error resiliance
- no audio transcode required
- can probably use vanilla ffmpeg to move to .ts container
- none apparent