Need help downloading this vimeo with youtube-dl

[jimdagys]

https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/
I want to download the 720p version.
I used youtube-dl with the
-F
command and got lots of info, but can't download it.
From the -F command, I tried this but no success.

youtube-dl -f hls-akfire_interconnect_quic-2962.640820 "https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/"

Could someone give me the correct youtube-dl code (with brief explanation) to download the video?
I already downloaded the video with Tubedigger, but I want to be able to download with youtube-dl.

[Wizard23]

try this youtube-dl -f mp4 https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/ the link works with ths command i tested it on my linux laptop it downloads and plays just fine.

wth youtube.dl you gotta tell the format to save the video to.Youtube.dl does not know what format you want want it download to. the -f command is telling youtube.dl to download the highest quality. Your link was find but your command to many not needed commands in there. If you want to see what the highest quality of the video is that would be -F. I hope this helps.

[jimdagys]

Anybody, please? As stated, I'm looking for 720p version. Your code downloads the 1080p version, useless for me.

[jagabo]

Just use -f and the name of the video you want:

youtube-dl -f hls-akfire_interconnect_quic-2962 https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/

or to pick individual video and audio streams:

youtube-dl -f dash-akfire_interconnect_quic-video-6f427ecd+dash-akfire_interconnect_quic-audio-0dad67b0 https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/

[jimdagys]

youtube-dl -f hls-akfire_interconnect_quic-2962 https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/

Thank you, that works. I see what my mistake was (adding unneeded text to the code).
I have a comment and another question. That website until recently did not post the streams for the episodes. They sold (and still sell) the episodes for $20 on cd.
I have a question. The 720p version of the video that I got from Tubedigger (probably the same as the video from youtube-dl)
won't play with Media Player Classic 1.6.3.5818 (2320902). The video will play with VLC. If I run the video through this ffmpeg:

ffmpeg -i video.mp4 -c copy video1.mp4

or use the Tubedigger convert tool,
then the video will play with Media Player Classic. Note that the above ffmpeg code does not change the container (mp4).
My question is:
What does the ffmpeg code do to the video so that it plays with Media Player Classic? I couldn't see any difference between the two videos using analyzers G-spot and MediaInfoXP.
Also, another question. Neither video will play in my Ematic media player. This is the first time I couldn't get a video to play in the media player. To get the video to play in the media player, I have to re-encode it with Vidcoder using default settings. This takes a long time. Is there an ffmpeg code that doesn't re-encode that will make the video play in the media player?
If you could give me a few possible ffmpeg codes that I could try on the video, that would be helpful.

[lomero]

your error: add .640820 to hls-akfire_interconnect_quic-2962
and add "...." to your link

[ponens]

What does the ffmpeg code do to the video so that it plays with Media Player Classic? I couldn't see any difference between the two videos using analyzers G-spot and MediaInfoXP.
Also, another question. Neither video will play in my Ematic media player. This is the first time I couldn't get a video to play in the media player. To get the video to play in the media player, I have to re-encode it with Vidcoder using default settings. This takes a long time. Is there an ffmpeg code that doesn't re-encode that will make the video play in the media player?
If you could give me a few possible ffmpeg codes that I could try on the video, that would be helpful.

If the dash version was downloaded, ffmpeg will "fix the headers" via codec copy.

There is a mp4 version that should not have this problem. But the Ematic may not support avc at all. Most cheap chinese players haven't expended for the cost of a license. But if it has played avc files in the past, there might be some other issue with this particular file.

youtube-dl -f http-720p https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/
or
youtube-dl -f http-720p https://player.vimeo.com/video/372238757

The url for the mp4 can also be found by viewing the source of the vimeo player page.

[jimdagys]

Well, for the record, I downloaded various videos from that website (intheamericas.org) on season 7 and 8, and none will play on the Ematic without alteration of the files. I used Tubedigger and downloaded both the mp4 and the ts at 720p and neither would play in the Ematic until I re-encoded with Vidcoder. Videcoder encodes to H.264/AVC and I kept the same resolution (720p) and similar bit rate. Then the video will play fine in the Ematic. However, it takes two hours to re-encode using my netbook. That's why I'm looking for some possible ffmpeg scripts (that don't re-encode) that I can try. (The mp4 and ts (converted to mp4 container) directly from Tubedigger played no problem with vlc, however, I had to "fix the headers", as you said, with ffmpeg, (or Tubedigger convert tool) to play the video (both mp4 and ts) with my version of Media Player Classic Home Cinema.)

[ponens]

Vidcoder encodes to H.264/AVC and I kept the same resolution (720p) and similar bit rate. Then the video will play fine in the Ematic

Does the vidcoder output file have the same h.264 profile (baseline/main/high) as the input file? Does it place the moov atom at the beginning?

If the h.264 profile is the same, maybe a strictly iso compliant file might play. Extract the elemental streams and remux with mp4box.

Or it could be just an aac issue. To test this, mux the original video track from the downloaded mp4 with the re-encoded audio track from vidcoder.

[jimdagys]

If the h.264 profile is the same, maybe a strictly iso compliant file might play. Extract the elemental streams and remux with mp4box.
Or it could be just an aac issue. To test this, mux the original video track from the downloaded mp4 with the re-encoded audio track from vidcoder.

I decided to try the extract/mux method. As a test of demuxing/muxing, I used My MP4Box GUI (which I already had installed on this xp computer). I demuxed and then muxed the original video file and then repeated with the "fixed" file. In both cases, when playing back the two videos with vlc, the video stretched about 5 minutes, but the audio stayed the same. So the audio and video soon got completely out of sync. No good. I then decided to use the latest MP4Box (command line). I downloaded and clicked to install the exe (I thought strange because quite large at 40MB). After, installing, the vlc icon on both videos on the desktop disappeared (and become unknown file icon). I tried to play the unknown file, but Windows didn't know what to do with it.
Then I uninstalled MP4Box (from the uninstaller menu). After uninstalling, the videos on the desktop still remained as unknown files. So MP4Box kind of ruined the computer. I did a system restore and fortunately brought the vlc icon back and the videos played fine on the computer.
Question: Can ffmpeg demux and mux this video? Can you give me the exact code to do this? I can't seem to get the syntax right and keep getting error message.

[jagabo]

I decided to try the extract/mux method. As a test of demuxing/muxing, I used My MP4Box GUI (which I already had installed on this xp computer). I demuxed and then muxed the original video file and then repeated with the "fixed" file. In both cases, when playing back the two videos with vlc, the video stretched about 5 minutes, but the audio stayed the same. So the audio and video soon got completely out of sync.

You may have to specify the frame rate when you mux. I seem to recall MP4Box GUI defaults to 25 fps.

[jimdagys]

Ok, I tried various things to get this video to play in my Ematic media player, but no success. I used ffmpeg and removed the audio and converted to mp3 and mixed together with ffmpeg. I also converted the audio to AAC from Vidcoder, but that also didn't play. I used ffmpeg to cut off several seconds from the beginning, but that didn't play. In all cases, the video plays fine with vlc. I used ffmpeg and cut out a 20 second clip from the video that doesn't play, and also a 20 second clip video that plays fine (but re-encoded with Vidcoder). The media player has no problem playing h264 videos. I have attached both clips here. Could someone take a look at the two videos (noplay and doplay (re-encoded by Vidcoder) and give me some things to try (that doesn't involve re-encoding) to get the video to play in the media player.

[jagabo]

What exactly happens with files that don't play? Does the player show the file in its browser? Does it try play the file? Does it play a little then screwing up the picture? Does it crash? They symptoms may give some hints about what's wrong.

If it's the encoding settings you will have to reencode. From MediaInfo:

doplay: cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=3  / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0                / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=300      / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=abr / mbtree=1 / bitrate=2447 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=25000 / nal_hrd=none               / filler=0 / ip_ratio=1.40 / aq=1:1.00
noplay: cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=22 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / stitchable=1 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=infinite / keyint_min=29 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=20.0                   / qcomp=0.60 / qpmin=5 / qpmax=69 / qpstep=4 / vbv_maxrate=2750  / vbv_bufsize=7500  / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

Some settings that are more likely to cause problems for some players:

ref:        1 vs. 5
mixed_ref:  0 vs. 1
trellis:    0 vs. 2
keyint:     300 vs. infinite

I would start with the slower preset and see if the resulting video plays. If not, try stepping through the lower presets until you find one that plays. Then compare the settings of the two at the boundary.

I built this table a long time ago so it may not reflect the current state of the x264 presets (and some are particular to the type of encoding -- for example CRF vs. ABR):

ultrafast: cabac=0 / ref=1  / deblock=0:0:0 / analyse=0:0       / me=dia  / subme=0  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0                                                                           / weightp=0 / keyint=250 / keyint_min=23 / scenecut=0  / intra_refresh=0                   / rc=crf / mbtree=0 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=0
superfast: cabac=1 / ref=1  / deblock=1:0:0 / analyse=0x3:0x3   / me=dia  / subme=1  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0                   / rc=crf / mbtree=0 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
veryfast:  cabac=1 / ref=1  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=2  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00
faster:    cabac=1 / ref=2  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=4  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=20 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00
fast:      cabac=1 / ref=2  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=6  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00
medium:    cabac=1 / ref=3  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=7  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00
slow:      cabac=1 / ref=5  / deblock=1:0:0 / analyse=0x3:0x113 / me=umh  / subme=8  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00
slower:    cabac=1 / ref=8  / deblock=1:0:0 / analyse=0x3:0x133 / me=umh  / subme=9  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00
veryslow:  cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh  / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8  / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00
placebo:   cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=tesa / subme=11 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40                 / aq=1:1.00

[jimdagys]

What exactly happens with files that don't play? Does the player show the file in its browser? Does it try play the file? Does it play a little then screwing up the picture? Does it crash? They symptoms may give some hints about what's wrong.

The video name (of the noplay video) appears in the files list on the media player, no problem. When I click on it, (the 20 second video), the media player just sits on it for about 6 seconds and then says "unsupported file". If I try to play the original file, (same parameters but 27 minutes long), the media player again sits on it, but doesn't say "unsupported file"; the player just locks up and has to be unplugged and plugged back in which resets the player back to the TV broadcast screen. At no time does the video play at all. Files that I have re-encoded with Vidcoder (to various resolutions and bit rates) always play perfectly in the media player. ( In the past, to reduce file size on the USB memory stick that plugs into the media player, I have re-encoded with Vidcoder and playing the files in the media player for over 3 years, no problem.) Now that I have a 720p TV, I don't want to reduce file size; I just try to play the videos directly after downloading the 720p version. The point is, I want to avoid re-encoding the 27 minute video because of the 2 hours it takes to do that. Not a big problem; I can do something else while the computer re-encodes. I thought you might have some shot-gun ffmpeg scripts that I can try. What I mean is that it would be faster to just try various scripts that change certain subtle video parameters, without re-encoding. But I'm not good with ffmpeg, so I need to be given the exact scripts, and I can just try them on the video, and then see if it plays. Since you can see the 20 second video that plays (that I attached from Vidcoder), I thought there might be a way to use ffmpeg to change some subtle parameters, without re-encoding.
When you say "h264 presets", I assume you are talking about subtle parameters (not bit rate, resolution, etc). When I use Vidcoder, (except for adjusting bit rate and resolution), I just use the default setting and the result always plays perfectly in the media player. So I am unfamiliar with the subtle parameters (or even how to change them with Vidcoder) that you mentioned. And since re-encoding is necessary to change those subtle parameters with Vidcoder, I am back to the 2 hour re-encoding time, anyway.

[jagabo]

I guess you already tried a simple remux in post #5. Maybe adding the faststart option will help:

ffmpeg -i input.mp4 -c copy -movflags faststart output.mp4

To demux to elementary streams, then remux to mp4:

ffmpeg -i input.mp4 -c copy v.h264
ffmpeg -i input.mp4 -c copy a.aac
ffmpeg -r 29.97 -i v.h264 -i a.aac -c copy output.mp4

You can delete v.h264 and a.aac when that's done.

[jimdagys]

ffmpeg -i input.mp4 -c copy -movflags faststart output.mp4

ffmpeg -i input.mp4 -c copy v.h264
ffmpeg -i input.mp4 -c copy a.aac
ffmpeg -r 29.97 -i v.h264 -i a.aac -c copy output.mp4

Thanks for helping. I tried both scripts (faststart and demux/mux) on the 20 second noplay file, but both yielded files that would not play in the media player (after 6 seconds said "unsupported file").

[jagabo]

What file did you remux in post #10. You reported that the resulting file played, though with the wrong frame rate. Fixing the frame rate would have been trivial.

You may have to give up and reencode the files.

Every player I tried played your noplay.mp4 file without any problems. MPC, MPCHC, MPCBE, KMPlayer, PotPlayer, WMP, SMPlayer, VLC, Kodi on a Raspberry Pi 3, Kodi on a $40 Adroid TV box, VLC on my Android phone. Maybe it's time to get a new player.

[ponens]

doplay;
Video
2447 Kbps, 1280*720 (16:9), at 29.970(30000/1001)fps, AVC(Main@L4) (CABAC / 4 RefFrames)
Audio
161 Kbps, 48.0 KHz, 2 channels, AAC (LC)

noplay;
Video
2841 Kbps, 1280*720 (16:9), at 29.970(30000/1001)fps, AVC(High@L.32) (CABAC / 5 RefFrames)
Audio
253 Kbps, 48.0 KHz, 2 channels, AAC (LC)

Both doplay and noplay have the moov atom at the end of the file, so the moov atom is not the issue.

The likely difference is that doplay is encoded using the Main@L4 profile, while noplay is encoded using the High@L.32 profile.

The high profile is more likely to cause problems on low-end media player hardware.

[jimdagys]

What file did you remux in post #10. You reported that the resulting file played, though with the wrong frame rate. Fixing the frame rate would have been trivial.

I remuxed using Mymp4boxgui on the original 25 minute file directly downloaded from the website with Tubedigger. I played in vlc, the video was off-sync by 5 minutes by the time the video got to the end. So I didn't even try to play it in the media player, However, I can go back and try to play that file in the media player.
On the files that ponens gave me, only these two files played in the media player, the other three said unsupported file.
noplay_vid-high-ffm.mp4
noplay_vid-main-ffm.mp4
Since these two files required video re-encoding, I guess I have exhausted all possibilities to get the files to play in the media player without video re-encoding.

[jagabo]

So it's not a Main vs. High profile issue.

Regarding your "Ematic media player" -- Is that a portable device with a small built in screen? You could probably run a quick reencode for that with an ffmpeg batch file. Use a bat file like:

ffmpeg -y -i "%1" -vf scale=w=480:h=-4 -codec:v libx264 -preset veryfast -crf 18 -acodec copy "%1.new.mp4"

On my 8 year old i5 2500K that reencoded a 45 minute 1280x720 30 pfs video to 480x272 in about 3.5 minutes. The quality is probably acceptable for a small screen display.

[jimdagys]

Ematic media player" -- Is that a portable device with a small built in screen?

No, this is the Ematic sold in Walmart for the past 3 years. It is still sold in Walmart. I bought mine 3 years ago. It connects to TV via HDMI cable or composite (for older TVs)
My TV (connected to the Ematic) is a 28 inch 720p with HDMI input. So I always download the 720p version of stream videos, transfer to USB memory stick and then plug the stick into the Ematic.The whole process is kind of a no-brainer. This is the first time that a video hasn't played directly. Vidcoder does an excellent job, though, to make the video play in the Ematic.

[ponens]

No, this is the Ematic sold in Walmart for the past 3 years. It is still sold in Walmart.

You probably mean the Ematic AT102 Digital TV HD Converter Box + Recorder.

Also seen in a review by some guy trying out for the "Hoarders" program; Part 1 & Part 2.

Virtually all of the boxes having this set of functions share the same design and cpu. I have one, the Aluratek ADTB01F, which has the same cpu as the Ematic AT102.

I was able to confirm the same playback results (for doplay/noplay) as you have reported.

For whatever reason, the video that you obtained from intheamericas-vimeo has a byte string for the avc/h264 profile that causes the Ematic player to report "unsupported file".

The byte string is "64 08 20" (two locations). If changed to "64 00 20", the file will play on the Ematic without any re-encoding. There probably are some utilities that can easily edit these profile values quickly.

Attached below is the noplay_hex.mp4, which has only the hex values for the avc/h264 profile edited. This is a two byte change. There is no re-encoding.

[jimdagys]

The byte string is "64 08 20" (two locations). If changed to "64 00 20", the file will play

Jagabo, are you able to follow what Ponens said? Could you translate and show me so I can do this myself? I am completely clueless.
Ponens, Yes, I have the Ematic, but is its the Ematic AT103B (sold inside Walmart store). How did you figure this out (how to get the video to play)? Can you show me step by step how to get the video to play? What software did you use to see the "byte string" of the video? You said you changed the bit string numbers in 2 locations. Did you use Notepad or something similar? I assume that it took only a few seconds to change the numbers. Once you changed the numbers, how did you save it back into the video?

which has only the hex values for the avc/h264 profile edited. This is a two byte change.

???I think this would be an excellent mental exercise if I could figure it out. Might also be useful (if relatively simple to do) for a handful of people who also can't get similar videos to play in their media player.
Edit: looking carefully at the above jpeg, I kind of see what you did. It looks like you only had to change 2 numbers (from 08 to 00, twice). Curious, out of all those numbers, you were able to figure that out that changing these numbers in this way would get the video to play.

[jagabo]

Ponens used a hex editor to change two bytes in the "bad" file. VirtualDub has a built in hex editor.

1) Start VirtualDub. Select Tools -> Hex Editor. Open the video file. The format of the data on each line is: offset, 16 bytes of data as hex, the same 16 bytes of data as ascii text.

2) Edit -> Find, search for "moov". That is the start of the MP4 header data. About 25 lines below that you should see "stbl" and four characters later, "stsd". stsd is the chunk that's going to be modified.


[Attachment 51095 - Click to enlarge]

3) About 7 lines below "stsd" you'll see the sequence 64 08 20, twice, in the hex data. Change both 08 to 00.

4) File -> Save.

You could just search for hex "64 08 20" but it's possible that a short sequence like that may appear in other parts of the file. Same with "sdst". Searching for "moov" then verifying the other chunks will prevent you from changing the wrong data. The "moov" tag should be in all MP4 files. I don't know if all will have the "stbl" and "stsd" tags. And the size of those chunks may vary.

[ponens]

https://intheamericas.org/works/810-colombias-guardians-of-the-homelands/
I want to download the 720p version.

https://player.vimeo.com/video/372238757

I'll use the http-720p quality of the above video as an example. This file exists on the vimeo server as 1546591581.mp4

Inspecting 1546591581.mp4 with mediainfo reveals the following basic details;

Video
2712 Kbps, 1280*720 (16:9), at 29.970 (30000/1001) fps, AVC(High@L3.2) (CABAC / 5 RefFrames)
Audio
253 Kbps, 48.0 KHz, 2 channels, AAC (LC)

"High" is the profile (wikipedia reference)
"3.2" is the level (wikipedia reference)

The "profile" and the "level" are stored in the elementary avc/h264 stream. These stored values are also expressed when the elementary avc/h264 stream is muxed into a mp4 container.

The numeric values that can represent "high" as the profile and "3.2" as the level can be variously expressed. For the purposes here, I will use the hexadecimal values.

Profile name / Hexadecimal value

Baseline / 42
Main / 4D
Extended / 58
High / 64
High 10 / 6E
High 4:2:2 / 7A
High 4:4:4 / F4
CAVLC 4:4:4 / 2C

Likewise, there is a corresponding hexadecimal value for each level.
For level "3.2", the hexadecimal value is "20".

There is a third value that is relevant to the profile and level values.
It is sometimes called the "profile compatibility" or "constraint flag" or "profile-iop"

The three hexadecimal bytes for the "profile", "constraint flag" and "level" are stored as sequential values.

The three values together are also known as the "profile-level-id" (see reference).

So, for the example file here (1546591581.mp4), which has;

Profile: High (64 in hex)
Constraint Flag: 08 in hex
Level: 3.2 (20 in hex)

The following hexadecimal byte string will exist in 1546591581.mp4

64 08 20

The constraint flag (the middle byte "08") is what is tripping up the Ematic player. You can read more about the constraint flag (also known as "profile-iop") here and here.

None of the above matters in order to do a simple hex edit of the mp4 file.

If the constraint flag byte is cleared (changed from 08 to 00) then the Ematic player will play the file. Some code in the Ematic firmware respects that value in a way that is not necessary or correct.

Download the hex editor HxD here.

Install and run HxD, and then using File / Open (or Ctrl+O),

Open 1546591581.mp4

Then use Search / Find (or Ctrl+F) to bring up the Find window.

Using the drop-down menu within the Find window, change Datatype to Hex-values.

Using the search box within the Find Window, enter the following;

640820

Within the Find Window, click OK

Position the cursor over the "08" byte and type "00" over it.

Press "F3" to continue search.

Position the cursor over the "08" byte and type "00" over it.

Do not search any further.

Use File / Save (or Ctrl+S) to save the edited file (a backup of the original file will be saved as 1546591581.mp4.bak).

If you'd rather not use the hex editor, you can use H264 Patcher and BD Tools.

However, using that program will require demuxing the mp4 first, and then remuxing afterwards, so it will take longer than using the hex editor.

[jimdagys]

Thank you, I was able to follow your clear directions with Hex Editor HxD and get the original 26 minute video to play in the media player. However, for exercise, I am trying to do the same thing with H264 Patcher and BD Tools (it is no problem to use ffmpeg and demux/mux the file).
I assume that one should use h264Modify.exe , is that correct?
I extracted the video stream and renamed to input.h264 and used this command:
h264Modify input.h264 –constraint_flags x02 output.h264
but I get error message, "h264Modify has stopped working".
What command should I use on the video stream?

[ponens]

My attempt using h264Modify was successful.

Starting with 1546591581.mp4

1. ffmpeg codec copy into new mp4
2. Extracted track1 h264 using mp4box -raw 1 (mp4box v0.4.4)
3. h264Modify

[jimdagys]

Ponens,
I followed your steps with mp4box and h264Modify, but the video wouldn't play in the media player. It played fine with vlc. Can you take
a look at the steps and see what I did wrong.
First, I used ffmpeg on the original file like this.

ffmpeg -i original.mp4 -c copy original1.mp4

Then I used ffmpeg to extract the audio (which I saved for final step).

ffmpeg -i original1.mp4 -vn -acodec copy aud_only.aac

Then I used mp4box (v0.4.4) to extract the video.

MP4box.exe original1.mp4 -raw 1 -out output.mp4

Then I used h264Modify (I changed the file name)

h264Modify in.h264 out.h264 -constraint_flags x00

Then I used mp4box to mux the video (from h264Modify) and the audio from ffmpeg

mp4box.exe -add out.h264:fps=29.97 -add aud_only.aac file.mp4

But the video (named "file") wouldn't play in the media player (played fine, and in sync, with vlc)

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\youtube-dl>MP4box.exe original1.mp4 -raw 1 -out output.mp4
[iso file] Box "avcC" has 4 extra bytes
Extracting MPEG-4 AVC-H264 stream to h264

C:\youtube-dl>h264Modify in.h264 out.h264 -constraint_flags x00
NAL position 0x00000000 (0)
nal_unit_type: 7 "Sequence parameter set"
profile_idc = 100 "High"
constraint_flags = 16 (0x10)
constraint_set0_flag = 0
constraint_set1_flag = 0
constraint_set2_flag = 0
constraint_set3_flag = 0
constraint_set4_flag = 1
constraint_set5_flag = 0
level_idc = 32
time_scale / 2 = 30000
num_units_in_tick = 1
fixed_frame_scale = 0

NAL units count 48135
End position 0x2072E4E5 (544400613)

C:\youtube-dl>mp4box.exe -add out.h264:fps=29.97 -add aud_only.aac file.mp4
AVC-H264 import - frame size 1280 x 720 at 29.970 FPS
Import results: 48132 samples - Slices: 719 I 14056 P 33357 B - 1 SEI - 656 IDR
Stream uses B-slice references - max frame delay 2
AAC import - sample rate 48000 - MPEG-4 audio - 2 channels
Saving to file.mp4: 0.500 secs Interleaving

C:\youtube-dl>

[ponens]

Here's the steps that I used.

Assuming that "original.mp4" is the native mp4 (1546591581.mp4) from the "http-720p" source on the vimeo server, and not a "mp4" crafted by tubedigger or youtube-dl from the dash or hls sources.

ffmpeg -i "original.mp4" -vcodec copy -acodec copy "original1.mp4"

using v0.4.4;

mp4box -raw 1 "original1.mp4"

above will produce "original1_track1.h264" as output

mp4box -raw 2 "original1.mp4"

above will produce "original1_track2.aac" as output

h264Modify original1_track1.h264 mod.h264 -constraint_flags x00

mp4box -add "mod.h264:fps=29.970" -add "original1_track2.aac" "output_box.mp4"

mp4box -add "output_box.mp4" "output_final.mp4"

The last mp4box step moves the moov atom to the beginning of the file (which doesn't happen in the previous mp4box step because elementary streams were used as input).

Checked playback of "output_final.mp4" on a "tv box" using the MStar-MSD7802 CPU.

[jimdagys]

Thank you for looking at it. Both files
output_box.mp4
output_final.mp4
played fine in the media player.
So now I have to go back and find what step caused the problem when I did it.
1) The first step could have caused a problem:
ffmpeg -i "original.mp4" -vcodec copy -acodec copy "original1.mp4" <your code>
ffmpeg -i original.mp4 -c copy original1.mp4 <my code>
2) Also, I used ffmpeg to extract the audio, you used mp4box
I think just those 2 steps were different from what you did. I'll have to substitute and find which step caused the problem.
I used Tubedigger to download the original video from the "in the americas" website. I'm not sure what you mean when you say "crafted", but this was not a problem, since the original modified video played just now from your code.
Also, what is the difference between extracting the video with ffmpeg and mp4box? In above post 26, I extracted the video stream with ffmpeg (ffmpeg -i original1.mp4 -c copy -an vid_only.mp4) and then h264Modify crashed from that video stream.